浅析GDAL库C#版本支持中文路径问题（续）

上篇博客中主要说了GDAL库C#版本中存在的问题，其表现形式主要是：“文件名中的汉字个数是偶数，完全没有影响，读取和创建都正常，如果文件名中的汉字个数是奇数，读取和创建都会报错。”

针对这个问题，今天仔细研究（查看+折腾）了下C#程序中string类型的默认编码方式。首先通过下面的代码进行检测C#程序中string类型的默认编码方式是什么。

static void Main(string[] args)
{
       string s = "我";
 
       // 首先获取默认编码的字节及其长度，并输出
       byte[] bDefault =Encoding.Default.GetBytes(s);
       Console.WriteLine(bDefault.Length);
       foreach (byte b inbDefault)
       {
              Console.WriteLine(b);
       }
 
       // 接下来获取Unicode编码的字节及其长度，并输出
       byte[] bUnicode =Encoding.Unicode.GetBytes(s);
       Console.WriteLine(bUnicode.Length);
       foreach (byte b inbUnicode)
       {
              Console.WriteLine(b);
       }
 
       // 接下来获取UTF8编码的字节及其长度，并输出
       byte[] bUTF8 =Encoding.UTF8.GetBytes(s);
       Console.WriteLine(bUTF8.Length);
       foreach (byte b inbUTF8)
       {
              Console.WriteLine(b);
       }
 
       // 最后获取936编码（即GB2312）的字节及其长度，并输出
       byte[] b936 =Encoding.GetEncoding(936).GetBytes(s);
       Console.WriteLine(b936.Length);
       foreach (byte b in b936)
       {
              Console.WriteLine(b);
       }
}

            在XP64位中文操作系统与Win764位英文操作系统上运行过上面的代码片段，我们通过查看四个byte数组中的值，分别如下图所示。截图上面是十进制显示，下半部分为十六进制显示。

从上图可以清楚的看出，C#中对于汉字的默认编码应该使用的是GB2312（936）编码。这个默认的编码与操作系统也没有关系。

知道了系统默认的汉字编码方式，那么下面就来看看昨天的问题，使用代码System.Text.Encoding.Default.GetString(System.Text.Encoding.UTF8.GetBytes(utf8_path))转换后的编码到底变成了什么编码。使用下面的代码片段进行测试：

static void Main(string[] args)
{
       string s = "我";
       string strTEmp = System.Text.Encoding.Default.GetString(System.Text.Encoding.UTF8.GetBytes(s));
       byte[] bDefault =Encoding.Default.GetBytes(strTEmp);
       Console.WriteLine(bDefault.Length);
       foreach (byte b inbDefault)
       {
              Console.WriteLine(b);
       }
 
       Console.WriteLine(strTEmp);
}

           通过监视查看发现通过上面的代码转换之后的字节与UTF8前两个一致，但是第三个已经变成了ASCII码中的63即问号“?”，但是系统当前认为字符串依旧是GB2312的编码，所以字符串出现了乱码。如下图所示。

接下来我们再看看这个字符串通过swig封装之后，传入GDAL库之后的C++语言对应的字节编码是什么，使用前两篇博客中的跨语言调试方式，直接将上面的字符串“我”用Ogr.Open函数打开，然后在C++库中的文件gdal-1.10.0portcpl_vsil_win32.cpp中的函数VSIVirtualHandle*VSIWin32FilesystemHandler::Open( const char *pszFilename,   const char *pszAccess )处添加断点来查看传入的字符串，如下图所示：

转换前后的字符串及其字节码如下：

通过对比这个图与上面C#的字节码，发现了一个问题。C#中的bDefault字节码是（230、136、63）转换为16进制为（0xe6、0x88、0x3f）与C++库中传入的字节码一致（pszFilename）。这也就是说，通过swig封装并传入C++库后，编码保持不变，依旧是那个错误的编码。也就是说通过代码System.Text.Encoding.Default.GetString(System.Text.Encoding.UTF8.GetBytes(utf8_path))进行转换造成了编码错误，那么只需要修改这里，不让他进行转码或者在将Default改成UTF8应该就行了。

按照这个思路，将swigcsharp目录下的所有的System.Text.Encoding.Default.GetString(System.Text.Encoding.UTF8.GetBytes(utf8_path))都改成System.Text.Encoding. UTF8.GetString(System.Text.Encoding.UTF8.GetBytes(utf8_path))进行测试。

共需改动的文件不多，共有四个文件，如下图所示：

修改时，使用批量替换即可。修改完重新编译GDAL的C#库，然后将编译好的八个dll重新加入工程中，按照上面的步骤再次进行调试。进入C++的代码中，监视编码转换前后的值的变化。如下图所示。

从上图可以看出，这里传入的字符串pszFilename的编码已经变成了(0xce、0xd2)，这个编码就是C#里面的默认编码或者GB2312编码，也就不是UTF8编码了。那么我们就可以通过设置GDAL_FILENAME_IS_UTF8=NO来进行读取了。

接下来，我们使用一个原来不能打开的路径，然后将GDAL_FILENAME_IS_UTF8设置为NO，进行测试。调试代码如下图所示，从图中可以看出，原来不能打开的shp已经正常打开。

控制台输出的信息为：

经过测试，这样修改可以支持所有的中文及其英文路径了。测试环境为Xp64位中文操作系统与Win764位英文操作系统。

我已经将修改后的C#版本的8个dll打包上传至CSDN资源和qq群共享，直接替换之前GDAL110版本里面的原来的dll即可。CSDN下载地址为：http://download.csdn.net/detail/liminlu0314/5809463