关于为何启用 GB18030 local 的说明

cjacker

在这需要特别说明一下：

XWindows GB18030 实现是通过utf8转过来的，通俗一点，就是每个gb18030字符显示都是通过utf8转gb18030实现，当然，实现上没有这么通俗。

图形界面的文本显示，都是将gb18030再次转换成utf8来显示的。


那么，你面临的是什么问题？

通过utf8转gb18030来实现gb18030支持，然后再通过gb18030转utf8来实现文本的显示。

相信这么说很多人也就明白了。

woolzey

除了ftp，还有nfs，cvs，或许还有svn(这个我不确定)可能会有乱码问题。

还有我不能理解为什么gb 18030不能处理多语言。理论上它编码了Unicode 3.1的所有字符，跟utf-8在这方面没有差别。

[quote:255d77e98f="cjacker"]
要实际作了才知道。
用了utf8当然是大大减少了Patch量，甚至基本不需要patch，因为内外都是utf8。

上面对文本文档和带格式带编码文档已经做过描述了。

至于你提到的Windows分区问题，我可以告诉你没有任何问题，根本就不会出现?????的问题。

另外对于基于带编码描述的协议的数据传递也不存在类似问题。
一个例外是ftp，他是没有编码描述的。
另一个是nntp，不过协议明确规定，新闻组名必须是latin1或者utf8，任何其他字符都是非法的。


我只需要提几个小小的问题，大家可以尝试在GBlocale下去fix。

1，多语言文本混排问题，最简单的表现就是kmail的邮件标题列表。有没有人能够用正确的方法去fix?
2，kio_trash中文文件名支持问题，这个问题有没有人能够去用正确的方法fix?
if LANG = zh_CN.xxxx
  xxxxxxxx
else
  xxxxxxxx
这样的方法不叫正确的方法。


理解这个问题，必须清楚的理解各编码之间的关系，目前Linux下存在那些中文支持问题，以及采用不同的方案会导致什么样的结果。而不是仅仅凭猜测。


utf8是不需要任何patch的，除非他的程序写错了才需要patch。
如果是gb18030，那么即使他的程序是正确的，也有很多需要patch的地方。


所以，不要凭猜测来作结论。

当然，这个是自由了，愿意用就用，但是，你确实需要背负更多的ugly hack的patch.[/quote]

woolzey

这种方案我觉得没啥问题。就好像Windows内部都是UCS-2/UCS-4，对外作一次编码转换。

现在的GTK内部也全是UTF-8，只要是非UTF-8的locale一样要做一次转换，不光是GB系列。我觉得这种方式很好，也使得GTK程序不需要xwindow支持gb18030。不知道QT是怎么处理这个问题的。

[quote:cdafbea4e2="cjacker"]在这需要特别说明一下：

XWindows GB18030 实现是通过utf8转过来的，通俗一点，就是每个gb18030字符显示都是通过utf8转gb18030实现，当然，实现上没有这么通俗。

图形界面的文本显示，都是将gb18030再次转换成utf8来显示的。


那么，你面临的是什么问题？

通过utf8转gb18030来实现gb18030支持，然后再通过gb18030转utf8来实现文本的显示。

相信这么说很多人也就明白了。[/quote]

cjacker

[quote:c1d705aed5="woolzey"]除了ftp，还有nfs，cvs，或许还有svn(这个我不确定)可能会有乱码问题。

还有我不能理解为什么gb 18030不能处理多语言。理论上它编码了Unicode 3.1的所有字符，跟utf-8在这方面没有差别。

[quote:c1d705aed5="cjacker"]
要实际作了才知道。
用了utf8当然是大大减少了Patch量，甚至基本不需要patch，因为内外都是utf8。

上面对文本文档和带格式带编码文档已经做过描述了。

至于你提到的Windows分区问题，我可以告诉你没有任何问题，根本就不会出现?????的问题。

另外对于基于带编码描述的协议的数据传递也不存在类似问题。
一个例外是ftp，他是没有编码描述的。
另一个是nntp，不过协议明确规定，新闻组名必须是latin1或者utf8，任何其他字符都是非法的。


我只需要提几个小小的问题，大家可以尝试在GBlocale下去fix。

1，多语言文本混排问题，最简单的表现就是kmail的邮件标题列表。有没有人能够用正确的方法去fix?
2，kio_trash中文文件名支持问题，这个问题有没有人能够去用正确的方法fix?
if LANG = zh_CN.xxxx
  xxxxxxxx
else
  xxxxxxxx
这样的方法不叫正确的方法。


理解这个问题，必须清楚的理解各编码之间的关系，目前Linux下存在那些中文支持问题，以及采用不同的方案会导致什么样的结果。而不是仅仅凭猜测。


utf8是不需要任何patch的，除非他的程序写错了才需要patch。
如果是gb18030，那么即使他的程序是正确的，也有很多需要patch的地方。


所以，不要凭猜测来作结论。

当然，这个是自由了，愿意用就用，但是，你确实需要背负更多的ugly hack的patch.[/quote][/quote]

举个例子：
藏文有600多个字符，但是gb18030中只有其基本集。

cjacker

[quote:6ae156b7b1="woolzey"]这种方案我觉得没啥问题。就好像Windows内部都是UCS-2/UCS-4，对外作一次编码转换。

现在的GTK内部也全是UTF-8，只要是非UTF-8的locale一样要做一次转换，不光是GB系列。我觉得这种方式很好，也使得GTK程序不需要xwindow支持gb18030。不知道QT是怎么处理这个问题的。

[quote:6ae156b7b1="cjacker"]在这需要特别说明一下：

XWindows GB18030 实现是通过utf8转过来的，通俗一点，就是每个gb18030字符显示都是通过utf8转gb18030实现，当然，实现上没有这么通俗。

图形界面的文本显示，都是将gb18030再次转换成utf8来显示的。


那么，你面临的是什么问题？

通过utf8转gb18030来实现gb18030支持，然后再通过gb18030转utf8来实现文本的显示。

相信这么说很多人也就明白了。[/quote][/quote]

很遗憾，QT4仍然是utf16，这是大家都认为不可用的编码，呵呵。

当然，如果仅仅是为了显示gb18030字符，当然不需要X支持，qt也一样，只要C库支持加上转换就可以了。

这样转没有问题，但是，不是所有的编码都可以转成gb18030，当然，大家都可以转成utf8。

但是何必浪费效率呢？

woolzey

毕竟gb18030可以提供兼容性，所以费些事也是值得的，反正现在CPU速度快。

当然我同意utf-8和gb18030适合不同的用户，不过只要windows的I/O还不是utf-8，那么utf-8还是有些麻烦的。

[quote:40c57269c6="cjacker"][quote:40c57269c6="woolzey"]这种方案我觉得没啥问题。就好像Windows内部都是UCS-2/UCS-4，对外作一次编码转换。

现在的GTK内部也全是UTF-8，只要是非UTF-8的locale一样要做一次转换，不光是GB系列。我觉得这种方式很好，也使得GTK程序不需要xwindow支持gb18030。不知道QT是怎么处理这个问题的。

[quote:40c57269c6="cjacker"]在这需要特别说明一下：

XWindows GB18030 实现是通过utf8转过来的，通俗一点，就是每个gb18030字符显示都是通过utf8转gb18030实现，当然，实现上没有这么通俗。

图形界面的文本显示，都是将gb18030再次转换成utf8来显示的。


那么，你面临的是什么问题？

通过utf8转gb18030来实现gb18030支持，然后再通过gb18030转utf8来实现文本的显示。

相信这么说很多人也就明白了。[/quote][/quote]

很遗憾，QT4仍然是utf16，这是大家都认为不可用的编码，呵呵。

这样转没有问题，但是，不是所有的编码都可以转成gb18030，当然，大家都可以转成utf8。

但是何必浪费效率呢？[/quote]

woolzey

gb18030中没有的在Unicode中有？不应该啊。

[quote:3bf94d133f="cjacker"]
举个例子：
藏文有600多个字符，但是gb18030中只有其基本集。[/quote]

BOoRFGOnZ

好贴

cjacker

[quote:c21a4d16cd="woolzey"]gb18030中没有的在Unicode中有？不应该啊。

[quote:c21a4d16cd="cjacker"]
举个例子：
藏文有600多个字符，但是gb18030中只有其基本集。[/quote][/quote]

当然了，gb18030一共多少个字，Unicode有多少个字啊。

cjacker

[quote:c11562cfd8="woolzey"]毕竟gb18030可以提供兼容性，所以费些事也是值得的，反正现在CPU速度快。

当然我同意utf-8和gb18030适合不同的用户，不过只要windows的I/O还不是utf-8，那么utf-8还是有些麻烦的。

[quote:c11562cfd8="cjacker"][quote:c11562cfd8="woolzey"]这种方案我觉得没啥问题。就好像Windows内部都是UCS-2/UCS-4，对外作一次编码转换。

现在的GTK内部也全是UTF-8，只要是非UTF-8的locale一样要做一次转换，不光是GB系列。我觉得这种方式很好，也使得GTK程序不需要xwindow支持gb18030。不知道QT是怎么处理这个问题的。

[quote:c11562cfd8="cjacker"]在这需要特别说明一下：

XWindows GB18030 实现是通过utf8转过来的，通俗一点，就是每个gb18030字符显示都是通过utf8转gb18030实现，当然，实现上没有这么通俗。

图形界面的文本显示，都是将gb18030再次转换成utf8来显示的。


那么，你面临的是什么问题？

通过utf8转gb18030来实现gb18030支持，然后再通过gb18030转utf8来实现文本的显示。

相信这么说很多人也就明白了。[/quote][/quote]

很遗憾，QT4仍然是utf16，这是大家都认为不可用的编码，呵呵。

这样转没有问题，但是，不是所有的编码都可以转成gb18030，当然，大家都可以转成utf8。

但是何必浪费效率呢？[/quote][/quote]

跟Windows我觉得只要保持协议数据兼容性和数据兼容性就可以了。

其他的倒是不用考虑，这里有一个例外，就是utf8文件集合的压缩包问题。

这个是要依赖特定工具的实现情况的，比如rar，在Linux下不论utf8还是gb压出来的东西，在Windows下都是正常的。同样，在Windows下用rar压出来的，在Linux下不论是utf8还是gb解开也是正常的。

但是，这个不适用与tar之类的压缩格式。

lanzinc

无论用何种方式识别编码类型都要求数据本身有一定的量，除非数据本身带编码标识符。
象文件名等这些字符数很小的串，是很难实现的。

如果系统不从外界获取GB系列的数据的话。系统的各个函数都把传递进来和传递出去的函数当成utf8（很多现有的linux函数就是这样的），当然可以减少许多补丁。

window2000和xp如果把默认内码页设置成简体中文，其实就和用中文版是一样的,只是系统界面语言是英文的罢了。比如英文软件中的摄氏度的符号，在这种情况下是乱码的。这种情况下一些连接的科学仪器也是不能正常工作的。因此有许多仪器要求其控制电脑一定要是英文版的，且默认内码页也要设置成英文(中文吗就不要用了：－）)。

windows的API中很多函数是两套的，一套是ANSI的（funnameA），一套是Unicode（funnameW）
是要编程的人自己选择合适函数解决编码问题的。

下面引用windows编程教程的一段：
1 Win32 API的A/W函数
要了解Win32子系统的DLL们提供了哪些API，最直接的方法就是用Win32dsm直接查看DLL们的导出表。这时我们会发现Win32 API中带字符串的API一般都有两个版本，例如CreateFileA和CreateFileW。当然也有例外，例如GetProcAddress函数。

A代表ANSI代码页，W是宽字符，即Unicode字符。Windows中的Unicode字符一般指UCS2的UTF16-LE编码。让我们通过几个实例观察A/W版本间的关系。

例1：用WIn32dsm查看gdi32.dll的汇编代码，可以看到TextOutA调用GdiGetCodePage获取当前代码页，再调用MultiByteToWideChar转换输入的字符串，然后调用一个内部函数。而TextOutW直接调用这个内部函数。

例2：用调试器跟踪一个使用了CreateFileA的程序，可以看到：CreateFileA在将输入字符串转换为Unicode后，会调用CreateFileW。假设输入文件名是“测试.txt”，对应的数据就是：“B2 E2 CA D4 2E 74 78 74 00”。
在调试器中可以看到传给CreateFileW的文件名数据是：“4B 6D D5 8B 2E 00 74 00 78 00 74 00 00 00”。 这是"测试.txt"对应的Unicdoe字符串。CreateFileW会接着调用ntdll.dll中的NtCreateFile。顺便看看NtCreateFile的代码：
mov eax, 00000020
lea edx, dword ptr [esp+04]
int 2E
ret 002C
可见这个native API只是简单地调用了核心态提供的0x20号system service。

例3：gdi32.dll中的GetGlyphOutline函数可以获取指定字符的字模。GetGlyphOutlineA和GetGlyphOutlineW函数都会调用同一个内部函数（记作F）。函数F在返回前将通过int 2E调用0x10B1号system service。
GetGlyphOutlineW直接调用函数F。GetGlyphOutlineA在调用函数F前，要依次调用GdiGetCodePage、IsDBCSLeadByteEx和MultiByteToWideChar，将当前代码页的字符编码转换成Unicode编码。
如果我们调用GetGlyphOutlineA时传入“baba”，这是“汉”字的GBK编码，用调试器可以看到传给函数F的字符编码是“6c49”，这是“汉”字的Unicode编码。

cjacker

这里有一个疑问：

GB编码的数据多还是unicode编码的数据多。

似乎gb编码的数据主要集中在纯文本上，带格式文档的编码，比如Doc文档是不是内部都是unicode？应该是吧，因为MS Word是可以同时处理多语言的，Notepad声称的rtf也应该是，因为他也可以同时处理多语言。只有文本编辑器不是。

此外，就是html之类的纯文本文件了，这个有可能GB编码的居多。

也就是说，GB兼容性问题，应该主要集中在纯文本文件(HTML都可以不考虑，只在编辑的时候可能发生，在浏览的时候不会，甚至可视化编辑的时候编辑器应该是读取Content-Type的)，另外就是无编码协议的数据传递上，比如FTP等。

其实这也是KDE中kio remoteencoding产生的意义，这个问题不管我们会遇到，任何一个有national charset定义的都会遇到。

所以，首先需要考虑的是多数还是少数问题，这个问题搞清楚了，这个问题的答案就可以确定下来了。

我的调研情况是，相对于GB编码下的补丁数量，UTF8编码下要解决的问题要少很多，而且，你可以保证你的修改不是locale specific的。

这样以来，选择也就明确了。

对于：
1，无编码描述协议，默认设置为gb编码，这是考虑到大量的历史数据的问题，当然要提供用户修改的可能，remoteencoding可以做到。

2，对纯文本文件，有两个选择：1，在读入时通过encoding detection工具判断并作设置；2，让用户手工选择。目前位置，1方案还没有100%的正确率，最后一个Windows的帖子也验证了我的说法，需要足够的数据量才能保证更高的准确率。

    那么，这里要考虑的是，用户的纯文本有多少？
    1，大量的数据以格式文本保存。
    2，会有从其他Linux过来的纯文本(主流版本都是utf8了)
    3，会有历史遗留文本或者从Windows过来的纯文本。
    我的建议是这个问题应该通过一个批量转换工具进行，在Windows下邮件乱码阅读器不是有很多人用吗？这就说明了问题，用户不是不能进行转换的。

3，文件名问题，两个系统之间肯定没有问题了，比如redhat和SuSE之间。
    这里的问题是：
     1，对Windows分区文件名兼容的问题，这个不需要论证，看看fat文件系统的内核代码就知道了，他是有encoding的设置的。
     2，对ext文件系统历史数据的兼容，我建议用convmv来解决。

4，utf8 Linux环境与Windows之间数据交流的问题，这个需要大家自己验证了，我还没有遇到严重的兼容性问题。

最难解决的是封装在特定格式内部的文件的文件名，比如压缩包，email中的附件名等等。目前可以确定他会有问题。但是，如果你是gb，别人是utf8，那么你一样要遇到问题。所以在保证了跟Linux系统之间的兼容性之后，再考虑怎么来更好的解决此类问题。

jiangtao9999

如果使用 utf8 那很有可能在未来还需要再进行这么一次编码迁移工作。

这也是为什么 GB18030 出现的原因，他是为了兼容 GB2312 而出现的编码方案。可以认为是以前的 GB2312 编码的扩展，如果中国真的想更换编码方案，那么已经有现成的方案了，就是基于 unicode 3 的中国编码标准 GBK （好像还有个别的名字，似乎统一名称是 ISO10646 ），还能轮得到 utf8 ？。中国政府会苯到放弃一个已经成型、可以和未来兼容的编码方案，来支持另一个还没有定论的方案？
在当时，韩国和日本也同时按照 unicode 设计了自己的编码方案。

按cjacker 的方案，那么会出现 GB -> UTF8 -> unicode 的现象。
而如果使用 GB18030 ，那么就省去了 UTF8 的过程。
要知道 utf8 和 GB18030 都是基于未完成的 unicode 4 进行设计的，要知道 unicode 还没有完整包含亚洲文字编码。
难道 utf8 就能完整包含？

utf8 考虑了西方字符的统一。
GB18030 考虑了中国少数民族文字的统一。GB18030 预留了 unicode 4 里尚未包含的很多文字。
你以为中国只会闭门造车？
要知道我妹妹的各种证件上“ 江 * ”已经很久了。

连 GB18030 都只能算是应急的标准，那 UTF8 就能算正式的方案？

要真想全球统一，只能等 unicode 完成全部的亚洲文字编码。
或者只能等中文改为拼音了，就象韩文拼写方式和日本的拼写方式。

中文的表型方式文字进行完整编码似乎比 100% 识别转换字符串还要困难。

cjacker 的方案，就是拿来增加成本的！

jiangtao9999

[quote:5268f5145e="cjacker"]在这需要特别说明一下：

XWindows GB18030 实现是通过utf8转过来的，通俗一点，就是每个gb18030字符显示都是通过utf8转gb18030实现，当然，实现上没有这么通俗。

图形界面的文本显示，都是将gb18030再次转换成utf8来显示的。


那么，你面临的是什么问题？

通过utf8转gb18030来实现gb18030支持，然后再通过gb18030转utf8来实现文本的显示。

相信这么说很多人也就明白了。[/quote]
内部 UTF8 读写 GB18030 ，一直是这样。
通过很多软件的设计，读取了字符串后 locale->UTF8 写字符串的时候 UTF8 -> locale ，正好符合这个方法啊。
这是目前最简单的解决方案。
虽然编码转换的工作应该由系统完成，而实际却由应用程序解决。

真正出现编码混乱的地方就是跨编码使用区域的时候，locale -> UTF8 就出现了问题。
真正的问题不是出在 GB18030 身上，而是出现在“万码奔腾”的时代。

只能等真正统一了编码，才能完整的解决这个问题。
不然，废弃了 GB 系列编码，大家仍然会遭到编码混乱的问题。

这个世界上除了，使用 UTF8 、GB18030 编码的国家外，还有很多国家他们也在使用自己的编码。
难道让他们也立即换成 UTF8 ？

lanzinc

想请教一下
local这个环境变量在一个linux系统中到底起什么用。
我的理解是：
1。她告诉一个应用程序在输入和输出不带编码标识符的数据是都当成local所指定的编码。
也就是她根本不管程序内部用何种编码工作，只要在外交的时候作好转换，内部你爱转来转去我才不管呢。
2。她告诉程序当有多种语言界面方案的时候，应该选择何种语言与用户交互。
不知道对不对？

另外国家标准中对一个系统对"GB18030的支持"是如何定义的

是不是这样要求：
1.不带编码标识符的数据输出都必须是GB18030。(对于一个操作系统，磁盘上的数据当作系统的外部数据），和外部系统的交互事先或默认确定了编码格式除外。
2.任何GB18030数据（无论带不带编码标识符），都能正确的识别为GB18030数据，以进行处理和显示。

我觉得一个系统只有作到以上两点才算是真正的支持GB18030。