最近刚刚巧儿，连续碰到几个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。今天絮絮叨叨了一大堆，希望读者尚未厌烦。那么，小编的分析就“咔哒”一声戛然而止吧。