GDAL C#读取shp中文属性值乱码问题

最新推荐文章于 2024-08-02 23:05:03 发布

箜_Kong

最新推荐文章于 2024-08-02 23:05:03 发布

阅读量7.7k

点赞数 4

分类专栏： GDAL C# 乱码文章标签：乱码 gdal C#

本文链接：https://blog.csdn.net/liminlu0314/article/details/54096119

版权

当使用GDAL的C#版本读取包含中文的shp文件时，可能会遇到属性值显示为乱码的问题。问题出在`Marshal.PtrToStringAnsi`函数上，由于UTF8编码，导致字符串长度计算错误。解决方法是通过循环查找正确长度，或者设置SHAPE_ENCODING配置项以匹配dbf编码，如GBK。修改Ogr.cs和Osr.cs中的相关函数并重新编译可以解决此问题。

摘要由CSDN通过智能技术生成

GDAL的C#版本读取shp中，如果属性值中含有中文，读出来有可能是乱码的问题，根据SWIG生成的C#代码调试发现问题所在，在Ogr.cs文件中有这么一个函数，代码如下：

  internal static string Utf8BytesToString(IntPtr pNativeData)
  {
    if (pNativeData == IntPtr.Zero)
        return null;

    int length = Marshal.PtrToStringAnsi(pNativeData).Length; //问题在这句
    byte[] strbuf = new byte[length];
    Marshal.Copy(pNativeData, strbuf, 0, length);
    return System.Text.Encoding.UTF8.GetString(strbuf);
  }

问题就出现在上面这句中，如果shp文件中dbf的编码是utf-8的时候，pNativeData实际上就是GDAL库读取到的一个const char的地址，这个时候，使用Marshal.PtrToStringAnsi函数返回的长度会变小，下面举个栗子：
如果GDAL的C++库返回的const char pszValue = “中”，那么pNativeData的值实际上就是pszValue这个地址，且用UTF8编码的时候，pszValue指针对应的内存中的信息应该是"E4 B8 AD 00 XX XX"，后面的XX表示其他的东西，只有前四个有用。
这时pNativeData的值就是上面这个"E4 B8 AD 00 XX XX"字符串的地址&#x