exp utf8->us7ascii imp us7ascii->utf8 中文为什么没有乱码?

zergduan

这样看就可以

zergduan

US7ACSII 有00~ff所有单位编码，所以你导出肯定不需要做编码替换，所以整个编码都被正常导出了。同时导入的时候由于US7ASCII是所有字符集的子集，也是UTF8的子集，一样不需要编码转换，直接把编码写入了。因此，不会丢失任何编码

chen222246lei

我在网上看到了有人反映,数据库字符集是ZHS16GBK, 客户端为US7ASCII时, 会乱码, 我做了一个新测试, 新建一个数据库, 把数据库字符集设置为ZHS16GBK, 测试结果仍然没有出现乱码, 我有一点疑问. US7ASCII所包含的编码范围应该是ORACLE中最小的字符集了. 如果US7ASCII都可以做到转换无乱码, 那么其他字符集也不会出现乱码. 所以我又把客户端字符集设置为WE8ISO8859P1, 其结果能够正常显示汉字.  

chen222246lei

我觉得一定是自己那个地方没弄清楚. 目前测试情况来看. 下面这些情况都不会出现乱码
源数据库         客户端             目标数据库     结果
AL32UTF8        US7ASCII             AL32UTF8       正常
AL32UTF8      WE8ISO8859P1      AL32UTF8       正常
ZHS16GBK        US7ASCII             ZHS16GBK       正常
ZHS16GBK        WE8ISO8859P1    ZHS16GBK       正常

lnwf5188588

chen222246lei 发表于 2018-1-11 15:39
我觉得一定是自己那个地方没弄清楚. 目前测试情况来看. 下面这些情况都不会出现乱码
源数据库         客 ...

这里的客户端nls_lang和客户单操作系统的字符集是一致的吧？

zergduan

chen222246lei 发表于 2018-1-11 15:35
我在网上看到了有人反映,数据库字符集是ZHS16GBK, 客户端为US7ASCII时, 会乱码, 我做了一个新测试, 新建一 ...

你说的有2个错误

1. 虽然US7ASCII是最小字符集，但是他包含了全部单位字符编码（看我上面的解释）
2. 所谓的出现乱码，是因为字符替换，你看到乱码是因为转换后发生了字符替换，替换字符是一个通用图形（乱码），但是exp/imp 并没有显示字符，所以你“看不到”乱码，单位字符被全部覆盖，所以编码在这个过程中也不会被替换。

zergduan

lnwf5188588 发表于 2018-1-11 18:13
这里的客户端nls_lang和客户单操作系统的字符集是一致的吧？

他说的是导出/导入时设置的NLS_LANG,此时设置的这个变量与操作系统无关（因为不需要用来显示字形）仅供Oracle来判断是否被要求做字符转换。

chen222246lei

zergduan 发表于 2018-1-11 18:32
他说的是导出/导入时设置的NLS_LANG,此时设置的这个变量与操作系统无关（因为不需要用来显示字形）仅供Or ...

意思我懂了, 也就是说只要字符集提供了所有字符的编码(0x00 ~ 0xff) 那么即使编码没有对应正确的字符, 那么转换也不会有任何问题. 那么验证方法也很简单, 只要找出没有提供全字符编码的字符集做个测试即可. 那么我如何知道那种字符集没有提供全字符编码呢? 请问那个local build查看字符集提供的编码是如何使用的呢?

dhhb

dmp文件是二进制的，只要你源数据库和目标数据库的字符集一致，就不会有乱码，只有存储过程里的注释，导出时不是byte,会产生乱码，exp的nls_lang，不会对表的数据做转换.

chen222246lei

dhhb 发表于 2018-1-12 10:41
dmp文件是二进制的，只要你源数据库和目标数据库的字符集一致，就不会有乱码，只有存储过程里的注释，导出 ...

源数据库和目标数据库字符集不一致,使用US7ASCII转换也不会出现乱码.
测试环境:
源数据库 AL32UTF8
客户端字符集: US7ASCII
目标数据库: ZHS16GBK
测试结果完全没有问题,