[GIS筆記] SHP 轉檔的亂碼陷阱：從「百年舊堤」案例看編碼偵測的重要性
在將既有的 GIS 開放資料（如 QGIS 專案中的 Shapefile）整合進 WalkGIS 系統時，最常遇到的挑戰往往不是座標轉換，而是文字編碼（Encoding）。 最近在處理「濁水溪流域情報地圖」中的「百年舊堤」圖層時，我遇到了一個經典的亂碼案例。這篇文章將紀錄問題的成因、誤判的過程，以及最終的正確解法，作為未來處理 GIS 舊資料的參考。 案例背景 我試圖將一份名為 23座百年舊堤.shp 的檔案匯入我的 WalkGIS SQLite 資料庫。 1. 初次嘗試：預設轉檔的失敗 一開始，我直接將 SHP 轉為 KML/KMZ 進行預覽。結果在 KML 中，所有的堤防名稱都變成了無法辨識的亂碼，如： 偌 這些字並不是常見的「」或亂數，而是顯示為 PUA (Private Use Area) 區域的罕見字元。這是一個強烈的訊號，代表編碼解讀錯誤。 2. 直覺誤判：這一定是 Big5 台灣早期的 GIS 資料（尤其是政府開放資料），絕大多數的 .dbf 屬性表都使用 Big5 (CP950) 編碼。當看見中文變亂碼時，直覺反應通常是：「啊，這一定是工具用 UTF-8 去讀 Big5 造成的。」 於是我在 Python 腳本中強制指定了編碼： # 錯誤的嘗試 gdal.SetConfigOption("SHAPE_ENCODING", "CP950") 結果出乎意料：亂碼依然存在，甚至變成了另一種形式的亂碼。如果您嘗試用各種 Big5/Latin1 交叉解碼都無效，那問題可能比想像中複雜。 真相：雙重編碼災難 為了找出真相，我使用 ogrinfo 指令進行了雙盲測試（A/B Testing）： 測試 A：指定 CP950 ogrinfo -al -so --config SHAPE_ENCODING CP950 "23座百年舊堤.shp" > Name (String) = 偌 (亂碼) 測試 B：不指定 (預設/UTF-8) ...