Encoding Db2导入和国际化

我有一个包含国际文本的csv文件，如下所示：

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

通过FTP将文件上传到数据库服务器后，我看到一些垃圾字符：

ÿÅ+0000000000000010003.,+0000000000000000103.,+0526640777496331405.,+0000000000000000019.,"³0¢0°0ë0ü0Ã0"
+0000000000000010020.,+0000000000000000120.,+0526640777496331405.,+0000000000000000019.,"Ã0ë0·0ü0¦0§0¤0Ã0"

然后，我尝试使用

iconv

命令修复文件的内容：

iconv-f ISO8859-9-t UTF-8测试/样本\u cat\u master.csv>测试/样本\u cat\u master\u test.csv

它不起作用，我仍然看到垃圾角色

将该文件导入Db2会产生以下消息：

SQL3110N  The utility has completed processing.  "0" rows were read
from the input file.

SQL3221W  ...Begin COMMIT WORK. Input Record Count = "0".

SQL3222W  ...COMMIT of any database changes was successful.

SQL3149N  "0" rows were processed from the input file.  "0" rows were
successfully inserted into the table.  "0" rows were rejected.

---

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

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

---

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

这太可怕了。请以后使用代码标签。这可能有助于了解您的平台-iSeries有自己的特殊问题，例如（通常使用

CCSID 037

创建文件）。