刚才有一个帖子讨论到字符集的问题。

此前我在文章中提到过这些问题:
http://www.eygle.com/special/NLS_CHARACTER_SET_05.htm

发现刚才问题的原因在于Solaris/Linux上od命令的输出不同导致:

QUOTE:

---

最初由 orientzkd 发布


eygle的那篇文章也是在oracle9.2下测试的。我是在oracle10下做的。
你说“alter改字符集必须是单字节对单字节两个对两个,“那么为什么US7ASCII 可以用alter database character set ZHS16GBK。这也是单字节向双字节转换阿。

---

这个问题的原因在于OD命令在不同的平台下缺省的输出结果是不同的。

我当初的测试结果是Solaris下的输出：

PHP code:



$ cat a.dmp|od -x|head


0000000 03'03 54'45 5850 4f52 543a 5630 392e 3032


0000020 2e30 300a 4445 5947 4c45 0a52 5553 4552


0000040 530a 3130 3234 0a30 0a33 320a 300a 0354


0000060 0354 07d0 0001 0000 0000 0000 0000 0005


0000100 0020 2020 2020 2020 2020 2020 2020 2020


0000120 2020 2020 2020 2020 2020 2020 2020 2020


0000140 2020 2020 2020 2020 2053 756e 2053 6570


0000160 2034 2031 313a 3238 3a33 3720 3230 3035


0000200 612e 646d 7000 0000 0000 0000 0000 0000


0000220 0000 0000 0000 0000 0000 0000 0000 0000


.

而在Linux下od的输出和Solaris是不同的:

PHP code:



[oracle@danaly ~]$ cat a.dmp|od -x|head


0000000 0303 4554 5058 524f 3a54 3156 2e30 3230


0000020 302e 0a31 5344 5359 4554 0a4d 5552 4553


0000040 5352 380a 3931 0a32 0a30 3032 300a 030a


0000060 0354 0754 00d0 0001 0000 0000 0000 0000


0000100 0005 2020 2020 2020 2020 2020 2020 2020


0000120 2020 2020 2020 2020 2020 2020 2020 2020


0000140 2020 2020 2020 2020 2020 6f4d 206e 6553


0000160 2070 2034 3131 323a 3a33 2035 3032 3630


0000200 2e61 6d64 0070 0000 0000 0000 0000 0000


0000220 0000 0000 0000 0000 0000 0000 0000 0000


.

注意Linux下od -x等加于-t x2

PHP code:



[oracle@danaly ~]$ cat a.dmp|od -t x2|head


0000000 0303 4554 5058 524f 3a54 3156 2e30 3230


0000020 302e 0a31 5344 5359 4554 0a4d 5552 4553


0000040 5352 380a 3931 0a32 0a30 3032 300a 030a


0000060 0354 0754 00d0 0001 0000 0000 0000 0000


0000100 0005 2020 2020 2020 2020 2020 2020 2020


0000120 2020 2020 2020 2020 2020 2020 2020 2020


0000140 2020 2020 2020 2020 2020 6f4d 206e 6553


0000160 2070 2034 3131 323a 3a33 2035 3032 3630


0000200 2e61 6d64 0070 0000 0000 0000 0000 0000


0000220 0000 0000 0000 0000 0000 0000 0000 0000


.

显示结果中，高位和低位发生了交换。
所以0303 4554 ,应该为: 0303 5445

oracledba 说的使用 -t x1参数可以得到更直观的输出，更适合在Linux下使用:

PHP code:



[oracle@danaly ~]$ cat a.dmp|od -t x1|head


0000000 03 '03 54' 45 58 50 4f 52 54 3a 56 31 30 2e 30 32


0000020 2e 30 31 0a 44 53 59 53 54 45 4d 0a 52 55 53 45


0000040 52 53 0a 38 31 39 32 0a 30 0a 32 30 0a 30 0a 03


0000060 54 03 54 07 d0 00 01 00 00 00 00 00 00 00 00 00


0000100 05 00 20 20 20 20 20 20 20 20 20 20 20 20 20 20


0000120 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20


0000140 20 20 20 20 20 20 20 20 20 20 4d 6f 6e 20 53 65


0000160 70 20 34 20 31 31 3a 32 33 3a 35 20 32 30 30 36


0000200 61 2e 64 6d 70 00 00 00 00 00 00 00 00 00 00 00


0000220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


.

By default, od uses -A o -t d2 -w 16.
-x Output as hexadecimal shorts. Equivalent to -t x2.

[QUOTE]最初由 eygle 发布
刚才有一个帖子讨论到字符集的问题。

此前我在文章中提到过这些问题:
http://www.eygle.com/special/NLS_CHARACTER_SET_05.htm

发现刚才问题的原因在于Solaris/Linux上od命令的输出不同导致:



这个问题的原因在于OD命令在不同的平台下缺省的输出结果是不同的。

eygle

麻烦在帮我看看http://www.itpub.net/418625.html
另外做csscan full=y fromchar=ZHS16GBK tochar=UTF8 log=check.log capture=y array=1000000 process=2，这个操作我在导入结束后再目标库上做，fromchar=ZHS16GBK 是不是代表了导出dmp的字符集，tochar=UTF8是不是代表了目标数据库的字符集 ？
我刚在目标库上做完，看到几乎每张表都转换出了问题，难道从ZHS16GBK 向UTF8转换，只要是汉字就不能转换？