之前一直把postgreSQL搁置了，原因是用PostGIS的shp2pgsql把shapefile导入psql时由于中文字符编码问题停滞不前，用-W
"GBK"参数控制CLIENT_ENCODING能够正常导出中文，但只能导出部分数据，然后就报错，其他编码都不可以，尝试过几乎所有与中文有关的编码（GB18030,GBK,GB2312等）。这次再次鼓起勇气来查找问题，出于三点考虑：
1）stinjia指点说GBK是可以的，并且他有成功的先例。
2）查看了大量Mailing
Lists记录，几乎所有关于shp2pgsql编码问题的记录都在最后-W处或前期相关方案中得到了终结，没有人遇到像我这样似解决但没解决的问题的。
3）既然中文编码可以导出，就没道理中途出错（大概9000多条记录处出错）。
4）当前阶段，在不同环境下，忍受不了庞大的Oracle给电脑和我脆弱心灵带来的负担。
这几点理由也让我一改以往对shp2pgsql能力的怀疑，把矛头指向了源数据本身。回想一下，只有shapefile文件的属性数据表（.dbf）中有中文，于是下载了专门的DBF编辑工具查看.dbf文件（Access在这方面令人不满），查看报错的那一行，果然，该记录的名称字段里最后有一个行似“口”字的非汉字字符，删掉该字符，便可以导出该记录，用同样的方式还找出了其他几处错误，排除所有类似问题，终于导出了全部两万余条记录。
数据是WGS84下的，所以SRS为4326，用-s参数，-W指明源数据shapefile的dbf文件所用的字符编码。这个参数能保证识别正确的编码，并且会在所生成的SQL文件的开头插入一句：“SET CLIENT_ENCODING to UTF8”，以便能够将再次将数据数据从UTF8转换成任意编码（你的数据库内部所使用的编码）。为了避免麻烦，我一开始就将数据库服务端编码设置为了UTF8。
第一步是将所有数据导入blocks.sql文件，这个文件中的SQL文件主要完成两件事：1）创建数据表blocks并建立包含geometry在内的相关字段；2）逐条插入数据。
$ sudo shp2pgsql -s "4326" -W "GBK" blocks.shp blocks
> blocks.sql
Shapefile type: Polygon
Postgis type: MULTIPOLYGON[2]
第二步是执行blocks.sql，将数据贯如postgreSQL的数据库中(nj)。
$ sudo psql -d nj -f blocks.sql
搞定！搞了半天还是自己数据的错，数据生产单位需要谨慎处理每一个细节，但真有了失误，有时候还真要命。
以前用ArcView的时候也发现过它处理中文字符时的问题，中文时常显示不正常，尤其是在某些分析过程的对话框中，也许是编码功能做得不好的原因，需要非常谨慎地操作每一步才会保证没错，在单纯的软件意义上，ESRI还有待提高。上面那种非汉字字符以前也见过，就是没有想到问题会在这里。另外，Oracle Spatial也有shapefile到database geometry的导入导出工具，之前使用同样的问题数据，都能正常导入，错误记录没有被忽略，也没中途报错，只是是错误本身被忽略，这应该归功于Oracle工具代码的健壮性，不过也有知情不报之嫌～～太能容错了，也会误导开发人员：）