GeoTools 34-SNAPSHOT版Txt转Shp避坑指南：中文乱码与空间索引问题解决

GeoTools 34-SNAPSHOT版Txt转Shp避坑指南：中文乱码与空间索引问题解决

最近在做一个城市数据分析项目，需要把一批从统计年鉴里导出的、格式简单的文本坐标数据，转换成能在GIS软件里直接加载和分析的Shapefile。听起来是个基础活，对吧？我一开始也是这么想的，直接上手GeoTools，想着几行代码就能搞定。结果，现实给了我当头一棒：生成出来的Shp文件，在QGIS里打开，城市名字全变成了问号“？？？”，更别提后续做空间查询时，那慢得让人怀疑人生的速度。

这让我意识到，从Txt到Shp，远不是“读取-写入”那么简单。尤其是在使用像GeoTools 34-SNAPSHOT这样的前沿版本时，一些默认行为或依赖的细微变化，都可能成为项目中的“暗礁”。今天，我就把自己踩过的坑、摸索出的解决方案，特别是针对中文乱码和空间索引失效这两个最棘手的问题，系统地梳理一遍。如果你也正在或即将进行类似的数据转换工作，希望这篇指南能帮你省下大量调试时间。

1. 理解数据转换的“黑箱”：不仅仅是格式变化

很多开发者容易把Txt转Shp看作一个单纯的格式转换过程，就像把Word文档另存为PDF。但实际上，这背后涉及一系列关键概念的映射和构建，任何一个环节的疏忽都会导致最终结果不符合预期。

首先，我们需要明确Txt文件和Shapefile的本质区别。一个纯文本文件（Txt）本质上是一串字符流，它没有内置的结构化信息来描述数据的几何类型、坐标系或属性字段的类型。而一个Shapefile（.shp及其附属文件）是一个复杂的地理空间数据容器，它必须明确定义几何图形（点、线、面）、空间参考系统（例如WGS84经纬度）以及每个属性字段的名称、类型和长度。

因此，转换过程的核心是为无结构的文本数据“赋予”一个明确的空间数据模型。这个过程可以分解为三个关键步骤：

1. 语义解析：从文本行中识别出哪些列代表X坐标（经度），哪些代表Y坐标（纬度），哪些是属性信息（如城市名、人口）。
2. 几何构造：将解析出的坐标对，使用GeometryFactory等工具实例化为Point、LineString等具体的几何对象。
3. 模式定义与写入：创建一个精确匹配数据结构的SimpleFeatureType（模式），并按照此模式将几何对象和属性值打包成SimpleFeature，最后写入到符合Shapefile规范的存储中。

在这个过程中，有两个问题极易被忽略，却直接影响数据的可用性：字符编码和空间索引。它们不像坐标错误那样立刻导致程序崩溃，而是像“慢性病”，在数据使用阶段才暴露出严重问题。

2. 根治中文乱码：从源头到输出的全程字符集管控

中文乱码是处理本地化数据时最常见的“顽疾”。在GeoTools转换流程中，乱码可能发生在三个环节：源文件读取时、内存中字符串处理时、写入Shapefile时。必须对全链路进行控制。

2.1 诊断乱码根源：你的文件到底是什么编码？

第一步，永远不要假设你的文本文件是UTF-8。它可能是GBK、GB2312，甚至是带BOM的UTF-8。用错误的编码去读取，第一步就错了。我推荐一个简单实用的Java方法来探测文件编码：

public static String detectFileEncoding(File file) throws IOException {
    try (BufferedInputStream bis = new BufferedInputStream(new FileInputStream(file))) {
        byte[] bom = new byte[3];
        bis.mark(3);
        int read = bis.read(bom);
        bis.reset();

        // 检查BOM (Byte Order Mark)
        if (read >= 3 && bom[0] == (byte) 0xEF && bom[1] == (byte) 0xBB && bom[2] == (byte) 0xBF) {