AL32UTF8 这样的字符集的诡异问题~

secooler

曾经在windows的sqlplus，PL/SQL Developer和Toad中做过您的测试。
结论是：
5）PL/SQL Developer工具在AL32UTF8字符集下貌似可以保证数据效果，但是“Toad同学”貌似不太“稳定”。

客户端存入数据库的内容与通过同样的客户端得到的内容是一致的（即使您生造一个根本不存在的文字）。

举另外一个例子，Server端使用西欧字符集WE8ISO8859P1保存汉字内容时，虽然数据库中存入的真实内容是乱码，但是如果客户端统一将NLS_LANG设置为WE8ISO8859P1，一样可以正确的存取汉字内容。

secooler

zergduan

举另外一个例子，Server端使用西欧字符集WE8ISO8859P1保存汉字内容时，虽然数据库中存入的真实内容是乱码，但是如果客户端统一将NLS_LANG设置为WE8ISO8859P1，一样可以正确的存取汉字内容。

这个说法有问题~  --如果要达到 “虽然数据库中存入的真实内容是乱码，但是如果客户端统一将NLS_LANG设置为WE8ISO8859P1，一样可以正确的存取汉字内容。” 这样的效果，“Server端使用西欧字符集WE8ISO8859P1保存汉字内容时”--这个时候输入的汉字的client nls_lang也必须是WE8ISO8859P1；说白了，就是输入的时候没有转码，输出的时候就必须不能转码，才能得到所谓的"汉字"~ 但是其实数据库里面并不是汉字~
因为如果数据库中是汉字的话，必须保证在使用其他client nls_lang 汉字字符集的时候，能够正常转码，并显示汉字。这才是真正的汉字存储在数据库中~

zergduan

5）PL/SQL Developer工具在AL32UTF8字符集下貌似可以保证数据效果，但是“Toad同学”貌似不太“稳定”。
也就是说真的pl/sql developer不受注册表的nls_lang的限制，可以自动的吧nls_lang调整成client系统相同的字符集？

secooler

没错，数据库中存放的就是“乱码”，取的也是“乱码”，所以得到的是“汉字”。

NLS_LANG在Server和Client端都必须设置为WE8ISO8859P1字符集才能达到这种正常使用的错觉。

secooler

[ 本帖最后由 secooler 于 2010-1-21 17:13 编辑 ]

secooler

原帖由 zergduan 于 2010-1-21 16:35 发表
5）PL/SQL Developer工具在AL32UTF8字符集下貌似可以保证数据效果，但是“Toad同学”貌似不太“稳定”。
也就是说真的pl/sql developer不受注册表的nls_lang的限制，可以自动的吧nls_lang调整成client系统相同的字符集？

测试结果是这样的，对于PL/SQL Developer工具到底做了哪些动作，不是很清楚，目前没有思路。
Toad感觉比较忠于Client端的NLS_LANG的设置。

secooler

Yong Huang

> 也就是说真的pl/sql developer不受注册表的nls_lang的限制

I looked it up on MOS and found in
https://support.oracle.com/CSP/m ... 4157.1&type=NOT

"this [SQL Developer] is a 'know good client' that needs no NLS configuration"

(The word "know" should be "known".)

Is SQL Developer the new name for PL/SQL Developer? If so, that's the official statement supporting our suspicion.

Yong Huang

zergduan

sql developer 是 oracle 公司出的client软件，不是pl/sql developer~
http://www.oracle.com/technology ... eveloper/index.html

tiantianchifan

谢谢各位的回复~ 但是关于ZHS16GBK和AL32UTF8这两个字符集没有子超集关系的问题，会不会发生转码丢失呢？

比如CLIENT 操作系统ZHS16GBK NLS_LANG ZHS16GBK；SERVER DB AL32UTF8
如果有一个汉字 X 这汉字在 ZHS16GBK中有编码为 "E3 10" 但是在 AL32UTF8中没有这个汉字的编码~

如果在client上向server插入这个汉字 ,那么就要转码 e3 10对应的AL32UTF8编码不存在，
是不是AL32UTF8就会是用一个通用的代码来代替这值来存储，比如'A1 B2 C3'，这样不就丢失了这个汉字了么？以后就算CLIENT使用NLS_LANG
ZHS15GBK也无法把'A1 B2 C3'转换成汉字 X 来显示给用户了...


我担心的这种情况是否存在？

〇〇

这就是Oracle推荐使用的字符集？还是用gbk/gb18030吧

zergduan

所谓的子集超集我理解是这样的关系:
A字符集是B字符集的子集~ 那么A中所存储的所有字符，在B中都存在，并且使用的编码和A相同.
我认为ZHS16GBK虽然不是AL32UTF8的子集，但是因为AL32UTF8是UNICODE标准的字符集，所以它应该有所有的中文字符。只不过对于同一个中文字符它和ZHS16GBK使用不同的编码来表示，所以它并不是ZHS16GBK的超集~

ALTER DATABASE CHARACTER SET XXX 之所以要求必须使用原字符集的严格超集作为新字符集，是因为这样做只不过是修改了数据字典，并没有修改汉字的实际存储编码，所以新的字符集必须保证和旧的字符集使用相同的编码表示相同的汉字，才能保证不出现乱麻或者信息的丢失...