[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。

转载于:https://www.cnblogs.com/wangyicarter/archive/2012/02/03/2337329.html