Informatica导入SQL Server中日文特殊字符乱码及代码页兼容问题

根因说明 #

乱码和代码页报错本质是两个问题叠加：一是全链路字符集配置不统一触发兼容校验失败，二是目标端写入时字符串按非Unicode类型传参，效果等同于手动执行INSERT时漏加N前缀，特殊字符被转码丢失。

第一步：回退错误配置，修复代码页不兼容报错 #

• 先将之前随意调整的所有代码页配置全部恢复为默认值，清除自定义配置冲突
• 统一全链路三个核心节点的代码页为完全相同的Unicode兼容编码：Informatica 10.2及以上版本统一选UTF-8，低版本统一选UTF-16LE，三个节点分别是：
  • Integration Service集成服务的运行代码页
  • 源数据连接、SQL Server目标连接的代码页配置
  • 源库、目标SQL Server库的默认字符集/排序规则配置
• 重新在Workflow Manager执行任务校验，确认无代码页不兼容类报错后再进行后续配置。

第二步：配置目标端自动实现N前缀写入效果，解决乱码 #

不需要手动给每个值加N前缀，按以下配置即可实现同等写入效果：

• 替换SQL Server目标连接驱动：优先使用ODBC Driver 17/18 for SQL Server，弃用老旧的SQL Server Native Client驱动
• 打开目标连接的高级配置项，勾选*Support Unicode（支持Unicode）*开关：开启后驱动会自动将所有字符串参数按Unicode类型传递给SQL Server，等价于INSERT语句中字符串前加N前缀的效果
• 校验目标表字段类型：存储中日文内容的字段必须使用nchar/nvarchar/ntext这类Unicode类型，禁止使用char/varchar/text非Unicode类型——即使传参加了N前缀，字段本身不支持Unicode也会存为乱码
• 如果使用自定义SQL模式写入，不要手动拼接字符串，保持参数为Unicode类型即可，参考写法：

-- 错误写法：参数按非Unicode类型解析，特殊字符丢失
INSERT INTO TargetTable (MultiLangContent) VALUES (?)

-- 正确写法：显式指定参数为NVARCHAR类型，和N前缀效果一致
INSERT INTO TargetTable (MultiLangContent) VALUES (CAST(? AS NVARCHAR(4000)))

常见避坑点 #

• 禁止只修改单个节点的代码页：比如仅修改目标连接代码页、不修改集成服务代码页，必然触发代码页不兼容报错
• 不要在转换逻辑中随意使用转码函数：比如自定义TO_CHAR()加编码参数转码，很容易提前将中日文转成乱码
• 如果源是平面文件，平面文件对象的代码页必须和文件实际存储编码一致，比如UTF-8保存的CSV文件就选UTF-8代码页，不要错选GBK编码。

内容的提问来源于stack exchange，提问作者HelloWorld