geo下载的数据乱码

最近好几个搞测绘的朋友，还有做GIS开发的同行，私底下都在吐槽这事。

就是那种从特定地理信息平台拉下来的数据，或者用geo工具抓下来的矢量、栅格数据，一打开，好家伙。

全是问号，或者一堆看不懂的符号。

明明文件名看着挺正常，坐标范围也在地球上，但就是打不开，或者画出来一团黑。

这真不怪软件，也不全怪你手气不好。

geo下载的数据乱码

这背后通常就三个原因，我按概率从高到低给你捋一捋。

首先，最坑人的，是编码没对上。

你以为你下的是UTF-8，其实源数据可能是GBK，甚至是GB2312。

很多国外的geo数据源，或者一些老旧的地方政务数据，它们根本不讲国际通用标准。

我去年帮一个做房产测绘的哥们儿处理数据，那个CAD图层导出来全是方块。

后来一查，源文件里有个字段存的是“姓名”，结果服务器端用了Shift-JIS编码，传到咱们这边解码直接炸了。

怎么破？

别急着重装软件。

先用十六进制编辑器，比如Notepad++，打开原始文件看看头几个字节。

如果是中文项目，大概率是ANSI编码问题。

这时候用iconv或者专门的转换工具，强行转一下码。

有个小技巧，如果你在linux下，可以试试iconv -f gbk -t utf8，亲测有效。

其次，坐标系统被魔改了。

这个更隐蔽。

有些geo下载的数据，表面上看着是WGS84，实际上经过了一个私有的投影变换，而且还没存参数。

你直接用标准工具加载，它会按默认规则硬套，结果数据就飞了。

有的甚至直接偏移了，你看着在海南，实际上人在东北。

这种情况下，数据本身没错，是你的“尺子”不对。

一定要找数据提供方要元数据，或者直接问他们的EPSG码到底是多少。

别听网上那些所谓的一键自动识别，那玩意儿准确率也就三四成。

我见过最离谱的，是一个地方自然资源局给的数据，他们说“这是标准经纬度”。

结果一画，整个城市往西北偏了20公里。

最后发现是他们内部用了一个未公开的高斯-克吕格变种投影，中央经线都改了，但参数没给全。

geo下载的数据乱码

这种时候，你得用控制点反算。

找几个已知坐标的点，套进去算出七参数或者四参数转换系数。

虽然麻烦，但这是唯一正路。

再者，就是文件头损坏。

下载过程中断，或者网络波动，导致shp文件的.cpg编码描述文件缺失，或者.prj坐标系统文件丢了一半。

这种情况下，数据主体还在，但说明书没了。

你可以尝试用ArcGIS或者QGIS里的“修复几何结构”功能。

有时候，哪怕你什么参数都不填，光跑一遍修复，软件也能把丢失的索引补全，数据就能显示出来了。

我一般建议，遇到这种情况，先备份原文件。

然后在副本上动手，千万别直接在原文件上改。

我有个教训，以前为了图省事，直接覆盖了，结果改坏了，找数据源方重新下，等了两周。

数据源方那帮人，响应速度有时候比蜗牛还慢。

还有个细节，很多人忽略。

有些geo平台下载的数据，其实是zipped的shp，或者是tar.gz格式。

解压的时候，如果你用的是Windows自带的解压器，可能会把某些二进制文件误识别。

特别是文件路径里如果有中文，解压后路径变长，导致文件指针错位。

我见过好几次，解压后shx索引文件比shp文件还小，这时候直接报“invalid header”。

解决办法？

换7-zip，或者用命令行tar解压。

并且，确保你的工作目录里，shp, shx, dbf, prj, cpg这几个文件是成套的。

少一个都不行，尤其是cpg，它决定了属性的文字编码。

没有cpg文件，ArcGIS通常默认UTF-8，如果源数据是别的编码，属性表必乱。

你可以手动新建一个文本文件，内容写UTF-8，或者GBK，改后缀为cpg，跟其他文件放一起。

这招简单粗暴，有时候真管用。

所以，面对geo下载的数据乱码，别焦虑。

它不是玄学，是工程问题。

编码、坐标、文件完整性，查这三样，基本能解决90%的问题。

剩下的10%，可能是源数据本身就错了。

那种情况，只能找上游要修正版。

最后唠叨一句，做数据处理，留痕最重要。

每一步操作，记下来。

哪天出了问题，能回溯，才不容易抓瞎。

这行干久了就会发现，数据这东西，比你想象的脆弱多了。