GDAL在GIS界是赫赫有名的，它即有操作柵格的GDAL組件，又有讀取矢量的OGR類庫，可謂"文武雙全"，連 ESRI也在使用，跨平台、開源、支持數據格式多、操作效率高……異常強勢！
畢竟是外國的東西，會有那么一點水土不服，那就是編碼問題。強大的開源的組件好像都有這個毛病，仔細想想python、sqlite、qt、qgis、gdal……
問題描述
使用C#+GDAL訪問中英文路徑的shp和gdb都不存在問題，可打開中文路徑的mdb直接報錯。System.ApplicationException:"Unable to initialize ODBC connection to DSN for DRIVER=Microsoft Access Driver(*.mdb);DBQ=….."
顯示是亂碼了，搜遍網絡，幾乎沒有人提出過打開mdb有異常，更別說解決方案；關於亂碼，要么說C++，要么講shp。轉載的文章總是千篇一律，有用的方法萬里難挑一。只有李民錄大佬認真分析過，可他給的轉換編碼方案也不適用。絕大多數給的方案是，添加如下代碼：
//方案一
OSGeo.GDAL.Gdal.SetConfigOption("GDAL_FILENAME_IS_UTF8", "YES");
//方案二
OSGeo.GDAL.Gdal.SetConfigOption("GDAL_FILENAME_IS_UTF8", "NO");
由於GDAL版本眾多，方案一和方案二的設置都是沖突的，我也是醉了，對1.9、2.2、2.4版本的GDAL都無法解決mdb中文路徑問題。
問題分析
分析1：類庫版本比較
花光了CSDN上所有的積分，下載所謂解決了中文路徑問題多個版本，問題依舊。
分析2：數據路徑比較
string gdbPath1 = @"D:\Data\全國行政區划.gdb";（√） string gdbPath2= @"D:\Data\china. gdb";（√） string shpPath1 = @"D:\Data\全國行政區划\省.shp";（√） string shpPath2 = @"D:\Data\china\p.shp ";（√） string mdbPath1 = @"D:\Data\全國行政區划.mdb";（Х） string mdbPath2 = @"D:\Data\國行政區划.mdb";（Х） string mdbPath3 = @"D:\Data\China.mdb";（√）
測試發現，凡是帶中文的mdb都不行，與字符數奇偶無關。
分析3：編碼方式比較
測試比較默認編碼(GBK2313)、UTF-8、UTF-16，確實可能是因為編碼不同導致轉換異常，我們來看源碼中關鍵方法Open，要求輸入utf8_path，然后第一句就直接將輸入路徑轉為utf8字節，不管你輸入的啥子，直接一頓猛如虎的操作，當作UTF8進行處理，這就是中文路徑報錯的原因。首先想到就是把含有中文的路徑直接轉換為utf8，但這里有一個重大bug，C#的變量路徑都是ANSI編碼，不存在轉換問題，只能轉字節的編碼，不能轉字符串的編碼。
解決方案
即在是編碼錯誤轉換，那直接改成轉換成默認編碼好了。
修改前：將Ogr.StringToUtf8Bytes(utf8_path)
修改后：System.Text.Encoding.Default.GetBytes(utf8_path)
但測試后發現，gdb和shp又找不開了，真是"牛鞭不滑馬鞭滑"（形容問題處理后又導致了新問題的一句土話）。理論上，mdb,gdb,shp應該是一樣的問題才對，真不知里面是怎么處理的。無奈，暫時通過判斷輸入路徑是否為mdb來判斷是否修改，如下：
修改后的dll（只修改ogr_csharp.dll）和測試demo：https://wwa.lanzous.com/izGtYh0ntva
里面還解決了兩個問題：
中文屬性編碼問題：https://www.cnblogs.com/liweis/p/13747862.html
中文圖層編碼問題：https://www.cnblogs.com/liweis/p/13747872.html