Troubleshooting
Problem
在进行IMPORT已经EXPORT出来的数据时，可能会出现字符混乱或丢失的情况。本文档介绍了出现乱码的原因和解决方法。
Sumptom
使用EXPORT和IMPORT移动数据时，在IMPORT数据可能会出现以下问题。
- 所有的字符都是乱码
- 一些字符被替换为替换字符(例如，0xFCFC)
- 一些字符被替换
- 列尾的字符被截断。
Cause
每种症状都可能是由以下原因引起的。
- 所有的字都是乱码
EXPORT出来的文件的编码与IMPORT的ODEPAGE不匹配。
(例)以CCSID943(SJIS)形式导出的文件以CCSID 954(EUC-JP)形式导入。 - 有些字符被替换为替换字符(如0xFCFC)
EXPORT出来的文件的代码集比数据库的代码集小。
(例)将代码集1208(UTF-8)的数据导出到943(SJIS)的文件。 - 一部分文字被替换了
EXPORT时的转换规则和IMPORT时的转换规则是不同的。
(例)EXPORT时采用932 ->932(无转换)，IMPORT时采用943 -> 932的转换规则。 - 列后的字符被截断
因为数据库的CODEPAGE和执行EXPORT的CLP的CODEPAGE不同，编码后的字符串长度变长，所以没有输入规则的列长，数据被截断。
Resolving The Problem
EXPORT和IMPORT在数据库代码页和命令行处理器（CLP）的代码页之间进行字符代码转换。
转换分为3种情况，你应该使用适用于你的情况。
附注1:
下面的命令是UNIX/Linux的例子；对于Windows，使用set命令代替导出命令，使用findstr命令代替grep命令。
附注2：
为了体现DB2CODEPAGE向CLP的变化，需要重新启动CLP，db2 terminate命令是用来重新启动CLP的，所以一定要执行。
情况1) EXPORT产地数据库和IMPORT目的地数据库的代码页相同时。
使CLP执行EXPORT和IMPORT的代码页与数据库代码页一致。
执行示例
$ db2 get db cfg for <元データベース> | grep “コード・ページ”
Database code page = 1208
$ db2 get db cfg for <宛先データベース> | grep “コード・ページ”
Database code page = 1208EXPORT
$ export DB2CODEPAGE=1208
$ db2 terminate
$ db2 connect to <元データベース>
$ db2 export to …$ export DB2CODEPAGE=
$ db2 terminateIMPORT
$ export DB2CODEPAGE=1208
$ db2 terminate
$ db2 connect to <宛先データベース>
$ db2 import from …$ export DB2CODEPAGE=
$ db2 terminate情况2) 如果EXPORT源数据库的代码页和IMPORT目的数据库的代码页不匹配
设置只做一次转换。例如，EXPORT会转换到目标数据库的代码页，而IMPORT则不进行转换。
注意：如果目标数据库编码后的字节数较大，且使用了保留源数据库字符串长度的文件格式，如IXF，则必须将源数据库的代码页设置DB2CODEPAGE。例如，如果你在下面的例子中使用IXF文件，你应该指定943而不是1208。
执行示例
$ db2 get db cfg for <元データベース> | grep “コード・ページ”
Database code page = 943
$ db2 get db cfg for <宛先データベース> | grep “コード・ページ”
Database code page = 1208EXPORT
$ export DB2CODEPAGE=1208
->匹配目标数据库的代码页。
$ db2 terminate
$ db2 connect to <元データベース>
$ db2 export to …
-> EXPORT出来的文件的编码为1208（UTF-8）。$ export DB2CODEPAGE=
$ db2 terminateIMPORT
$ export DB2CODEPAGE=1208
-> 匹配目标数据库的代码页。 这样一来，import就不用转换了。
$ db2 terminate
$ db2 connect to <宛先データベース>
$ db2 import from …$ export DB2CODEPAGE=
$ db2 terminate如果你IMPORT到一个字符集较少的数据库，IMPORT目的地无法处理的字符将被替换为替换字符。
为了避免这种情况的发生，IMPORT目的数据库应与EXPORT源相同，或者选择能处理较大字符集的代码集。
情况3) IMPORT目的数据库的字符集比EXPORT源数据库的字符集小时
IMPORT到支持与EXPORT源相同或更大字符集的数据库。
支持日语的主要码页按字符集降序排列为1208（UTF-8）>943（SJIS）>954（EUC-JP）。
操作注意事项
因为DB2CODEPAGE变量有很多考虑，所以暂时设置在环境变量中。
另外，为了体现DB2CODEPAGE向CLP的变化，需要用db2 terminate命令重新启动CLP。
当从ADMIN_CMD( )执行IMPORT或EXPORT时，由于不能明确地指定应用程序的代码页，所以转换的结果是不确定的。
因此，您应该使用MODIFIED BY CODEPAGE选项来明确指定输入/输出文件的代码页。
相关信息
- 如果以IXF格式导出，选择二进制模式将文件传输到另一个系统；如果以DEL和ASC格式导出，选择ASCII模式。
如果不以二进制方式传输IXF，则会出现SQL3089N等IMPORT失败的情况。 - 导出到IXF时，如果转换可能会造成字符截断，将记录SQL3132W警告。 然而，在IC70409 (V9.5FP8)和IC70427 (V9.7 FP4)的故障中，没有显示该警告。
- EXPORT用 "MODIFIED BY CODEPAGE "导出时，会报告出现意外的截断字符。EXPORT WITH “MODIFIEDBY CODEPAGE” MAY TRUNCATE THE DATA. IT04210 (v9.7fp11), IT05377(v10.1fp5), IT06572 (v10.5fp7)这个修复可以防止意外截断的情况发生。因此，当截断可能发生时，可能会记录到以前没有记录的SQL3132W警告。
- SQL3525N CODEPAGE option is incompatible with the LOBSINFILE optionduring IMPORT
DB2 V8与CODEPAGE选项和LOBSINFILE不兼容。在V9及以后的版本中已经解决了这个问题。 - 需要注意的是，IMPORT的MODIFIED BY CODEPAGE选项不能和IXF一起使用，在V8之前，它总是被转换为应用代码页一次。
此外，在 EXPORT中指定 MODIFIED BY CODEPAGE 954 时，报告输出的字符长度数据不正确。
IC77874: INCORRECT EXPORTED DATA LENGTH FOR THE EXPORT COMMAND
SPECIFYING MODIFIED BY CODEPAGE=954
