DB2导入和国际

我有一个包含国际文如下DB2导入和国际

+0000000000000010003.,+0000000000000000103.,+0526640777496331405.,+0000000000000000019.,"¿¿¿¿¿¿" 
+0000000000000010020.,+0000000000000000120.,+0526640777496331405.,+0000000000000000019.,"¿¿¿¿¿¿¿¿"

当我的FTP它DB服务器上传的目的，我看到服务器上的一些垃圾字符的CSV文件：

Ã¿Å+0000000000000010003.,+0000000000000000103.,+0526640777496331405.,+0000000000000000019.,"Â³0Â¢0Â°0Ã«0Ã¼0Ã0" 
+0000000000000010020.,+0000000000000000120.,+0526640777496331405.,+0000000000000000019.,"Ã0Ã«0Â·0Ã¼0Â¦0Â§0Â¤0Ã0"

我试过用iconv -f ISO8859-9 -t UTF-8 test/sample_cat_master.csv> test/sample_cat_master_test.csv 但是没有得到结果。我仍然看到垃圾字符。

从该文件导入以下消息： SQL3110N该实用程序已完成处理。从输入文件读取“0”行。

SQL3221W ...开始提交工作。输入记录计数=“0”。

SQL3222W ...任何数据库更改的COMMIT成功。

SQL3149N从输入文件处理“0”行。 “0”行是成功插入表中。 “0”行被拒绝。

来源

2012-01-06 beetri

那件事很可怕。请在将来使用代码标签。 – 2012-01-06 00:37:57

可能有助于了解您的平台 - 例如，iSeries有自己的特殊问题（通常使用“CCSID 037”创建文件）。 – 2012-01-06 16:56:37

由于不正确的代码页翻译导致文件被破坏，因此您需要确定它发生的位置和方式以防止它发生。使用Linux/UNIX实用程序查看和/或编辑文件的尝试也可能是翻译文件的UTF-8字符，因为大多数发行版很少默认为UTF-8代码页。

在涉及数据库之前，尝试以二进制模式对文件进行FTP传输，希望保留UTF-8编码并避免不必要的代码页转换。 od实用程序对于检查使用不同代码页的二进制文件或文本文件的内容特别有用。如果od没有为UTF-8字符显示有效的多字节序列，那么数据库也不可能正确处理UTF-8数据。

哪个代码页是您的DB2数据库的内置使用？如果不是1208（UTF-8），则在使用IMPORT实用程序时可能会遇到其他翻译问题。您可能还需要在客户端环境和DB2注册表中将DB2CODEPAGE设置为1208，并在IMPORT语句的MODIFIED BY部分中设置codepage = 1208。

来源

2012-01-09 00:04:42

DB2导入和国际

回答

相关问题