[Configuration][Informatica] [ZT] Informatica Code Page字符集设置总结
http://www.cnblogs.com/wangyicarter/archive/2012/02/03/2337306.html
在上文Informatica的配置过程,对于字符集如何设置并未结束,附下文对字符集设置进行说明
从数据通路的角度看,Informatica中数据的流向是:Source Storage ->Transformations->Target Storage。为了保证数据不至于丢失,靠后的target的字符集需要兼容靠前的source的字符集。如下图:
整个ETL的数据流动过程都是由Integration Service(下文简称IS) Process来完成。当Informatica与数据库交互时,因为会用到数据库的client driver,所以,运行IS Process的服务器的数据库客户端设置会影响到Informatica与数据库的数据交换。因为数据经历了如下流向:Database A Server->Database A Client->IS Processà Database B Client->Database B Server。当Informatica从Flat File加载数据时,则需要指定文件使用的字符集。它的数据流向是:Flat File->IS Process->Database A Client->Database A Server。
IS Process可以以两种方式move数据:ASCII和UNICODE。ASCII模式下,IS Process不会做character conversion,即input的binary流是什么样子,output什么binary流。而在UNICODE模式下,Informatica会检查source和target的字符集是否兼容,重要的是IS Process会做character conversion,在其内部以UTF8方式传输数据。
因为Informatica的Client需要和Repository Database交互,所以它们的字符集需要和Repository Database的一致或为对方的子集。Informatica的Client包括:IS Process、PowerCenter Designer、PowerCenter Workflow Manager等。一般Informatica的Client的字符集设置是跟着运行该Client的本地OS走的,例如:运行在简体中文的Window上运行PowerCenter Designer,此时它使用的code page是“MS Windows Simplified Chinese”;而在英文系统Window上运行IS Process,那么它使用的code page就是“MS Windows Latin 1 (ANSI)”。在Unix系统上的Client同样道理。Informatica的Client字符集设置,不影响数据在Informatica的ETL过程,只是影响它们自己和Repository Database的数据交换。
案例分析
案例I
环境:
Source:Oracle Database(UTF8)
Target:Oracle Database(UTF8)
IS Process Code Page:MS Windows Latin 1 (ANSI)
IS Movement Mode:ASCII
NLS_LANG:AMERICAN_AMERICA.WE8MSWIN1252
Mapping设置:
Source Connection Code Page=UTF8
Target Connection Code Page=UTF8
ETL结果:
中文为乱码
分析:
因为NLS_LANG设置的是WE8MSWIN1252,虽然Source Connection Code Page和Oracle Database Server都使用UTF8编码,但是在从DB Server->DB Client时乱码已经产生,Informatica的Source Connection拿到的就是乱码了。
解决:
修改NLS_LANG为“AMERICAN_AMERICA.AL32UTF8”或者“AMERICAN_AMERICA.ZHS16GBK”。此时,IS Movement Mode是ASCII还是Unicode都可以。
解释:
在IS Movement Mode=ASCII情况下,Source/Target Connection Code Page设置为“UTF8”、 “GBK”或者“ISO8859-1”等都可以,因为此时DB Server->DB Client和DB Client->DB Server不会发生数据丢失和乱码,同时Informatica不会去转码。这保证DB ClientàIS ProcessàDB Client过程中binary数据流没有发生变化。
在IS Movement Mode=UNICODE情况下,就不同了,此时Source/Target Connection Code Page的设置必须与DB Client的编码保持一致,否则IS在转码的时候就会出现问题。
案例II
环境:
Source:Flat File(UTF8)
Target:Oracle Database(UTF8)
IS Process Code Page:MS Windows Latin 1 (ANSI)
IS Movement Mode:ASCII
NLS_LANG:AMERICAN_AMERICA.ZHS16GBK
Mapping设置:
Source Flat File=UTF8
Target Connection Code Page=UTF8
ETL结果:
中文为乱码
分析:
因为NLS_LANG设置的是ZHS16GBK,而IS Movement Mode=ASCII,此时IS Process不会转码,以至于IS ProcessàDB ClientàDB Server时,DB Client将原本UTF8的数据按照GBK编码提交DB Server,结果乱码产生。
解决:
方法一:修改NLS_LANG= AMERICAN_AMERICA.AL32UTF8。
方法二:修改IS Movement Mode=UNICODE,并保证Target Connection Code Page的设置必须与DB Client的编码保持一致,因为此时Informatica是将IS内部的UCS-2编码转为Target Connection Code Page再提交给DB Client。
对应表
注:Source和Target的编码都为UTF8。