中文是日文的超集?再试验字符集问题

chengyong

我再试试直接使用.NET编程  net是UNICODE的
要是有结果的话 贴上来

biti_rainy

最初由 chengyong 发布
[B]如果需要开发一个软件需要在ORACLE实现多语言共存 CS结构的
例如这个例子的日文和中文(英文和中文由于存在严格超集所以不用讨论)
数据库存放UTF8,那么日文和中文都转化成UNICODE保存在数据库中
但是取回的时候,又发生了转化,中文转日文发生无法转换
是否可以设置NLS_LANG=ALT32UTF8哪?
如果不行的话,是否可以论证中文日文在这个CS结构无法实现共存
除非使用OCI直接取出和保存UNICODE才可以?
不好意思  有些跑题了  涉及了开发的问题
按照ORACLE自己的标准架构,好像总是有这个中间转换层存在的 [/B]

1：数据库存储选择一个能同时兼容 中文和日文的编码字符集，然后所有client的 NLS_LANG设置和数据库字符集一样。

2：干脆就使用单字节字符集，当然所有client 的NLS_LANG设置也可数据库字符集一样。

3：有可能，你把信息都当二进制流存储进数据库，取出来再转换也应该可以


4: 如果使用 16bit 的字符集A存储其他16bit 的字符集B，如果B的这个编码在A中不存在，则数据库将存成 ???  这样的无法识别的字符。同理大于8bit的字符集编码之间都可能存在类似问题，所以需要选择一个能兼容的字符集来存储。

数据库只关心两个问题：
数据库字符集是否能支持存储传过来的编码
client nls_lang设置和数据库存储字符集一致以使得编码不发生转化。

chengyong

"数据库存储选择一个能同时兼容 中文和日文的编码字符集"同意 没有问题
但是
"4: 如果使用 16bit 的字符集A存储其他16bit 的字符集B，如果B的这个编码在A中不存在，则数据库将存成 ??? 这样的无法识别的字符。同理大于8bit的字符集编码之间都可能存在类似问题，所以需要选择一个能兼容的字符集来存储。"---有问题 我可以使用UNICODE呀

由于数据库支持UTF8,WINDOWS也支持UNICODE 所以难道没有办法
全部使用UNICODE,不管是什么语言,都是原来的样子吗?这个问题不管是
什么语言了  就算是泰国语言也能原样显示的问题.
那个这个UNICODE是否不能使用ORACLE的VARCHAR2只能使用NVARCHAR?
这个才是真的要命的问题
理由是现在的很多程序都是VARCHAR2的,但是都有语言共存问题

或者干脆这样问:ORACLE如何解决UNICODE保存和输出的
               是否可以使用VARCHAR2

biti_rainy

如果你所有都转换成unicode了，对于数据库来说和你以前是什么字符集是不是就没有关系了呢？因为转换之后，编码自身可能就已经发生了变化。





使用 varchar2 应该是没有问题，如果你要存储 unicode ,创建数据库的时候，可以选择合适的字符集，比如一些 24bit 的或者 32bit 的字符集。不过我没有这方面经验。(创建数据库的时候有两种字符集选择，一种是通常使用的，另一种是 national 的，也就是 nvarchar/nclob 这样的类型使用的，如果你把通常使用的字符集不再使用gbk/gb231280/us7ascii 等字符集而是使用其他的 定长 24bit  or  32bit 字符集（比如ALT32UTF8），不知道是不是能解决你的问题)


顺带提醒一点，在使用utf8 字符集的时候对于中文有一些bug，但某些字位于字符串的末尾和 单引号 挨在一起的时候，sql就会出错。

chengyong

讨论一下确实收益不浅
从开头的字符集子集问题一直到UNICODE应用问题
概念越来越清晰,至少不用盲目测试了
有趣的字符集问题  我需要测试全UNICODE的状态了

funnyok

最初由 biti_rainy 发布
[B]如果你所有都转换成unicode了，对于数据库来说和你以前是什么字符集是不是就没有关系了呢？因为转换之后，编码自身可能就已经发生了变化。





使用 varchar2 应该是没有问题，如果你要存储 unicode ,创建数据库的时候，可以选择合适的字符集，比如一些 24bit 的或者 32bit 的字符集。不过我没有这方面经验。(创建数据库的时候有两种字符集选择，一种是通常使用的，另一种是 national 的，也就是 nvarchar/nclob 这样的类型使用的，如果你把通常使用的字符集不再使用gbk/gb231280/us7ascii 等字符集而是使用其他的 定长 24bit  or  32bit 字符集（比如ALT32UTF8），不知道是不是能解决你的问题)


顺带提醒一点，在使用utf8 字符集的时候对于中文有一些bug，但某些字位于字符串的末尾和 单引号 挨在一起的时候，sql就会出错。 [/B]

如果是24,32bit字符集,支持unicode的客户端(java,.net ...)就可以直接以unicode写入/读出db而不需要转换吗？
我觉得在unicode的情况下如果客户端的nls_lang与服务器不一样(比如client 24 server 32)还是需要客户端转换的。只不过这些转换理论上都是无损的完全等价的？而且与客户端、服务器的首要语言无关。

题一个问题

因为转换之后，编码自身可能就已经发生了变化。

指的是什么？

biti_rainy

最初由 funnyok 发布
[B]

如果是24,32bit字符集,支持unicode的客户端(java,.net ...)就可以直接以unicode写入/读出db而不需要转换吗？
我觉得在unicode的情况下如果客户端的nls_lang与服务器不一样(比如client 24 server 32)还是需要客户端转换的。只不过这些转换理论上都是无损的完全等价的？而且与客户端、服务器的首要语言无关。

题一个问题

指的是什么？ [/B]

客户端的nls_lang与服务器不一样(比如client 24 server 32)，都会发生转换,这个转换就可能导致编码发生变化。这个转换是在oracle  net 交换时候发生的，也就是 two  task 通信层。有时候字符集问题引出 two  task 错误并出现 ORA-3113 就和这一层有关。