Shapefile與字符集編碼設置之ArcGIS for Server

         最近剛剛巧兒，連續碰到幾個Shapfile中文亂碼的問題，參照kikita博主在博客空間慕名ArcGIS中的博文《shapefile與字符集編碼設置》，通過在註冊表中導航到計算機 > HKEY_CURRENT_USER > Software > ESRI > Desktop10.3，依次新建項Common，項CodePage，字符串值dbfDefault，設置鍵值爲oem（或936），並重啓ArcMap，從而完美地解決了ArcMap端的顯示問題。

   

      

        原以爲這一亂碼問題就這麼着徹底掀篇了，小編還小小地得意了一把，終於沒我Server啥事兒了。結果，真相曝露的那一瞬——納尼？竟然是這樣的！！！

        當然，我們確實可通過將shapefile導入file geodatabase而後重新加載以繞開這一問題。然而，個性如我，就是不願意走這條康莊尋常路。於是，新一輪的嘗試再次啓動。

        首先，老老實實地邯鄲學步唄。參照ArcGIS for Desktop的解決方案，小編嘗試在註冊表 HKEY_CURRENT_USER > Software > ESRI > Server10.3 下新建項Common、CodePage及字符串值dbfDefault，設置鍵值爲oem（或936），並重啓 ArcGISfor Server。

        其次，邯鄲學步第二式。在註冊表 HKEY_LOCAL_MACHINE > SOFTWARE> ESRI > Server10.3 下新建Common，CodePage及dbfDefault，輸入oem鍵值，重啓 ArcGIS for Server。

        接下來，嘗試修改ArcGIS for Server內置tomcat（默認路徑[ArcGIS Server安裝目錄] \framework\runtime\tomcat\conf）下的server.xml文件，在6080的Connector中添加URIEncoding項並設置爲中文簡體編碼，如GBK或gb2312。雖然心裏明白標註中的中文亂碼顯然和這項設置沒關係，但是實在無法，只能硬着頭皮死馬當活馬醫啦。

        上述諸方法的多次嘗試和確認後，亂碼的問題依然未獲得解決。小編都要忍不住放棄了。

        最後，不得不開始放大招了。小編利用微軟提供的Windows實用工具Process Monitor監控所查看服務的ArcSOC進程的PID值，終於發現，當服務執行ExportMap操作時，服務進程將讀取*.cpg文件和註冊表項 HKU\S-1-5-21-3961182117-3494339963-1454951688-1002\SOFTWARE\ESRI\Server10.3\Common\CodePage。由此可推測Server端編碼的獲取將分爲兩個步驟，首先，讀取隨數據存儲的cpg文件以獲取編碼信息；當檢測到cpg不存在時，則讀取 HKU\S-1-5-21-3961182117-3494339963-1454951688-1002\SOFTWARE\ESRI\Server10.3 下的CodePage。對於當前數據而言，cpg文件必然是不存在的。通過檢查，此處所指向的CodePage也是不存在的。因此，爲了解決這一問題，小編嘗試訪問註冊表，依次導航到HKU即 HKEY_USERS > S-1-5-21-3961182117-3494339963-1454951688-1002 >Software > ESRI > Server10.3，新增Common項，CodePage項，以及字符串值dbfDefault，並將鍵值設置爲oem。

        重啓ArcGIS for Server。耶！問題成功解決。

      

        爲什麼CodePage信息會存儲在HKEY_USERS下的S-1-5-21-3961182117-3494339963-1454951688-1002中呢？利用PsGetsid進行檢測，發現-1-5-21-3961182117-3494339963-1454951688-1002實質對應的就是ArcGIS for Server賬戶arcgis。

        綜上，簡言之，ArcGIS for Server字符編碼的獲取將受限於其賬戶arcgis的字符編碼的設置。也就是說，實質是在用戶環境變量中設置這一字符編碼並確保其生效。

        OK。今天絮絮叨叨了一大堆，希望讀者尚未厭煩。那麼，小編的分析就「咔噠」一聲戛然而止吧。