一、基礎說明 新的GDAL版本裡（據說是18以後，這個沒有考證，但下文中就認為18版本以後都這樣），GDAL添加了對UTF8路徑的支持，新增了一個配置項，叫GDAL_FILENAME_IS_UTF8，可以在C#中使用下面的語句設為YES或NO,默認為YES Gdal.SetConfigOption("GDAL_FILENAME_IS_UTF8", "YES"); Gdal.SetConfigOption("GDAL_FILENAME_IS_UTF8", "NO") 當這個值為YES（默認）時，GDAL會認為傳入的路徑字符串是按UTF8編碼的，它會試圖將這個字符串轉到UCS-2編碼下，但我們一般使用的中文路徑都不是UTF8的，就會產生路徑亂碼和無法打開的問題了，可以參考： 《關於GDAL180中文路徑不能打開的問題分析與解決》http://blog.csdn.net/liminlu0314/article/details/6610069 二、在C++下的解決辦法 同樣可以參考上面那篇文章，使用其中的前兩個解決辦法，將GDAL_FILENAME_IS_UTF8值設為NO即可正常讀取中文路徑 三、在C#下的問題（18版本以後） 實際上，在C#下的問題與C++下是不一樣的 首先，成功地編譯後，在C#下引用GDAL的相關DLL讀取中文路徑的文件時，不需要將GDAL_FILENAME_IS_UTF8設為NO（在C#下，將它設置為NO是會出錯的，原因下文分析），在大多數情況下，讀取都是正確的， 只有少數情況會出現問題，那就是：當中文路徑中，出現奇數個中文字符連在一起，而且其後有除“\”之外的符號或字符時，會無法打開，比如說以下幾個示例： [plain] C:\測試路徑\aa.img 中文路徑，中文字符個數為偶數，能夠正常打開 C:\測試文件夾\aa.img 中文路徑，中文字符個數為奇數，但其後為"\"，能夠正常打開 C:\測試文件夾1\aa.img 中文路徑，中文字符個數為奇數，其後不是"\"，無法打開，報錯 C:\testPath\測試檔.img 中文路徑，中文字符個數為奇數，其後不是"\"，無法打開，報錯 四、大多數情況下能夠正常讀取的原因 上文中提到，在GDAL_FILENAME_IS_UTF8值為YES（也就是正常在C#裡使用GDAL庫的情況下），GDAL是會做編碼轉換的，那為什麼這種情況下C#能夠正常讀取中文路徑（大多數情況下）呢？ 打開GDAL的源碼，找到\swig\csharp這個文件夾，這個文件是gdal_csharp.dll等八個C#引用文件的源碼，打開\swig\csharp\gdal\Gdal.cs，找到public static Dataset Open(string utf8_path, Access eAccess)這個函數，內容如下： [csharp] { IntPtr cPtr = GdalPINVOKE.Open(System.Text.Encoding.Default.GetString(System.Text.Encoding.UTF8.GetBytes(utf8_path)), (int)eAccess); Dataset ret = (cPtr == IntPtr.Zero) ? null : new Dataset(cPtr, true, ThisOwn_true()); if (GdalPINVOKE.SWIGPendingException.Pending) throw GdalPINVOKE.SWIGPendingException.Retrieve(); return ret; } 可以看到，在這個函數中，路徑（字符串uft8_path）在傳入後，首先將其進行了重新編碼，即這一語句： [csharp] view plaincopy System.Text.Encoding.Default.GetString(System.Text.Encoding.GetBytes(utf8_path) 再將其傳給C++編寫的實際處理函數，這樣的轉換在\swig\csharp還有很多處，正因為有了這個轉換，C#中使用GDAL時才會能夠正常讀取出中文路徑。 也就是說，在C#中調用GDAL時，GDAL中首先將路徑字符串在C#中轉到UTF-8下，再在C++在將這個UTF-8的代碼轉到UCS-2下，保證能夠正常讀取（暈了沒。。。） 五、為什麼奇數中文字符的情況下又會出現問題呢？ 這個問題嚴格來說其實不是GDAL的錯，而是C#在編碼轉換時出的問題，可以參考： 《淺析GDAL庫C#版本支持中文路徑問題》http://www.cfanz.cn/index.php?c=article&a=read&id=103228 這篇文章分析得十分細致，實驗也非常嚴謹。 總結一下，就是GDAL在的C#代碼中做的這個轉換， System.Text.Encoding.Default.GetString(System.Text.Encoding.GetBytes(utf8_path) 也就是先將字符串轉到UTF-8編碼的Byte[]，再解析為Default編碼（在中文系統中，一般指的是GB2312）字符串的過程中，當遇到奇數中文字符的時候會丟失一個字節的信息，導致傳給GDAL對應C++代碼的路徑參數是錯的，那當然就無法打開了。 （注：其實再嚴格點說起來，這個問題也不是C#的錯，由於不同編碼的編碼規則不同，這個轉來轉去的過程其實本身就是存在很大風險的，很多情況下都是轉不過去的，不能怪人家C#） 六、尋找C#下的解決方案 上面提到的文章雖然分析得十分細致，但很遺憾，它沒有給出比較簡便的解決方案，所以只能靠自己來摸索。 首先，最簡便的解決方案：每次打開之前分析一下路徑，判斷按照上面提到的規則是否會出錯，如果會則提示用戶。。。。。。。這種方法可以解決，但看起來挺不靠譜的 第二，能否找到一種方法，讓其在C#下的編碼轉換過程中不丟字節呢？很遺憾，也沒有能找到實現的方法 第三，既然C++都可以直接跳過這些轉換，那麼C#為什麼不可以呢？於是有了如下的方案，經過簡單測試，是有效的，暫沒有發現連帶問題： 七、最終的解決方案 修改\swig\csharp下的文件，將C#代碼中的編碼轉換部分全部去掉，這部分代碼主要集中在這幾個文件中： \swig\csharp\gdal\Gdal.cs \swig\csharp\gdal\Driver.cs \swig\csharp\ogr\Ogr.cs \swig\csharp\ogr\Driver.cs 將這幾個文件中的System.Text.Encoding.Default.GetString(System.Text.Encoding.UTF8.GetBytes(utf8_path))全部替換為utf8_path 重新編譯（gdal1x.dll不需要重新編譯，只需要重新編譯csharp相關的DLL）即可，這樣，路徑字符串就會不經過轉換直接進行傳遞，但和C++中一樣，這時就需要在程序中將GDAL_FILENAME_IS_UTF8參數設為NO了，不然同樣會讀取出錯
