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。今天絮絮叨叨了一大堆,希望读者尚未厌烦。那么,小编的分析就“咔哒”一声戛然而止吧。


文章来源:http://blog.csdn.net/zssai2015/article/details/49703105

2 个评论

这绝对是干货!
厉害

要回复文章请先登录注册