SHP文件与PostGIS数据库Geom字段：WKB/EWKB高精度互转最全踩坑总结

一、前言

在GIS业务开发中，经常遇到一个核心需求：拿到SHP原始矢量，精准对应数据库中Geom原始存储值。

很多人分不清：WKT、WKB、EWKB，经常出现导出坐标精度丢失、二进制串对不上等问题。

本文结合真实实操踩坑，一次性讲透：

为什么SHP肉眼坐标一样，二进制Geom却不一样？
PostGIS真实存储格式是什么？
如何高精度正向生成数据库原生EWKB串？
如何从十六进制Geom逆推原始高精度坐标？
精准实现Hex与高精度坐标互相转换

二、三种几何格式通俗区分（重点）

1、WKT（人看的明文）

示例：POINT \(107\.503611000347 35\.6885570000056\)

特点：可读、简单、不带坐标系。

2、WKB（标准二进制）

示例：0101000000fab9a1293be05a404837c2a222d84140

特点：纯几何，不带SRID坐标系，PostGIS不原生存储这种。

3、EWKB（PostGIS真实存储格式）⭐重点

示例：0101000020E6100000FCB9A1293BE05A405037C2A222D84140

多出一段：20E6100000 = SRID=4326

结论：PostGIS库里Geom字段存的全部是EWKB，不是WKB。

三、最容易踩的坑（你今天全部遇到过）

坑1：小数点位数不同，二进制完全不同

看上去几乎一样的坐标：

原始高精度：POINT \(107\.503611000347 35\.6885570000056\)
四舍五入后：POINT \(107\.503611 35\.688557\)

二进制EWKB完全不一样，绝对不能混用。

原因：浮点二进制存储极其敏感，哪怕末尾0.0000000001差异，Hex串完全改变。

坑2：QGIS导出WKT默认丢精度

QGIS导出CSV时，自动压缩小数位，永远得不到SHP原生高精度坐标，所以转出来Hex永远和数据库对不上。

四、生产通用万能SQL（可直接收藏）

1、正向生成：高精度EWKB（和数据库一模一样）

-- WKT 转 PostGIS 原生存储 EWKB 十六进制
SELECT encode(
  ST_AsEWKB(
    ST_SetSRID(ST_GeomFromText('POINT (107.503611000347 35.6885570000056)'),4326)
  ),'hex'
) AS geom_hex;

2、逆向解析：Hex原始Geom逆推高精度WKT

解决endian报错、唯一正确写法

-- EWKB十六进制 逆推 原始高精度坐标
SELECT ST_AsText(
    ST_GeomFromEWKB(
        decode('0101000020E6100000A428756E7F145840C0D39D279E454440', 'hex')
    )
) AS wkt_point;

3、批量解析库里所有Geom（生产常用）

SELECT
  id,
  ST_AsText(ST_GeomFromEWKB(decode(geom, 'hex'))) AS wkt_point
FROM 你的表名;

五、如何拿到SHP原生高精度Hex（不用计算）

最稳定、零误差方案：超图iDesktop

SHP导入UDB文件数据源（不要直接进数据库）
打开属性表
查看Shape 字段
该字段值 = 数据库真实存储EWKB

✅ 无需转换、无精度丢失、完全一致。

六、最终总结（最简背诵版）

数据库存的是EWKB，带4326坐标系头；
坐标小数少一位，Hex完全不一样；
QGIS导出WKT会丢精度，不可用于比对；
逆推Hex必须加 decode(xxx,'hex')，否则endian报错；
想要原始Geom，优先超图Shape字段，不要手动算。

SHP文件与PostGIS数据库Geom字段：WKT和EWKB相互转换SQL