到底是用GB2312还是UTF-8
终极super
想想又不想放弃对GB2312的支持，又不想太局限与GB2312，真是郁闷呀：（
大家说呢？
--
终极super zhongjisuper
4361z0aa0-c5e93as0a66-8634jeb6e
#############################################
Email/GTalk：zhongjisuper0[at]gmail.com
吟风茶馆：http://www.yfcg.com.cn/
Blog原创：http://zhjsuper.blogspot.com/
Blog转载-计算机相关：http://zhongjisuper0.blogspot.com/
Blog转载-其他：http://zhongjisuper1.blogspot.com/
yong
曾经一些人(包括我)不用UTF-8是因为听了日本人的"不适合双字节用户的习惯"等等,号召亚洲用户抵制UTF-8,现在用了一段时间之后发现也没有多少不适合的地方.
所以还是推荐用UTF-8.
My Personal Website:
http://www.twinbee.info
本人驻守於
cn.comp.lang.perl
cn.comp.lang.c
cn.comp.www
cn.music
cn.music.classical
火柴
> 一直在琢磨这个问题，按理UTF-8兼容GB2312、BIG5、EUC-JP等多种国家的语言编
> 码，至少台湾，香港等海外朋友都可以看到我的blog，而且不会出现乱码！但那
> 天我在链接cnblog的最新链接的时候，发现他们提供的都是GB2312，结果出来一
> 堆乱码，这让我很矛盾。看来国内的bloger还是太局限于GB2312编码，虽然是国
> 家标准码，但UTF-8应该是大趋所势，看看对岸的台湾兄弟大都采用了UTF-8，觉
> 得就比较国际话。
>
> 想想又不想放弃对GB2312的支持，又不想太局限与GB2312，真是郁闷呀：（
>
> 大家说呢？
utf-8, utf-8, utf-8....
我现在硬盘由能转成 utf-8, 一般都转了。用 gb2312, gbk, gb18030, ...之类太
折腾了。还是 utf-8 最好，一般软件都会有支持。
--
火柴
Ruth made a great mistake when he gave up pitching. Working once a week,
he might have lasted a long time and become a great star.
-- Tris Speaker, commenting on Babe Ruth's plan to change
from being a pitcher to an outfielder.
Cerf/Navasky, "The Experts Speak"
GoldenMouse
8，欧美国家的人们可以用底成本达到编码统一，但是象中国等非英语国家则面临
巨大的转换成本和将来的运行成本。说UTF-8是技术歧视似乎并不算过。
终极super 写道:
batch
"终极super" <zhongj...@gmail.com> 写入消息 news:ebmrji$v31$1...@news.yaako.com...
风中纸页
这样光有论据根本不能说明问题的。：）
Last time, Fat "终极super" <zhongj...@gmail.com> says:
--
>一直在琢磨这个问题，按理UTF-8兼容GB2312、BIG5、EUC-JP等多种国家的语言编码，至少台湾，香港等海外朋友都可以看到我的blog，而且不会出现乱码！但那天我在链接cnblog的最新链接的时候，发现他们提供的都是GB2312，结果出来一堆乱码，这让我很矛盾。看来国内的bloger还是太局限于GB2312编码，虽然是国家标准码，但UTF-8应该是大趋所势，看看对岸的台湾兄弟大都采用了UTF-8，觉得就比较国际话。
>
>想想又不想放弃对GB2312的支持，又不想太局限与GB2312，真是郁闷呀：（
>
>大家说呢？
--
把问题先交给google，然后再交给你的朋友。。。
终极super
你能不能介绍一下UTF-8的技术细节
--
终极super zhongjisuper
4361z0aa0-c5e93as0a66-8634jeb6e
#############################################
Email/GTalk：zhongjisuper0[at]gmail.com
吟风茶馆：http://www.yfcg.com.cn/
Blog原创：http://zhjsuper.blogspot.com/
Blog转载-计算机相关：http://zhongjisuper0.blogspot.com/
Blog转载-其他：http://zhongjisuper1.blogspot.com/
"GoldenMouse" <golden...@sina.com.cn> 写入消息
news:ebmvtl$4ee$1...@news.yaako.com...
终极super
by Markus Kuhn
中国LINUX论坛翻译小组 xLoneStar[译] 2000年2月
这篇文章说明了在 POSIX 系统 (Linux,Unix) 上使用 Unicode/UTF-8 所需要的信息.
在将来不远的几年里, Unicode 已经很接近于取代 ASCII 与 Latin-1 编码的位置了.
它不仅允许你处理处理事实上存在于地球上的任何语言文字, 而且提供了一个全面的数
学与技术符号集, 因此可以简化科学信息交换.
UTF-8 编码提供了一种简便而向后兼容的方法, 使得那种完全围绕 ASCII 设计的操作系
统, 比如 Unix, 也可以使用 Unicode. UTF-8 就是 Unix, Linux 已经类似的系统使用
Unicode 的方式. 现在是你了解它的时候了.
什么是 UCS 和 ISO 10646?
国际标准 ISO 10646 定义了 通用字符集 (Universal Character Set, UCS). UCS 是所
有其他字符集标准的一个超集. 它保证与其他字符集是双向兼容的. 就是说, 如果你将
任何文本字符串翻译到 UCS格式, 然后再翻译回原编码, 你不会丢失任何信息.
UCS 包含了用于表达所有已知语言的字符. 不仅包括拉丁语,希腊语, 斯拉夫语,希伯来
语,阿拉伯语,亚美尼亚语和乔治亚语的描述, 还包括中文, 日文和韩文这样的象形文字
, 以及 平假名, 片假名, 孟加拉语, 旁遮普语果鲁穆奇字符(Gurmukhi), 泰米尔语,
印
.埃纳德语(Kannada), Malayalam, 泰国语, 老挝语, 汉语拼音(Bopomofo), Hangul, D
evangari, Gujarati, Oriya, Telugu 以及其他数也数不清的语. 对于还没有加入的语
言, 由于正在研究怎样在计算机中最好地编码它们, 因而最终它们都将被加入. 这些语
言包括 Tibetian, 高棉语, Runic(古代北欧文字), 埃塞俄比亚语, 其他象形文字, 以
及各种各样的印-欧语系的语言, 还包括挑选出来的艺术语言比如 Tengwar, Cirth 和
克林贡语(Klingon). UCS 还包括大量的图形的, 印刷用的, 数学用的和科学用的符号,
包括所有由 TeX, Postscript, MS-DOS，MS-Windows, Macintosh, OCR 字体, 以及许
多其他字处理和出版系统提供的字符.
ISO 10646 定义了一个 31 位的字符集. 然而, 在这巨大的编码空间中, 迄今为止只分
配了前 65534 个码位 (0x0000 到 0xFFFD). 这个 UCS 的 16位子集称为 基本多语言面
(Basic Multilingual Plane, BMP). 将被编码在 16 位 BMP 以外的字符都属于非常特
殊的字符(比如象形文字), 且只有专家在历史和科学领域里才会用到它们. 按当前的计
划, 将来也许再也不会有字符被分配到从 0x000000 到 0x10FFFF 这个覆盖了超过 100
万个潜在的未来字符的 21 位的编码空间以外去了. ISO 10646-1 标准第一次发表于
1993 年, 定义了字符集与 BMP 中内容的架构. 定义 BMP 以外的字符编码的第二部分
ISO 10646-2 正在准备中, 但也许要过好几年才能完成. 新的字符仍源源不断地加入到
BMP 中, 但已经存在的字符是稳定的且不会再改变了.
UCS 不仅给每个字符分配一个代码, 而且赋予了一个正式的名字. 表示一个 UCS 或
Unicode 值的十六进制数, 通常在前面加上 "U+", 就象 U+0041 代表字符"拉丁大写字母
A". UCS 字符 U+0000 到 U+007F 与 US-ASCII(ISO 646) 是一致的, U+0000 到
U+00FF
与 ISO 8859-1(Latin-1) 也是一致的. 从 U+E000 到 U+F8FF, 已经 BMP 以外的大范
围的编码是为私用保留的.
什么是组合字符?
UCS里有些编码点分配给了 组合字符.它们类似于打字机上的无间隔重音键. 单个的组合
字符不是一个完整的字符. 它是一个类似于重音符或其他指示标记, 加在前一个字符后
面. 因而, 重音符可以加在任何字符后面. 那些最重要的被加重的字符, 就象普通语言
的正字法(orthographies of common languages)里用到的那种, 在 UCS 里都有自己的
位置, 以确保同老的字符集的向后兼容性. 既有自己的编码位置, 又可以表示为一个普
通字符跟随一个组合字符的被加重字符, 被称为 预作字符(precomposed characters).
UCS 里的预作字符是为了同没有预作字符的旧编码, 比如 ISO 8859, 保持向后兼容性
而设的. 组合字符机制允许在任何字符后加上重音符或其他指示标记, 这在科学符号中
特别有用, 比如数学方程式和国际音标字母, 可能会需要在一个基本字符后组合上一个
或多个指示标记.
组合字符跟随着被修饰的字符. 比如, 德语中的元音变音字符 ("拉丁大写字母A 加上分
音符"), 既可以表示为 UCS 码 U+00C4 的预作字符, 也可以表示成一个普通 "拉丁大写
字母A" 跟着一个"组合分音符":U+0041 U+0308 这样的组合. 当需要堆叠多个重音符,
或在一个基本字符的上面和下面都要加上组合标记时, 可以使用多个组合字符. 比如在
泰国文中, 一个基本字符最多可加上两个组合字符.
什么是 UCS 实现级别?
不是所有的系统都需要支持象组合字符这样的 UCS 里所有的先进机制. 因此
ISO 10646 指定了下列三种实现级别:
级别1
不支持组合字符和 Hangul Jamo 字符 (一种特别的, 更加复杂的韩国文的编码, 使用两
个或三个子字符来编码一个韩文音节)
级别2
类似于级别1, 但在某些文字中, 允许一列固定的组合字符 (例如, 希伯来文, 阿拉伯文
, Devangari, 孟加拉语, 果鲁穆奇语, Gujarati, Oriya, 泰米尔语, Telugo, 印.埃纳
德语, Malayalam, 泰国语和老挝语). 如果没有这最起码的几个组合字符, UCS 就不能
完整地表达这些语言.
级别3
支持所有的 UCS 字符, 例如数学家可以在任意一个字符上加上一个 tilde(颚化符号,西
班牙语字母上面的～)或一个箭头(或两者都加).
什么是 Unicode?
历史上, 有两个独立的, 创立单一字符集的尝试. 一个是国际标准化组织(ISO)的 ISO
10646 项目, 另一个是由(一开始大多是美国的)多语言软件制造商组成的协会组织的
Unicode 项目. 幸运的是, 1991年前后, 两个项目的参与者都认识到, 世界不需要两个不
同的单一字符集. 它们合并双方的工作成果, 并为创立一个单一编码表而协同工作. 两
个项目仍都存在并独立地公布各自的标准, 但 Unicode 协会和 ISO/IEC JTC1/SC2 都同
意保持 Unicode 和 ISO 10646 标准的码表兼容, 并紧密地共同调整任何未来的扩展.
那么 Unicode 和 ISO 10646 不同在什么地方?
Unicode 协会公布的 Unicode 标准 严密地包含了 ISO 10646-1 实现级别3的基本多语
言面. 在两个标准里所有的字符都在相同的位置并且有相同的名字.
Unicode 标准额外定义了许多与字符有关的语义符号学, 一般而言是对于实现高质量的
印刷出版系统的更好的参考. Unicode 详细说明了绘制某些语言(比如阿拉伯语)表达形
式的算法, 处理双向文字(比如拉丁与希伯来文混合文字)的算法和 排序与字符串比较
所需的算法, 以及其他许多东西.
另一方面, ISO 10646 标准, 就象广为人知的 ISO 8859 标准一样, 只不过是一个简单
的字符集表. 它指定了一些与标准有关的术语, 定义了一些编码的别名, 并包括了规范
说明, 指定了怎样使用 UCS 连接其他 ISO 标准的实现, 比如 ISO 6429 和 ISO 2022.
还有一些与 ISO 紧密相关的, 比如 ISO 14651 是关于 UCS 字符串排序的.
考虑到 Unicode 标准有一个易记的名字, 且在任何好的书店里的 Addison-Wesley 里有
, 只花费 ISO 版本的一小部分, 且包括更多的辅助信息, 因而它成为使用广泛得多的参
考也就不足为奇了. 然而, 一般认为, 用于打印 ISO 10646-1 标准的字体在某些方面的
质量要高于用于打印 Unicode 2.0的. 专业字体设计者总是被建议说要两个标准都实现
, 但一些提供的样例字形有显著的区别. ISO 10646-1 标准同样使用四种不同的风格变
体来显示表意文字如中文, 日文和韩文 (CJK), 而 Unicode 2.0 的表里只有中文的变体
. 这导致了普遍的认为 Unicode 对日本用户来说是不可接收的传说, 尽管是错误的.
什么是 UTF-8?
首先 UCS 和 Unicode 只是分配整数给字符的编码表. 现在存在好几种将一串字符表示
为一串字节的方法. 最显而易见的两种方法是将 Unicode 文本存储为 2 个 或 4 个字
节序列的串. 这两种方法的正式名称分别为 UCS-2 和 UCS-4. 除非另外指定, 否则大多
数的字节都是这样的(Bigendian convention). 将一个 ASCII 或 Latin-1 的文件转换
成 UCS-2 只需简单地在每个 ASCII 字节前插入 0x00. 如果要转换成 UCS-4, 则必须在
每个 ASCII 字节前插入三个 0x00.
在 Unix 下使用 UCS-2 (或 UCS-4) 会导致非常严重的问题. 用这些编码的字符串会包
含一些特殊的字符, 比如 '\0' 或 '/', 它们在 文件名和其他 C 库函数参数里都有特
别的含义. 另外, 大多数使用 ASCII 文件的 UNIX 下的工具, 如果不进行重大修改是无
法读取 16 位的字符的. 基于这些原因, 在文件名, 文本文件, 环境变量等地方,
UCS-2 不适合作为 Unicode 的外部编码.
在 ISO 10646-1 Annex R 和 RFC 2279 里定义的 UTF-8 编码没有这些问题. 它是在
Unix 风格的操作系统下使用 Unicode 的明显的方法.
UTF-8 有一下特性:
UCS 字符 U+0000 到 U+007F (ASCII) 被编码为字节 0x00 到 0x7F (ASCII 兼容). 这
意味着只包含 7 位 ASCII 字符的文件在 ASCII 和 UTF-8 两种编码方式下是一样的.
所有 >U+007F 的 UCS 字符被编码为一个多个字节的串, 每个字节都有标记位集. 因此
, ASCII 字节 (0x00-0x7F) 不可能作为任何其他字符的一部分.
表示非 ASCII 字符的多字节串的第一个字节总是在 0xC0 到 0xFD 的范围里, 并指出这
个字符包含多少个字节. 多字节串的其余字节都在 0x80 到 0xBF 范围里. 这使得重新
同步非常容易, 并使编码无国界, 且很少受丢失字节的影响.
可以编入所有可能的 231个 UCS 代码
UTF-8 编码字符理论上可以最多到 6 个字节长, 然而 16 位 BMP 字符最多只用到3 字
节长.
Bigendian UCS-4 字节串的排列顺序是预定的.
字节 0xFE 和 0xFF 在 UTF-8 编码中从未用到.
下列字节串用来表示一个字符. 用到哪个串取决于该字符在 Unicode 中的序号.
U-00000000 - U-0000007F: 0xxxxxxx
U-00000080 - U-000007FF: 110xxxxx 10xxxxxx
U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
U-00010000 - U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 - U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 - U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
10xxxxxx
xxx 的位置由字符编码数的二进制表示的位填入. 越靠右的 x 具有越少的特殊意义.
只
用最短的那个足够表达一个字符编码数的多字节串. 注意在多字节串中, 第一个字节的
开头"1"的数目就是整个串中字节的数目.
例如: Unicode 字符 U+00A9 = 1010 1001 (版权符号) 在 UTF-8 里的编码为:
11000010 10101001 = 0xC2 0xA9
而字符 U+2260 = 0010 0010 0110 0000 (不等于) 编码为:
11100010 10001001 10100000 = 0xE2 0x89 0xA0
这种编码的官方名字拼写为 UTF-8, 其中 UTF 代表 UCS Transformation Format. 请勿
在任何文档中用其他名字 (比如 utf8 或 UTF_8) 来表示 UTF-8, 当然除非你指的是一
个变量名而不是这种编码本身.
什么编程语言支持 Unicode?
在大约 1993 年之后开发的大多数现代编程语言都有一个特别的数据类型, 叫做 Unico
de/ISO 10646-1 字符. 在 Ada95 中叫 Wide_Character, 在 Java 中叫 char.
ISO C 也详细说明了处理多字节编码和宽字符 (wide characters) 的机制, 1994 年 9
月 Amendment 1 to ISO C 发表时又加入了更多. 这些机制主要是为各类东亚编码而设
计的, 它们比处理 UCS 所需的要健壮得多. UTF-8 是 ISO C 标准调用多字节字符串的
编码的一个例子, wchar_t 类型可以用来存放 Unicode 字符.
在 Linux 下该如何使用 Unicode?
在 UTF-8 之前, 不同地区的 Linux 用户使用各种各样的 ASCII 扩展. 最普遍的欧洲编
码是 ISO 8859-1 和 ISO 8859-2, 希腊编码 ISO 8859-7, 俄国编码 KOI-8, 日本编码
EUC 和 Shift-JIS, 等等. 这使得 文件的交换非常困难, 且应用软件必须特别关心这
些编码的不同之处.
最终, Unicode 将取代所有这些编码, 主要通过 UTF-8 的形式. UTF-8 将应用在
文本文件 (源代码, HTML 文件, email 消息, 等等)文件名
标准输入与标准输出,
管道环境变量
剪切与粘贴选择缓冲区
telnet, modem 和到终端模拟器的串口连接
以及其他地方以前用ASCII来表示的字节串
在 UTF-8 模式下, 终端模拟器, 比如 xterm 或 Linux console driver, 将每次按键转
换成相应的 UTF-8 串, 然后发送到前台进程的 stdin 里. 类似的, 任何进程在
stdout
上的输出都将发送到终端模拟器, 在那里用一个 UTF-8 解码器进行处理, 之后再用一
种 16 位的字体显示出来.
只有在功能完善的多语言字处理器包里才可能有完全的 Unicode 功能支持. 而广泛用在
Linux 里用于取代 ASCII 和其他 8 位字符集的方案则要简单得多. 第一步, Linux
终
端模拟器和命令行工具将只是转变到 UTF-8. 这意味着只用到 级别1 的 ISO 10646-1
实现 (没有组合字符), 且只支持那些不需要更多处理的语言象 拉丁, 希腊, 斯拉夫
和
许多科学用符号. 在这个级别上, UCS 支持与 ISO 8859 支持类似, 唯一显著的区别是
现在我们有几千种字符可以用了, 其中的字符可以用多字节串来表示.
总有一天 Linux 会当然地支持组合字符, 但即便如此, 对于组合字符串, 预作字符(如
何可用的话)仍将是首选的. 更正式地, 在 Linux 下用 Unicode 对文本编码的首选的方
法应该是定义在 Unicode Technical Report #15 里的 Normalization Form C.
在今后的一个阶段, 人们可以考虑增加在日文和中文里用到的双字节字符的支持 (他们
相对比较简单), 组合字符支持, 甚至也许对从右至左书写的语言如希伯来文 (他们可不
是那么简单的) 的支持. 但对这些高级功能的支持不应该阻碍简单的平板 UTF-8 在 拉
丁, 希腊, 斯拉夫和科学用符号方面的快速应用, 以取代大量的欧洲 8 位编码, 并提供
一个象样的科学用符号集.
我该怎样修改我的软件?
有两种途径可以支持 UTF-8, 我称之为软转换与硬转换. 软转换时, 各处的数据均保存
为 UTF-8 形式, 因而需要修改的软件很少. 在硬转换时, 程序将读入的 UTF-8 数据转
换成宽字符数组, 以在应用程序内部处理. 在输出时, 再把字符串转换回 UTF-8 形式.
大多数应用程序只用软转换就可以工作得很好了. 这使得将 UTF-8 引入 Unix 成为切实
可行的. 例如, 象 cat 和 echo 这样的程序根本不需要修改. 他们仍然可以对输入输出
的是 ISO 8859-2 还是 UTF-8 一无所知, 因为它们只是搬运字节流而没有处理它们.
它
们只能识别 ASCII 字符和象 '\n' 这样的控制码, 而这在 UTF-8 下也没有任何改变.
因此, 这些应用程序的 UTF-8 编码与解码将完全在终端模拟器里完成.
而那些通过数字节数来获知字符数量的程序则需要一些小修改. 在 UTF-8 模式下, 它们
必须不数入 0x80 到 0xBF 范围内的字节, 因为这些只是跟随字节, 它们本身并不是字
符. 例如, ls 程序就必须要修改, 因为它通过数文件名中字符数来排放给用户的目录表
格布局. 类似地, 所有的假定其输出为定宽字体, 并因此而格式化它们的程序, 必须学
会怎样数 UTF-8 文本中的字符数. 编辑器的功能, 如删除单个字符, 必须要作轻微的修
改, 以删除可能属于该字符的所有字节. 受影响有编辑器 (vi,emacs, 等等)以及使用
ncurses 库的程序.
Linux 核心使用软转换也可以工作得很好, 只需要非常微小的修改以支持 UTF-8. 大多
数处理字符串的核心功能 (例如: 文件名, 环境变量, 等等) 都不受影响. 下列地方也
许必须修改:
控制台显示与键盘驱动程序 (另一个 VT100 模拟器) 必须能编码和解码 UTF-8, 必须要
起码支持 Unicode 字符集的几个子集. 从 Linux 1.2 起这些功能已经有了.
外部文件系统驱动程序, 例如 VFAT 和 WinNT 必须转换文件名字符编码. UTF-8 已经加
入可用的转换选项的列表里了, 因此 mount 命令必须告诉核心驱动程序用户进程希望看
到 UTF-8 文件名. 既然 VFAT 和 WinNT 无论如何至少已经用了 Unicode了, 那么
UTF-8
在这里就可以发挥其优势, 以保证转换中无信息损失.
POSIX 系统的 tty 驱动程序支持一种 "cooked" 模式, 有一些原始的行编辑功能. 为了
让字符删除功能工作正常, stty 必须在 tty 驱动程序里设置 UTF-8 模式, 因此它就不
会把 0x80 到 0xBF 范围内的跟随字符也数进去了. Bruno Haible 那里已经有了一些
stty 和核心 tty 驱动 程序的 Linux 补丁 了.
C 对 Unicode 和 UTF-8 的支持
从 GNU glibc 2.1 开始, wchar_t 类型已经正式定为只存放独立于当前 locale 的, 3
2位的 ISO 10646 值. glibc 2.2 开始将完全支持 ISO C 中的多字节转换函数
(wprintf(),mbstowcs(),等等), 这些函数可以用于在 wchar_t 和包括 UTF-8 在内的任
何依赖于 locale 的多字节编码间进行转换.
例如, 你可以写
wprintf(L"Sch鰊e Gre!\n");
然后, 你的软件将按照你的用户在环境变量 LC_CTYPE (例如, en_US.UTF-8 或 de_DE.
ISO_8859-1) 中选择的 locale 所指定的编码来打印这段文字. 你的编译器必须运行在
与该 C 源文件所用编码相应的 locale 中, 在目标文件中以上的宽字符串将改为
wchar_t
字符串存储. 在输出时, 运行时库将把 wchar_t 字符串转换回与程序执行时的
locale 相应的编码.
注意, 类似这样的操作:
char c = L"a";
只允许从 U+0000 到 U+007F (7 位 ASCII) 范围里的字符. 对于非 ASCII 字符, 不能
直接从 wchar_t 到 char 转换.
现在, 象 readline() 这样的函数在 UTF-8 locale 下也能工作了.
怎样激活 UTF-8 模式?
如果你的应用程序既支持 8 位字符集 (ISO 8859-*,KOI-8,等等), 也支持 UTF-8, 那么
它必须通过某种方法以得知是否应使用 UTF-8 模式. 幸运的是, 在未来的几年里, 人们
将只使用 UTF-8, 因此你可以将它作为默认, 但即使如此, 你还是得既支持传统 8 位字
符集, 也支持 UTF-8.
当前的应用程序使用许许多多的不同的命令行开关来激活它们各自的 UTF-8 模式, 例如:
xterm 命令行选项 "-u8" 和 X resource "XTerm*utf8:1"
gnat/gcc 命令行选项 "-gnatW8"
stty 命令行选项 "iutf8"
mined 命令行选项 "-U"
xemacs elisp 包裹 以在 UTF-8 和内部使用的 MULE 编码间转换
vim 'fileencoding' 选项
less 环境变量 LESSCHARSET=utf-8
记住每一个应用程序的命令行选项或其他配置方法是非常单调乏味的, 因此急需某种标
准方法.
如果你在你的应用程序里使用硬转换, 并使用某种特定的 C 库函数来处理外部字符编码
和内部使用的 wchar_t 编码的转换工作, 那么 C 库会帮你处理模式切换的问题. 你只
需将环境变量 LC_CTYPE 设为正确的 locale, 例如, 如果你使用 UTF-8, 那就是
en.UTF-8, 而如果是 Latin-1, 并需要英语的转换, 则设为 en.ISO_8859-1.
然而, 大多数现存软件的维护者选择用软转换来代替, 而不使用 libc 的宽字符函数,
不仅因为它们还未得到广泛应用, 还因为这会使得软件进行大规模修改. 在这种情况下
, 你的应用程序必须自己来获知何时使用 UTF-8 模式. 一种方式是做以下工作:
按照环境变量 LC_ALL, LC_CTYPE, LANG 的顺序, 寻找第一个有值的变量. 如果该值包
含 UTF-8 子串 (也许是小写或没有"-") 则默认为 UTF-8 模式 (仍然可以用命令行开关
来重设), 因为这个值可靠又恰当地指示了 C 库应该使用一种 UTF-8 locale.
提供一个命令行选项 (或者如果是 X 客户程序则用 X resource 的值) 将仍然是有用的
, 可以用来重设由 LC_CTYPE 等环境变量指定的默认值.
我怎样才能得到 UTF-8 版本的 xterm?
在 XFree86 里带的 xterm 版本最近已经由 Thomas E. Dickey 加入了支持 UTF-8 的扩
展. 使用方法是, 获取 xterm patch #119 (1999-10-16) 或更新版本, 用
"./configure --enable-wide-chars ; make"
来编译, 然后用命令行选项 -u8 来调用 xterm, 使它将输入输出转换为 UTF-8.
在 UTF-8 模式里使用一个 *-ISO10646-1 字体. 当你在ISO 8859-1 模式里时也可以使
用 *-ISO10646-1 字体, 因为 ISO 10646-1 字体与 ISO 8859-1 字体是完全向后兼容的.
新的支持 UTF-8 的 xterm 版本, 以及一些 ISO 10646-1 字体, 将被收录入 XFree86
4.0 版里.
xterm 支持组合字符吗?
Xterm 当前只支持级别1的 ISO 10646-1, 就是说, 不提供组合字符的支持. 当前, 组合
字符将被当作空格字符对待. xterm 将来的修订版很有可能加入某些简单的组合字符支
持, 就是仅仅将那个有一个或多个组合字符的基字符加粗 (logical OR-ing). 对于在基
线以下的和在小字符上方的重音符来说, 这样处理的结果还是可以接受的. 对于象泰国
文字体那样使用特别设计的加粗字符的文字, 这样处理也能工作的很好. 然而, 对于某
些字体里, 在较高的字符上方组合上的重音符, 特别是对于 "fixed" 字体族, 产生的结
果就不完全令人满意了. 因此, 在可用的地方, 应该继续优先使用预作字符.
xterm 支持半宽与全宽 CJK 字体吗?
Xterm 当前只支持那种所有字形都等宽的 cell-spaced 的字体. 将来的修订版很有可能
为 CJK 语言加入半宽与全宽字符支持, 类似于 kterm 提供的那种. 如果选择的普通字
体是 X×Y 象素大小, 且宽字符模式是打开的, 那么 xterm 会试图装入另外的一个 2X
×Y 象素大小的字体 (同样的 XLFD, 只是 AVERAGE_WIDTH 属性的值翻倍). 它会用这个
字体来显示所有在 Unicode Technical Report #11 里被分配了East Asian Wide (W)
或 East Asian FullWidth (F) 宽度属性的 Unicode 字符. 下面这个 C 函数用来测试
一个 Unicode 字符是否是宽字符并需要用覆盖两个字符单元的字形来显示:
/* This function tests, whether the ISO 10646/Unicode character code
* ucs belongs into the East Asian Wide (W) or East Asian FullWidth
* (F) category as defined in Unicode Technical Report #11. In this
* case, the terminal emulator should represent the character using
* a glyph from a double-wide font that covers two normal (Latin)
* character cells. */
int iswide(int ucs)
{
if (ucs < 0x1100)
return 0;
return
(ucs >= 0x1100 && ucs <= 0x115f) || /* Hangul Jamo */
(ucs >= 0x2e80 && ucs <= 0xa4cf && (ucs & ~0x0011) != 0x300a &&
ucs != 0x303f) || /* CJK ... Yi */
(ucs >= 0xac00 && ucs <= 0xd7a3) || /* Hangul Syllables */
(ucs >= 0xf900 && ucs <= 0xfaff) || /* CJK Compatibility Ideographs */
(ucs >= 0xfe30 && ucs <= 0xfe6f) || /* CJK Compatibility Forms */
(ucs >= 0xff00 && ucs <= 0xff5f) || /* Fullwidth Forms */
(ucs >= 0xffe0 && ucs <= 0xffe6);
}
某些 C 库也提供了函数
#include <wchar.h>
int wcwidth(wchar_t wc);
int wcswidth(const wchar_t *pwcs, size_t n);
用来测定该宽字符 wc 或由 pwcs 指向的字符串中的 n 个宽字符码 (或者少于n 个宽
字符码, 如果在 n 个宽字符码之前遇到一个空宽字符的话) 所要求的列位置的数量.
这
些函数定义在 Open Group 的 Single UNIX Specification 里. 一个拉丁/希腊/斯拉夫
/等等的字符要求一个列位置, 一个 CJK 象形文字要求两个, 而一个组合字符要求零个.
最终 xterm 是否会支持从右到左的书写?
此刻还没有给 xterm 增加从右到左功能的计划. 希伯来与阿拉伯用户因此不得不靠应用
程序在将希伯来文与阿拉伯文字符串送到终端前按左方向翻转它们, 换句话说, 双向处
理必须在应用程序里完成, 而不是在 xterm 里. 至少, 希伯来与阿拉伯文在预作字形的
可用性的形式上, 以及提示表格上的支持, 比 ISO 8859 要有所改进. 现在还远没有决
定 xterm 是否支持双向文字以及该怎样工作. ISO 6429 = ECMA-48 和 Unicode bidi
algorithm 都提供了可供选择的开始点. 也可以参考 ECMA Technical
Report TR/53. Xterm 也不处理阿拉伯文, Hangul 或 印度文本的格式化算法, 而且现
在还不太清楚在 VT100 模拟器里处理是否可行和值得, 或者应该留给应用软件去处理.
如果你打算在你的应用程序里支持双向文字输出, 看一下 FriBidi, Dov Grobgeld
的
Unicode 双向算法的自由实现.
我在哪儿能找到 ISO 10646-1 X11 字体?
在过去的几个月里出现了相当多的 X11 的 Unicode 字体, 并且还在快速增多.
Markus Kuhn 正和其他许多志愿者一起工作于手动将旧的
-misc-fixed-*-iso8859-1 字
体扩展到覆盖所有的欧洲字符表 (拉丁, 希腊, 斯拉夫, 国际音标字母表. 数学与技术
符号, 某些字体里甚至有亚美尼亚语, 乔治亚语, 片假名等). 更多信息请参考
Unicode
fonts and tools for X11 页. 这些字体将与 XFree86 一起分发. 例如字体
-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
(旧的 xterm 的 fixed 缺省字体的一个扩展, 包括超过 3000 个字符) 已经是XFree86
3.9 snapshot 的一部分了.
Markus 也做好了 X11R6.4 distribution 里所有的 Adobe 和 B&H BDF 字体的 ISO
10646 版本. 这些字体已经包含了全部 Postscript 字体表 (大约 30 个额外的字符,
大
部分也被 CP1252 MS-Windows 使用, 如 smart quotes, dashes 等), 在 ISO 8859-1
编码下是没有的. 它们在 ISO 10646-1 版本里是完全可用的.
XFree86 4.0 将携带一个集成的 TrueType 字体引擎, 这使得你的 X 应用程序可以将任
何 Apple/Microsoft 字体用于 ISO 10646-1 编码.
将来的 XFree86 版本很有可能从分发版中去除大多数旧的 BDF 字体, 取而代之的是 I
SO 10646-1 编码的版本. X 服务器则会增加一个自动编码转换器, 只有当旧的 8 位软
件请求一个类似于 ISO 8859-* 编码的字体时, 才虚拟地从 ISO 10646-1 字体文件中创
建一个这样的字体. 现代软件应该优先地直接使用 ISO 10646-1 字体编码.
ClearlyU (cu12) 是一个非常有用的 X11 的 12 点阵, 100 dpi 的 proportional
ISO 10646-1 BDF 字体, 包含超过 3700 个字符, 由 Mark Leisher 提供 (样例图象).
Roman Czyborra 的 GNU Unicode font 项目工作于收集一个完整的与免费的
8×16/16×16 pixel Unicode 字体. 目前已经覆盖了 34000 个字符.
etl-unicode 是一个 ISO 10646-1 BDF 字体, 由 Primoz Peterlin 提供.
Unicode X11 字体名字以 -ISO10646-1 结尾. 这个 X 逻辑字体描述器 (X Logical
Font Descriptor, XLFD) 的 CHARSET_REGISTRY 和 CHARSET_ENCODING 域里的值已经为所
有 Unicode 和 ISO 10646-1 的 16 位字体而正式地注册了. 每个 *-ISO10646-1 字体
都包含了整个 Unicode 字符集里的某几个子集, 而用户必须弄清楚他们选择的字体覆盖
哪几个他们需要的字符子集.
*-ISO10646-1 字体通常也指定一个 DEFAULT_CHAR 值, 指向一个非 Unicode 字形, 用
来表示所有在该字体里不可用的字符 (通常是一个虚线框, 一个 H 的大小, 位于 0x1F
或 0xFFFE). 这使得用户至少能知道这儿有一个不支持的字符. xterm 用的小的定宽字
体比如 6x13 等, 将永远无法覆盖所有的 Unicode, 因为许多文字比如日本汉字只能用
比欧洲用户广泛使用的大的象素尺寸才能表示. 欧洲使用的典型的 Unicode 字体将只包
含大约 1000 到 3000 个字符的子集.
我怎样才能找出一个 X 字体里有哪些字形?
X 协议无法让一个应用程序方便地找出一个 cell-spaced 字体提供哪些字形, 它没有为
字体提供这样的量度. 因此 Mark Leisher 和 Erik van de Poel (Netscape) 指定了一
个新的 _XFREE86_GLYPH_RANGES BDF 属性, 告诉应用程序该 BDF 字体实现了哪个Unicode
子集. Mark Leisher 提供了一些样例代码以产生并扫描这个属性, 而
Xmbdfed 3.9 以及更高版本将自动将其加入到由它产生的每个 BDF 文件里.
与 UTF-8 终端模拟器相关的问题是什么?
VT100 终端模拟器接受 ISO 2022 (=ECMA-35) ESC 序列, 用于在不同的字符集间切换.
UTF-8 在 ISO 2022 的意义里是一个 "其他编码系统" (参考 ECMA 35 的 15.4 节). U
TF-8 是在 ISO 2022 SS2/SS3/G0/G1/G2/G3 世界之外的, 因此如果你从 ISO 2022 切换
到 UTF-8, 所有的 SS2/SS3/G0/G1/G2/G3 状态都变得没有意义了, 直到你离开 UTF-8
并切换回 ISO 2022. UTF-8 是一个没有国家的编码, 也就是一个自我终结的短字节序列
完全决定了它代表什么字符, 独立于任何国家的切换. G0 与 G1 在 ISO 10646 里与在
ISO 8859-1 里相同, 而 G2/G3 在 ISO 10646 里不存在, 因为任何字符都有固定的位
置, 因而不会发声切换. 在 UTF-8 模式下, 你的终端不会因为你偶然地装入一个二进制
文件而切换入一种奇怪图形字符模式. 这使得一个终端在 UTF-8 模式下比在 ISO 2022
模式下要健壮得多, 而且因此可以有办法将终端锁在 UTF-8 模式里, 而不会偶然地回
到 ISO 2022 世界里.
ISO 2022 标准指定了一系列的 ESC % 序列, 以离开 ISO 2022 世界 (指定其他的编码
系统, DOCS), 用于 UTF-8 的许多这样的序列已经注册进了 ISO 2375 International
Register of Coded Character Sets:
ESC %G 从 ISO 2022 里激活一个未指定实现级别的 UTF-8 模式且允许再返回 ISO
2022.
ESC %@ 从 UTF-8 回到 ISO 2022, 条件是通过 ESC %G 进入的 UTF-8
ESC %/G 切换进 UTF-8 级别 1 且不返回.
ESC %/H 切换进 UTF-8 级别 2 且不返回.
ESC %/I 切换进 UTF-8 级别 3 且不返回.
当一个终端模拟器在 UTF-8 模式时, 任何 ISO 2022 逃脱码序列例如用于切换G2/G3
等的都被忽略. 一个在 UTF-8 模式下的终端模拟器唯一会执行的 ISO 2022 序列是
ESC %@ 以从 UTF-8 返回 ISO 2022 方案.
UTF-8 仍然允许你使用象 CSI 这样的 C1 控制字符, 尽管 UTF-8 也使用 0x80-0x9F
范
围里的字节. 重要的是必须理解在 UTF-8 模式下的终端模拟器必须在执行任何控制字符
前对收到的字节流运用 UTF-8 解码器. C1 字符与其他任何大于 U+007F 的字符一样需
先经过 UTF-8 解码.
已经有哪些支持 UTF-8 的应用程序了?
Yudit 是 Gaspar Sinai 的自由 X11 Unicode 编辑器
Mined 98 由 Thomas Wolff 提供, 是一个可以处理 UTF-8 的文本编辑器.
less 版本 346 或更高, 支持 UTF-8
C-Kermit 7.0 在传输, 终端, 及文件字符集方面支持 UTF-8.
Sam 是 Plan9 的 UTF-8 编辑器, 类似于 vi, 也可用于 Linux 和 Win32. (Plan9是第
一个完全转向 UTF-8, 将其作为字符编码的操作系统.)
9term 由 Matty Farrow 提供, 是一个 Plan9 操作系统的 Unicode/UTF-8 终端模拟器
的 Unix 移植.
Wily 是一个 Plan9 Acme 编辑器的 Unix 实现.
ucm-0.1 是 Juliusz Chroboczek 的 Unicode 字符映射表, 一个小工具, 使你可以选中
任何一个 Unicode 字符并粘贴进你的应用程序.
有哪些用于改善 UTF-8 支持的补丁?
Robert Brady 提供了一个 patch for less 340 (现在已经合并进了 less 344)
Bruno Haible 提供了用于 stty, Linux 核心 tty 等的 多个补丁.
Otfried Cheong 编写了 Unicode encoding for GNU Emacs 工具箱, 使 Mule 能够处理
UTF-8 文件.
Postscript 字形的名字与 UCS 代码是怎么关联的?
参考 Adobe 的 Unicode and Glyph Names 指南.
X11 的剪切与粘贴工作在 UTF-8 时是如何完成的?
参考 Juliusz Chroboczek 的 客户机间 Unicode 文本的交换 草案, 对 ICCCM 的一个
扩充的建议, 用一个新的可用于属性类型(property type)和选中(selection)目标的原
子 UTF8_STRING 来处理 UTF-8 的选中.
现在有没有用于处理 Unicode 的免费的库?
IBM Classes for UnicodeMark Leisher 的 UCData Unicode 字符属性库和 wchar_t
支持测试码.
各种 X widget 对 Unicode 支持的现状如何?
GScript - Unicode 与复杂文本处理 是一个为 GTK+ 增加全功能的 Unicode 支持的项目.
Qt 2.0 现在支持使用 *-ISO10646-1 字体了.
FriBidi 是 Dov Grobgeld 的 Unicode 双向算法的免费实现.
有什么关于这个话题的好的邮件列表?
你确实应该订阅的是 uni...@unicode.org 邮件列表, 这是发现标准的作者和其他许多
领袖的话语的最好办法. 订阅方法是, 用 "subscribe" 作为标题, "subscribe YOUR@E
MAIL.ADDRESS unicode" 作为正文, 发一条消息到 unicode...@unicode.org.
也有一个专注与改进通常用于 GNU/Linux 系统上应用程序的 UTF-8 支持的邮件列表 l
inux...@nl.linux.org. 订阅方法是, 以 "subscribe linux-utf8" 为内容, 发送消
息到 majo...@nl.linux.org. 你也可以浏览 linux-utf8 archive
其他相关的还有 XFree86 组的 "字体" 与 "i18n" 列表, 但你必须成为一名正式的开发
者才能订阅.
更多参考
Bruno Haible 's Unicode HOWTO.
The Unicode Standard, Version 2.0
Unicode Technical Reports
Mark Davis' Unicode FAQ
ISO/IEC 10646-1:1993
Frank Tang's I?t?rnati?nàliz?ti?n Secrets
Unicode Support in the Solaris 7 Operating Environment
The USENIX paper by Rob Pike and Ken Thompson on the introduction of UTF-8
under Plan9 reports about the first operating system that migrated already
in
1992 completely to UTF-8 (which was at the time still called UTF-2).
Li18nux is a project initiated by several Linux distributors to enhance
Unicode support for Linux.
The Online Single Unix Specification contains definitions of all the ISO C A
mendment 1 function, plus extensions such as wcwidth().
The Open Group's summary of ISO C Amendment 1.
GNU libc
The Linux Console Tools
The Unicode Consortium character database and character set conversion
tables
are an essential resource for anyone developping Unicode related tools.
Other conversion tables are available from Microsoft and Keld Simonsen's
WG15
archive.
Michael Everson's ISO10646-1 archive contains online versions of many of the
more recent ISO 10646-1 amendments, plus many other goodies. See also his R
oadmaps to the Universal Character Set.
An introduction into The Universal Character Set (UCS).
Otfried Cheong's essey on Han Unification in Unicode
The AMS STIX project is working on revising and extending the mathematical c
haracters for Unicode 4.0 and ISO 10646-2.
Jukka Korpela's Soft hyphen (SHY) - a hard problem? is an excellent discussi
on of the controversy surrounding U+00AD.
James Briggs' Perl, Unicode and I18N FAQ.
我不断地将新的材料加入这份文档, 因此请定期来查看. 欢迎所有关于改进的建议, 以
及自由软件社区里关于改善 UTF-8 支持的广告. UTF-8 用在 Linux 里是新近的事, 因
此我们在将来的几个月里可以见到大量的进展.
特别感谢 Ulrich Drepper 和 Bruno Haible 的有价值的注解
Markus Kuhn <<Marku...@cl.cam.ac.uk>
创建于 1999-06-04 -- 最近更新于 2000-01-15 --
http://www.cl.cam.ac.uk/~mgk25/unicode.html
--
终极super zhongjisuper
4361z0aa0-c5e93as0a66-8634jeb6e
#############################################
Email/GTalk：zhongjisuper0[at]gmail.com
吟风茶馆：http://www.yfcg.com.cn/
Blog原创：http://zhjsuper.blogspot.com/
Blog转载-计算机相关：http://zhongjisuper0.blogspot.com/
Blog转载-其他：http://zhongjisuper1.blogspot.com/
"终极super" <zhongj...@gmail.com> 写入消息
news:ebn5q6$b4t$1...@news.yaako.com...
TKGG
On Sun, 13 Aug 2006 20:52:45 +0800, "终极super" <zhongj...@gmail.com>
wrote:
>UTF-8 and Unicode FAQ
>by Markus Kuhn
>中国LINUX论坛翻译小组 xLoneStar[译] 2000年2月
--
Reguards,
TKGG
---
Posted via news://freenews.netfront.net
Complaints to ne...@netfront.net
Lu Wei
> 一直在琢磨这个问题，按理UTF-8兼容GB2312、BIG5、EUC-JP等多种国家的语言编码，至少台湾，香港等海外朋友都可以看到我的blog，而且不会出现乱码！但那天我在链接cnblog的最新链接的时候，发现他们提供的都是GB2312，结果出来一堆乱码，这让我很矛盾。看来国内的bloger还是太局限于GB2312编码，虽然是国家标准码，但UTF-8应该是大趋所势，看看对岸的台湾兄弟大都采用了UTF-8，觉得就比较国际话。
>
> 想想又不想放弃对GB2312的支持，又不想太局限与GB2312，真是郁闷呀：（
>
> 大家说呢？
>
>
字，兼容的更好，所以我默认就是用UTF8发帖。
--
Regards
Lu Wei
火柴
--
火柴
"No one talks peace unless he's ready to back it up with war."
"He talks of peace if it is the only way to live."
-- Colonel Green and Surak of Vulcan, "The Savage Curtain",
stardate 5906.5.
流星99
都是属于Unicode体系的变体，而Unicode体系就更加复杂了，包括了一些统一码区，
以及无数个自定义码区，所以，UTF-8并不是一帖整治乱码的良药，相反，
因为UTF-8造成的乱码有时候比以前的各国的各自编码更多.......
举个不恰当的例子，正如现在的域名体系，已经统一定义了.COM/.NET/ORG乃至于.CN/.TW/.JP等等，
但是对于其它的却没有统一，或许你在使用163.com、google.cn、yahoo.tw时都没有问题，
但是如果你想使用"网易.com"或者"谷歌.cn"或者"奇摩.tw"就会问题成堆.......
在 Sun, 13 Aug 2006 20:26:50 +0800 时, "终极super" <zhongj...@gmail.com> 写了:
--
>UTF-8是不是可以支持各国的文字？那样他的编码当然就复杂了，
>你能不能介绍一下UTF-8的技术细节
>"GoldenMouse" <golden...@sina.com.cn> 写入消息
>news:ebmvtl$4ee$1...@news.yaako.com...
>> UTF-8是与GB2312不兼容的，UTF-8本身就是偏向欧美的设计。如果大家都用UTF-
>> 8，欧美国家的人们可以用底成本达到编码统一，但是象中国等非英语国家则面临
>> 巨大的转换成本和将来的运行成本。说UTF-8是技术歧视似乎并不算过。
>>
>> 终极super 写道:
>>> 一直在琢磨这个问题，按理UTF-8兼容GB2312、BIG5、EUC-JP等多种国家的语言编码，至少台湾，香港等海外朋友都可以看到我的blog，而且不会出现乱码！但那天我在链接cnblog的最新链接的时候，发现他们提供的都是GB2312，结果出来一堆乱码，这让我很矛盾。看来国内的bloger还是太局限于GB2312编码，虽然是国家标准码，但UTF-8应该是大趋所势，看看对岸的台湾兄弟大都采用了UTF-8，觉得就比较国际话。
>>>
>>> 想想又不想放弃对GB2312的支持，又不想太局限与GB2312，真是郁闷呀：（
>>>
>>> 大家说呢？
--
我是流星，虽然一闪而过，
也希望能留下美丽的光芒。
欢迎光临 news://news.cn99.com/cn.fan
中国fans的新闻组，中国fans的家......
流星99
GB2312=GBK（对于*NIX系统，我个人建议把GB2312映射为GBK，以GBK为默认），
所以说GB2312/GBK过时，是不准确的（其实GB18030并不比GBK多多少字符），
也基于此点，我坚持使用GB2312/GBK，估计在将来很长一段时间内可能依然如此......
在 Sun, 13 Aug 2006 19:37:01 +0800 时, "batch" <chin...@hotmail.com> 写了:
--
>GB2312早就过时了。有很多字符GB2312根本不行，所以我要么用UTF-8，要么用GB18030。
>"终极super" <zhongj...@gmail.com> 写入消息 news:ebmrji$v31$1...@news.yaako.com...
>> 一直在琢磨这个问题，按理UTF-8兼容GB2312、BIG5、EUC-JP等多种国家的语言编码，至少台湾，香港等海外朋友都可以看到我的blog，而且不会出现乱码！但那天我在链接cnblog的最新链接的时候，发现他们提供的都是GB2312，结果出来一堆乱码，这让我很矛盾。看来国内的bloger还是太局限于GB2312编码，虽然是国家标准码，但UTF-8应该是大趋所势，看看对岸的台湾兄弟大都采用了UTF-8，觉得就比较国际话。
>>
>> 想想又不想放弃对GB2312的支持，又不想太局限与GB2312，真是郁闷呀：（
>>
>> 大家说呢？
--
流星99
实际上根本就没有考虑到亚洲地区的传统编码体系，甚至在某些字符的映射上，
出现了歧义的情况（举例而言，在部分日文字符上就出现了转换时的歧义，
引起了多对一和一对多的糟糕情况，这也是很多日本人坚决抵制UTF的原因），
如果亚洲地区不分青红皂白全盘接受的话，确实有可能导致很多问题.......
可惜我没有足够的影响力和时间，否则我也想发动一场抵制UTF-8的运动呢~~
在 Sun, 13 Aug 2006 18:46:12 +0800 时, GoldenMouse <golden...@sina.com.cn> 写了:
--
--
流星99
但是并不意味着UTF-8/UNICODE就是整治乱码的万能良方，在某些场合，UTF-8/Unicode甚至可能引起新的乱码，
因此，假如你的访问者不仅仅是华人的话，不建议你用UTF-8，而在博客以外的场合（比如邮件、网站网页、
新闻组帖子等等等），也不建议使用UTF-8.......
在 Sun, 13 Aug 2006 17:32:37 +0800 时, "终极super" <zhongj...@gmail.com> 写了:
--
>一直在琢磨这个问题，按理UTF-8兼容GB2312、BIG5、EUC-JP等多种国家的语言编码，至少台湾，香港等海外朋友都可以看到我的blog，而且不会出现乱码！但那天我在链接cnblog的最新链接的时候，发现他们提供的都是GB2312，结果出来一堆乱码，这让我很矛盾。看来国内的bloger还是太局限于GB2312编码，虽然是国家标准码，但UTF-8应该是大趋所势，看看对岸的台湾兄弟大都采用了UTF-8，觉得就比较国际话。
>
>想想又不想放弃对GB2312的支持，又不想太局限与GB2312，真是郁闷呀：（
>
>大家说呢？
--
batch
因为在粤语地区多数会偏向用GBK、GB18030，写入粤语文字的需要用到。
"流星99" <bian...@bianlule.3322.org> 写入消息 news:44ef2dde...@127.0.0.1...
batch
终极super
--
终极super zhongjisuper
4361z0aa0-c5e93as0a66-8634jeb6e
#############################################
Email/GTalk：zhongjisuper0[at]gmail.com
吟风茶馆：http://www.yfcg.com.cn/
Blog原创：http://zhjsuper.blogspot.com/
Blog转载-计算机相关：http://zhongjisuper0.blogspot.com/
Blog转载-其他：http://zhongjisuper1.blogspot.com/
""火柴"" <willi...@gmail.com> 写入消息
news:87ejvku...@www.williamxu.com...
火柴
> 因为我是GB2312，所以他回我的帖，客户端应该会自动调整
我的比较强悍，你是 gb2312, gbk, 还是啥，我的回复都变成了 utf-8. (其实我
没弄明白怎样据情况不用 utf-8..)
--
火柴
There will always be beer cans rolling on the floor of your car when
the boss asks for a lift home from the office.
GoldenMouse
系统都不兼容。所谓兼容，是说现有文档可以不必转换直接使用，也就是说所有的
“字”在两种系统中使用相同的编码。例如，某个字在GB2312中的编码是“A8A8”，这
个字在GB18030中的编码还是“A8A8”，而在UTF中的编码却成了“A8A8A8”，这时候可
以说GB18030是兼容GB2312的，但UTF是与GB2312不兼容的。兼容与“可以容纳”是两
个不同的概念，UTF对于包括中文系统在内的非拉丁系统是“可以容纳”，而不是“兼
容”。
如果欧美国家使用UTF，他们的系统没有任何变化，或者变化很小。而中国等亚洲
国家使用UTF则成本高昂。首先，软件系统要修改，大量的检索、统计、翻译、存
储程序以及大屏幕显示系统的驱动程序和嵌入系统等都需要升级甚至重写。然后，
原有数据必须转换，海量的资料、文档、记录等都要重新编码。更要命的是，从
GB2312转到UTF后，多数中文字从两字节变成了三字节，你的存储能力和传输能力
凭空就减少了三成，这可不是一次性的，是要跟你一辈子的。
有不少人拿博客说事儿，举例说改成UTF以后如何如何方便。我建议还是不要说这
种小儿科的话吧，制定国家标准，博客基本可以忽略不计的。我们个人喜欢用什么
编码其实无所谓，但是对于应用系统则必须有个标准，这个标准当然是中国国家标
准而不是外国标准，即使它冠以“国际”的名义。GB2312和GB18030是中国强制执行
的国家标准，也就是说必须要支持的，GBK是个建议标准。GB18030包含并兼容
GB2312。不支持GB18030的系统，在中国被禁止销售。虽然个人喜欢用什么编码无
所谓，但是使用符合中国国家标准的编码对我们自己相当有好处。
我现在使用GB18030。而Linux对GB18030的支持非常好，Windows则差些，因为微软
本来不打算支持GB18030的。
终极super 写道:
> UTF-8是不是可以支持各国的文字？那样他的编码当然就复杂了，
> 你能不能介绍一下UTF-8的技术细节
>
GoldenMouse
的人，不管他喜欢不喜欢，他必定使用GB编码，因为那是国家标准，要和其他也有
影响力的人交流，就得使用国家标准。
流星99 写道:
>
> 可惜我没有足够的影响力和时间，否则我也想发动一场抵制UTF-8的运动呢~~
>
東瓜
--
火柴
[...]
sigh...utf-8 一种编码可以显示多国语言，对用户而言这不是很方便的一件事么？
省得不管是为了中文的 gb*, 日文的 iso-2022-jp, shift_jis, ...还是其它各种
编码弄得晕头转向。
> 我现在使用GB18030。而Linux对GB18030的支持非常好，Windows则差些，因为微软
> 本来不打算支持GB18030的。
这话就不对了。我想 linux 支持 gb18030 是很少的，远不能说非常好。我现在看
你的帖子，事实上只能是把 gb18030 当成 gb2312 来解析。
ps. 如果你有订过 debian-chinese-gb 的 ML 就会知道由于各种不同的中文编码混
在一起弄得有多乱，现在大家基本上都倾向于采用 utf-8 了。
--
火柴
The biggest mistake you can make is to believe that you are working for
someone else.
GoldenMouse
火柴 写道:
> sigh...utf-8 一种编码可以显示多国语言，对用户而言这不是很方便的一件事么？
> 省得不管是为了中文的 gb*, 日文的 iso-2022-jp, shift_jis, ...还是其它各种
> 编码弄得晕头转向。
如果你以前从没有用过电脑，UTF确实很诱人。但是事实并非如此，我们现在不能
不考虑兼容问题。
> 我想 linux 支持 gb18030 是很少的，远不能说非常好。我现在看
> 你的帖子，事实上只能是把 gb18030 当成 gb2312 来解析。
这大概与你的设置有关，你可以去技术组寻求帮助，在别人的指导下重新设置一下。
> ps. 如果你有订过 debian-chinese-gb 的 ML 就会知道由于各种不同的中文编码混
> 在一起弄得有多乱，现在大家基本上都倾向于采用 utf-8 了。
大家都倾向于UTF-8了么？这个“大家”是谁？能代表多少中国人？
你现在知道了不同中文编码混在一起有多乱，但是你知道用UTF-8以后有多乱么？
batch
XP/2003则已经有GB18030的支持，只需要安装GB18030的字体就立刻可以用，而不像Win9x/2000那样需要安装支持程序。
到了Windows Vista就更加彻底了，连内置的中文字体(像宋体)都是GB18030支持包的字体，各方面也是支持GB18030。
这对我来说是好事情，因为我更加偏向用GB18030。
"GoldenMouse" <golden...@sina.com.cn> 写入消息 news:ebo20e$8pp$1...@news.yaako.com...
snnn
也就是说如果locale是GB18030则就无法输入汉字
除非你hack
量子公民
火柴
> 火柴 写道:
>> sigh...utf-8 一种编码可以显示多国语言，对用户而言这不是很方便的一件事么？
>> 省得不管是为了中文的 gb*, 日文的 iso-2022-jp, shift_jis, ...还是其它各种
>> 编码弄得晕头转向。
>
> 如果你以前从没有用过电脑，UTF确实很诱人。但是事实并非如此，我们现在不能
> 不考虑兼容问题。
别这么说，我以前都是 gb*, 现在硬盘上的东西基本上都转成了 utf-8，感觉方便
多了。兼容性是个问题，但是不能说因为有这个问题就要绕行。如果都能慢慢转向
utf-8, 岂不皆大欢喜？就个人用户来说，转换其实也不并不复杂，简单地用
iconv, convmv 等转换工具就能实现。
>> 我想 linux 支持 gb18030 是很少的，远不能说非常好。我现在看
>> 你的帖子，事实上只能是把 gb18030 当成 gb2312 来解析。
>
> 这大概与你的设置有关，你可以去技术组寻求帮助，在别人的指导下重新设置一
> 下。
有那么简单就好了。我直接告诉你吧，Emacs 22 就只支持 gb2312。
>> ps. 如果你有订过 debian-chinese-gb 的 ML 就会知道由于各种不同的中文编码混
>> 在一起弄得有多乱，现在大家基本上都倾向于采用 utf-8 了。
>
> 大家都倾向于UTF-8了么？这个“大家”是谁？能代表多少中国人？
何必上纲上线呢？难道要公投？前两句我说的是 debian-chinese-gb ML, 我所指
的大家即是指 ML 上的人。
> 你现在知道了不同中文编码混在一起有多乱，但是你知道用UTF-8以后有多乱么？
我只知道用 utf-8 省心多了，一般软件都会有支持。
--
火柴
Lead me not into temptation... I can find it myself.
batch
"量子公民" <airo...@gmail.com> 写入消息 news:1155534516.3...@75g2000cwc.googlegroups.com...
> Unicode中CJK表意文字编码的制定,中日韩三国专家都参与了啊...
>
金箭
量子公民 写道:
> Unicode中CJK表意文字编码的制定,中日韩三国专家都参与了啊...
金箭
GoldenMouse 写道:
GoldenMouse
没问题。
snnn 写道:
> X到目前还不支持GB18030的输入法。
> 也就是说如果locale是GB18030则就无法输入汉字
> 除非你hack
>
>
>
GoldenMouse
量子公民 写道:
> Unicode中CJK表意文字编码的制定,中日韩三国专家都参与了啊...
GoldenMouse
火柴 写道:
> 别这么说，我以前都是 gb*, 现在硬盘上的东西基本上都转成了 utf-8，感觉方便
> 多了。兼容性是个问题，但是不能说因为有这个问题就要绕行。如果都能慢慢转向
> utf-8, 岂不皆大欢喜？就个人用户来说，转换其实也不并不复杂，简单地用
> iconv, convmv 等转换工具就能实现。
就个人来说，什么都不复杂。如果说个人喜好，那么随便啦……
> 有那么简单就好了。我直接告诉你吧，Emacs 22 就只支持 gb2312。
这个逻辑似乎有点问题。Emacs目前只支持GB2312能说明GB18030不好么？
> 何必上纲上线呢？难道要公投？前两句我说的是 debian-chinese-gb ML, 我所指
> 的大家即是指 ML 上的人。
我绝对没有上纲上线的意思，只是因为你把“大家”抬出来了，我就顺便问一句。现在知道
了，这个“大家”只是少数人。（Make Love ?）
> 我只知道用 utf-8 省心多了，一般软件都会有支持。
还是那句话，如果说个人喜好，那么随便啦……
GoldenMouse
金箭 写道:
> 给单位做网站的时候我也掂量了几次，最终还是GB了。
火柴
>> 有那么简单就好了。我直接告诉你吧，Emacs 22 就只支持 gb2312。
>
> 这个逻辑似乎有点问题。Emacs目前只支持GB2312能说明GB18030不好么？
有没有搞错？你说 linux 下 gb18030 的支持非常好，我举了个反例而已。
> 我绝对没有上纲上线的意思，只是因为你把“大家”抬出来了，我就顺便问一句。
> 现在知道 了，这个“大家”只是少数人。（Make Love ?）
你连 ML 是什么意思都不知道，又怎么知道是少数人？赫赫。。
--
火柴
题目:《春怀示邻里》
作者:陈师道（１０５３－１１０１）
断墙着雨蜗成字，老屋无僧燕作家，
剩欲出门追语笑，却嫌归鬓著尘沙。
风翻蛛网开三面，雷动蜂窠趁两衙。
屡失南邻春事约，只今容有未开花。
Lu Wei
> "终极super" <zhongj...@gmail.com> writes:
>
>> 因为我是GB2312，所以他回我的帖，客户端应该会自动调整
>
> 我的比较强悍，你是 gb2312, gbk, 还是啥，我的回复都变成了 utf-8. (其实我
> 没弄明白怎样据情况不用 utf-8..)
>
的字符才会转成uft-8。
--
Regards
Lu Wei
Lu Wei
> 无需抵制。凡是使用UTF的人，他们的影响力更小，小到可以忽略。真正有影响力
> 的人，不管他喜欢不喜欢，他必定使用GB编码，因为那是国家标准，要和其他也有
> 影响力的人交流，就得使用国家标准。
>
--
Regards
Lu Wei
Lu Wei
> 基本上不反对，某种意义上而言，Unicode/UTF本身就是西方强加于亚洲地区的标准，
> 实际上根本就没有考虑到亚洲地区的传统编码体系，甚至在某些字符的映射上，
> 出现了歧义的情况（举例而言，在部分日文字符上就出现了转换时的歧义，
> 引起了多对一和一对多的糟糕情况，这也是很多日本人坚决抵制UTF的原因），
> 如果亚洲地区不分青红皂白全盘接受的话，确实有可能导致很多问题.......
>
> 可惜我没有足够的影响力和时间，否则我也想发动一场抵制UTF-8的运动呢~~
乎都是“西方”的，这是历史事实，哪能说都是“强加”过来的呢，实际上是我们必须
“拿过来”。要是没有NNTP标准我们哪能在这发帖啊。至少现在由于技术的发展标准
的制定也国际化了，unicode的计划里几乎包含了全球的语言，有各国的专家在里
面，加入、推动这个协作才是更有意义的事情。GB***有这么完整的解决方案吗？
能在技术上成为国际标准吗？
--
Regards
Lu Wei
batch
"Lu Wei" <inv...@address.invalid> 写入消息 news:ebphkk$jra$2...@news.yaako.com...
Lu Wei
> 射手网上的是GBK……
射手网都是外挂字幕。我说的是mkv，大多数是动画
TKGG
>> 因为我是GB2312，所以他回我的帖，客户端应该会自动调整
>我的比较强悍，你是 gb2312, gbk, 还是啥，我的回复都变成了 utf-8. (其实我
>没弄明白怎样据情况不用 utf-8..)
因为每个客户端软件的设定都不同啊。
--
Reguards,
TKGG
---
Posted via news://freenews.netfront.net
Complaints to ne...@netfront.net
TKGG
反正平时偶只上新闻组灌水，要求也不是太高，能凑合着用就好了。
On Mon, 14 Aug 2006 16:31:18 +0800, GoldenMouse <golden...@sina.com.cn>
wrote:
>嘿嘿，标准就是标准，她并不完美，但她是标准。
>
>金箭 写道:
>> 给单位做网站的时候我也掂量了几次，最终还是GB了。
--
Regards,
winsphinX
"终极super" <zhongj...@gmail.com> 写入消息新闻:ebmrji$v31$1...@news.yaako.com...
> 一直在琢磨这个问题，按理UTF-8兼容GB2312、BIG5、EUC-JP等多种国家的语言编码，至少台湾，香港等海外朋友都可以看到我的blog，而且不会出现乱码！但那天我在链接cnblog的最新链接的时候，发现他们提供的都是GB2312，结果出来一堆乱码，这让我很矛盾。看来国内的bloger还是太局限于GB2312编码，虽然是国家标准码，但UTF-8应该是大趋所势，看看对岸的台湾兄弟大都采用了UTF-8，觉得就比较国际话。
>
> 想想又不想放弃对GB2312的支持，又不想太局限与GB2312，真是郁闷呀：（
>
> 大家说呢？
>
>
> --
> 终极super zhongjisuper
> 4361z0aa0-c5e93as0a66-8634jeb6e
> #############################################
> Email/GTalk：zhongjisuper0[at]gmail.com
> 吟风茶馆：http://www.yfcg.com.cn/
> Blog原创：http://zhjsuper.blogspot.com/
> Blog转载-计算机相关：http://zhongjisuper0.blogspot.com/
> Blog转载-其他：http://zhongjisuper1.blogspot.com/
>
winsphinX
"GoldenMouse" <golden...@sina.com.cn> 写入消息新闻:ebpbij$dkq$1...@news.yaako.com...
winsphinX
"GoldenMouse" <golden...@sina.com.cn> 写入消息新闻:ebo20e$8pp$1...@news.yaako.com...
winsphinX
"snnn" <snn...@gmail.com> 写入消息新闻:ebp2as$311$2...@news.yaako.com...
> X到目前还不支持GB18030的输入法。
> 也就是说如果locale是GB18030则就无法输入汉字
> 除非你hack
>
>
>
winsphinX
linuxsir.org有不少讨论gb vs utf 的帖子
"流星99" <bian...@bianlule.3322.org> 写入消息新闻:44ef2dde...@127.0.0.1...
> GB2312确实是过时了，但是GBK并不过时，而对于Windows NT内核而言，
> GB2312=GBK（对于*NIX系统，我个人建议把GB2312映射为GBK，以GBK为默认），
> 所以说GB2312/GBK过时，是不准确的（其实GB18030并不比GBK多多少字符），
> 也基于此点，我坚持使用GB2312/GBK，估计在将来很长一段时间内可能依然如此......
>
> 在 Sun, 13 Aug 2006 19:37:01 +0800 时, "batch" <chin...@hotmail.com> 写了:
> --
>
>>GB2312早就过时了。有很多字符GB2312根本不行，所以我要么用UTF-8，要么用GB18030。
>>
>>"终极super" <zhongj...@gmail.com> 写入消息
>>news:ebmrji$v31$1...@news.yaako.com...
>>> 一直在琢磨这个问题，按理UTF-8兼容GB2312、BIG5、EUC-JP等多种国家的语言编码，至少台湾，香港等海外朋友都可以看到我的blog，而且不会出现乱码！但那天我在链接cnblog的最新链接的时候，发现他们提供的都是GB2312，结果出来一堆乱码，这让我很矛盾。看来国内的bloger还是太局限于GB2312编码，虽然是国家标准码，但UTF-8应该是大趋所势，看看对岸的台湾兄弟大都采用了UTF-8，觉得就比较国际话。
>>>
>>> 想想又不想放弃对GB2312的支持，又不想太局限与GB2312，真是郁闷呀：（
>>>
>>> 大家说呢？
>
> --
> 我是流星，虽然一闪而过，
> 也希望能留下美丽的光芒。
> 欢迎光临 news://news.cn99.com/cn.fan
> 中国fans的新闻组，中国fans的家......
NewBlue
在编码的选择上是个特别头疼的问题,Unicode标准里面有utf7 utf8 utf16 utf32,
中国有gb2312 gbk gb18030,如果从国际化方面看,同样是多字节编码的unicode,能
够表达范围更大.中国的标准虽然也用多个字节,但却只是表达中文范围的内容.
unicode依旧还是有很讨厌的地方,例如那个BOM标志,让本来已经很复杂的事情再复
杂一点.
如果有写代码的话,其实用unicode处理事情会相对轻松很多,因为用到能支持中文的
库, 都是把gb2312 gbk gb18030转成unicode.如果你的文字不单单只是简单的处理
还包括呈现出来,不用unicode就等于你要自己重新写很多东西,因为很多东西都是外
国人做出来的,这个则是更大的麻烦.不过也外国人这样做也是对了,别说人家打地基
的看到那么多种编码头疼,在上面搞高层建筑的人看到每个国家一个或者多个编码标
准,不头疼才怪(我也很头疼,本来就很复杂的编码标准里面还有人不遵守标准).
对于unicode这个标准,亚洲最好还是多参与制订,让unicode这个标准可以更合适亚
洲的发展,抵触unicode很大程度上造成的自损也是很大的,在windows里面不管是什
么编码,最后在系统的核心部分其实都是转成unicode.不过98以及之前的系统不支持
unicode.
就转码上的歧义这个也应该是转码器要处理的问题.
现在其实跟秦朝之前的情况差不多,一种编码到了另外一个国家的编码里面就不知道
说什么了,而且除非你人为的一个一个的试,写代码去辨别可能分辨出来的机率不高.
utf8对于C/C++语言来说还是比utf16好得多,没有那个NULL问题,utf8也是为了应付
这种情况产生的,你也别怪它.
其实抵制unicode对我们自己也没什么好处,虽然外国人发起unicode标准也是为了
他们自己,但如果我们抵制它,也就是要放掉很多软件代码资源.而且最后还不得不
在写一个接口转成unicode,除非我们有能力写一个只支持我们自己的编码标准的系
统,还能每个公民可以免费使用的系统.
[newblue@bEyoOo ~]$ cat 流星99
> 基本上不反对，某种意义上而言，Unicode/UTF本身就是西方强加于亚洲地区的标准，
> 实际上根本就没有考虑到亚洲地区的传统编码体系，甚至在某些字符的映射上，
> 出现了歧义的情况（举例而言，在部分日文字符上就出现了转换时的歧义，
> 引起了多对一和一对多的糟糕情况，这也是很多日本人坚决抵制UTF的原因），
> 如果亚洲地区不分青红皂白全盘接受的话，确实有可能导致很多问题.......
>
> 可惜我没有足够的影响力和时间，否则我也想发动一场抵制UTF-8的运动呢~~
--
机器重新开动，系统重新安装，建立新的思想，迎接新的局面，一切重新再来
汝不可省钱而资料不备
BeYoOo网络工作室 [[ http://www.beyooo.com/ ]]
acc
"GoldenMouse" <golden...@sina.com.cn> 写入消息新闻:ebpbij$dkq$1...@news.yaako.com...
> ...
> 现在知道了，这个“大家”只是少数人。（Make Love ?）
> ...
量子公民
GoldenMouse
火柴 写道:
GoldenMouse
火柴 写道:
> 你连 ML 是什么意思都不知道，又怎么知道是少数人？赫赫。。
缺乏幽默感，哦。我讲个笑话，活跃一下气氛：说把大象装冰箱，笼共分几步？
GoldenMouse
Lu Wei 写道:
> 举个例子，我看过的mkv影片，中文字幕流的编码基本上都是utf-8。
>
GoldenMouse
任何标准本身都只是一个建议，只有在国家的支持下才有了强制性。国家永远只能代表一部
分人的利益，支持什么样的标准要看是否符合本国的利益。事实上，从来就没有出现过国际
“标准”，只有国际“建议”，国家标准才是真正的“标准”。不遵守国际标准，别人也不能把你
怎么样；但是不遵守国家标准，你就失去了一个市场。
技术并不是制定标准的真正目的，也不是成为标准的首要障碍。说某项技术落后，在很多情
况下只不过是一个借口。而所谓“国际化”，也只是为了推行标准而说的托词。执行标准的动
力，在于这个标准带来的利益。标准，是以己之长攻人之短的最强利器。三流企业搞生产，
二流企业搞设计，一流企业搞标准。
古语云：条条大路通罗马。解决问题的办法不只一个。就字符编码来说，我们完全能以
GB18030为基础进行扩展，所有GB18030现有字符保持不变，把未包含的字符包含进来，甚至
给“外星”语言留出位置，两字节不够扩成三字节，三字节不够就扩成四字节……弄个GB18030-
16、GB18030-24、GB18030-32什么的，这谁不会啊！有一点必须指出，GB18030目前兼容主
流的中、英文系统，对现有系统的兼容性比Unicode强很多；如果统一使用GB18030，现有中
文和英文系统都无需修改，或者很少修改，从可行性上来说，GB18030也比Unicode强很多。
另外，全世界中文用户恐怕要占总人口的三分之二，即使是主要使用中文的也不会低于四分
之一，从用户人数上说也应该在标准中体现中文优先，因此GB18030在人性化上也比Unicode
强。如此说来，GB18030更应该成为国际标准。
Lu Wei 写道:
金箭
的，日本、韩国甚至把各种古代符号都弄出来了。由于工作关系，我也曾经参加过
一点相关工作，包括编码整理什么的，感觉整体上比较乱。
NewBlue 写道:
Lu Wei
> 是正版的么？
>
有正版的mkv么？空对空的标准有什么用
> Lu Wei 写道:
>> 举个例子，我看过的mkv影片，中文字幕流的编码基本上都是utf-8。
>>
--
Regards
Lu Wei
Lu Wei
> 事情不是这么简单的。
>
> 任何标准本身都只是一个建议，只有在国家的支持下才有了强制性。国家永远只能
> 代表一部 分人的利益，支持什么样的标准要看是否符合本国的利益。事实上，从
> 来就没有出现过国际 “标准”，只有国际“建议”，国家标准才是真正的“标准”。不
> 遵守国际标准，别人也不能把你 怎么样；但是不遵守国家标准，你就失去了一个
> 市场。
不是哪个政府制定的，科技和企业的推动力才是主要原因。所以不必带国家色彩，
应该加入全球的技术合作，将来才能获得更大的利益
>
> 技术并不是制定标准的真正目的，也不是成为标准的首要障碍。说某项技术落后，
> 在很多情 况下只不过是一个借口。而所谓“国际化”，也只是为了推行标准而说的
> 托词。执行标准的动 力，在于这个标准带来的利益。标准，是以己之长攻人之短
> 的最强利器。三流企业搞生产， 二流企业搞设计，一流企业搞标准。
一些中国的行业标准不过是拿iso甚至ansi现成的标准来翻译一遍，小改几个字就
套个GB×××发布了。如果中国哪方面技术特强，提个标准出来，国际上也一样会审
核接受。
说到底制定标准的动力是全球化的科技、经济交流，需要提供一个协议、接口，降
低通行门槛，是为了节省众多企业各自为政造成的冗余的研发、生产和管理费用。
某些企业在标准制定中起了主要作用是自然形成的，因为行业标准本来就是它们在
市场中长期摸索提出来的，本来就凝集了它们很多心血在内。“一流企业搞标准”，
是因为它们有这个技术实力。假如没有标准化组织的参与和协调，他们的垄断门槛
只会更强硬。所以标准化组织必须是非政府、非商业性质的。“中国”标准只要确实
先进可靠，当然可以成为国际标准。
>
> 古语云：条条大路通罗马。解决问题的办法不只一个。就字符编码来说，我们完全
> 能以 GB18030为基础进行扩展，所有GB18030现有字符保持不变，把未包含的字符
> 包含进来，甚至 给“外星”语言留出位置，两字节不够扩成三字节，三字节不够就
> 扩成四字节……弄个GB18030- 16、GB18030-24、GB18030-32什么的，这谁不会啊！
> 有一点必须指出，GB18030目前兼容主 流的中、英文系统，对现有系统的兼容性比
> Unicode强很多；如果统一使用GB18030，现有中 文和英文系统都无需修改，或者
> 很少修改，从可行性上来说，GB18030也比Unicode强很多。 另外，全世界中文用
> 户恐怕要占总人口的三分之二，即使是主要使用中文的也不会低于四分 之一，从
> 用户人数上说也应该在标准中体现中文优先，因此GB18030在人性化上也比Unicode
> 强。如此说来，GB18030更应该成为国际标准。
呢？字符编码绝不是简单的做个映射的事情，恐怕设计的时候就没有国际性的眼光
吧。GB18030的制定过程中，有各国的语言学者、编码专家的参与吗？甚至真正有
听取国内各方面专家的意见吗？一贯的“政府主导”，找一帮人黑箱操作搞了个东西
出来，然后行政命令强制推行——这就是中国政府一向的作风。这种东西能拿到国际
上去审核讨论吗？至于说从人数，几亿农民能拉进来凑数吗？
--
Regards
Lu Wei
yong
我一般只用UTF-8,原先用UNIX软件要配置一大堆语言方面的东西,现在不用了,在emacs里好像只包含一个文件就可以变成UTF-8的了.
写的文件如果别人拿走看就给他转一下编码,别管中文日文韩文希伯来文拿过来就用,一般用软件也先切换成UTF-8用,
UTF-8用起来上瘾.
--
My Personal Website:
本人驻守於
cn.comp.lang.perl
cn.comp.lang.c
cn.comp.www
cn.music
cn.music.classical
yong
UTF-8比GB18030好的地方就是可以纠错,比如丢失字符,如果用UTF-8编码就可以检查出来.如果经常在blog上复制粘贴可能会遇到这种情况.
NewBlue
头疼
[newblue@bEyoOo ~]$ cat 金箭
--
机器重新开动，系统重新安装，建立新的思想，迎接新的局面，一切重新再来
不是我不想说，只是不愿意带着借口过日子
BeYoOo网络工作室 [[ http://www.beyooo.com/ ]]
NewBlue
谢谢
[newblue@bEyoOo ~]$ cat 量子公民
> 提供IRG的网址:
> http://www.info.gov.hk/digital21/eng/structure/irg.html
> http://www.cse.cuhk.edu.hk/~irg/
--
机器重新开动，系统重新安装，建立新的思想，迎接新的局面，一切重新再来
人活着，多无聊阿，好在有新闻组，可以不用无聊至死
BeYoOo网络工作室 [[ http://www.beyooo.com/ ]]
GoldenMouse
Lu Wei 写道:
流星99
当然，对于搞考古的来说，恐怕世界上还没有哪种编码可以描述甲骨文的.......
在 Tue, 15 Aug 2006 20:20:09 +0800 时, yong <yong.pers...@gmail.com> 写了:
--
>GBK还没过时,只要国内的网民大部分还停留在聊QQ灌天涯的地步GBK就过不了时.哈哈
流星99
而Unicode倒恰恰是一帮程序员弄出来的玩意，基本上没有什么语言学家参与，Unicode的中文区，
几乎是基本上照抄GBK的，以及以前CJK专家组弄的一些东西凑合起来的.......
在 Tue, 15 Aug 2006 14:25:47 +0800 时, Lu Wei <inv...@address.invalid> 写了:
--
>你这么说应该有道理，但是为何GB18030没有像Unicode那样提出实现的具体方案来
>呢？字符编码绝不是简单的做个映射的事情，恐怕设计的时候就没有国际性的眼光
>吧。GB18030的制定过程中，有各国的语言学者、编码专家的参与吗？甚至真正有
>听取国内各方面专家的意见吗？一贯的“政府主导”，找一帮人黑箱操作搞了个东西
>出来，然后行政命令强制推行——这就是中国政府一向的作风。这种东西能拿到国际
>上去审核讨论吗？至于说从人数，几亿农民能拉进来凑数吗？
--
流星99
GB18030甚至包括了欧洲字符、俄语以及部分少数民族字符，
表达上来说，基本上是OK的，要说不方便，大概只有交流方面的问题了。
我前面说过，Unicode实际上就是一帮程序员弄出来的东西，所以，
用Unicode写代码不方便的话，那才真叫见了Ghost了，但是正如Linux一样，
一个东东单纯靠程序员来弄，是永远不可能平易近人的.......
作为一个文字编码标准，不能仅仅考虑到程序员的方便和利益，更要考虑到方方面面更多的东西
（别的不说，哪怕是个PHP+MYSQL的论坛，如果你用UTF-8的话，你就得为多出来的将近50%的MYSQL数据库容量，
多付一笔钱给虚拟主机商），所以我还是那句话，有时候，单靠民主和专业人士是不能解决问题的，
适当的来一点强制和暴力，并非就是罪恶，某种意义上讲，当年如果不是秦始皇，
或许我们就会象欧洲那样弄出几十种语言文字出来了.......
在 Mon, 14 Aug 2006 20:55:33 +0000 时, NewBlue <new...@BeYoOooooOoooo.cOm> 写了:
--
--
流星99
而且*NIX是程序员说话的地方，而非用户，Unicode本来就是程序员搞出来的东西，
自然是方便程序员的.......
就某种意义而言，GB18030实际上是个超前的标准，除了搞古语言文学的
（或者加上派出所搞户口的），几乎没人需要这个标准，而GBK就目前来说，
应该是比较实用的，而且它和GB2312完全兼容（在Windows上二者是一回事），
可以说是既满足了使用的要求，又不会增加转换和存储成本，
更不会带来三字节和四字节编码的一些特有的麻烦，而且它的非强制性，
也不会带来某些崇尚“自由”的家伙的反感.......
在 Mon, 14 Aug 2006 21:23:21 +0800 时, "winsphinX" <x...@yyy.zzz> 写了:
--
流星99
出版社、图书馆之类的地方上千TB的资料转换就够要你命的了，更何况还有存储问题
（UTF-8的存储消耗要比GB大将近50%），传输问题（因为容量增加引起的）、
打印问题（主要是打印字库的问题）等等等一系列复杂的问题，虽然这些在个人使用上或许可以忽略不计
（但也不全然如此，如果你租用虚拟主机架设论坛的话，使用UTF-8会让你化掉更多的钱在购买数据库容量、
以及网络流量上），但是对于大面积推广和普及而言，这些问题都是不得不考虑的.......
在 Mon, 14 Aug 2006 13:57:01 +0800 时, willi...@gmail.com (火柴) 写了:
>GoldenMouse <golden...@sina.com.cn> writes:
>
>> 火柴 写道:
>>> sigh...utf-8 一种编码可以显示多国语言，对用户而言这不是很方便的一件事么？
>>> 省得不管是为了中文的 gb*, 日文的 iso-2022-jp, shift_jis, ...还是其它各种
>>> 编码弄得晕头转向。
>>
>> 如果你以前从没有用过电脑，UTF确实很诱人。但是事实并非如此，我们现在不能
>> 不考虑兼容问题。
>
>别这么说，我以前都是 gb*, 现在硬盘上的东西基本上都转成了 utf-8，感觉方便
>多了。兼容性是个问题，但是不能说因为有这个问题就要绕行。如果都能慢慢转向
>utf-8, 岂不皆大欢喜？就个人用户来说，转换其实也不并不复杂，简单地用
>iconv, convmv 等转换工具就能实现。
流星99
是不是为了交流，我们就全民放弃中文，全部改用英文作为母语（果真那样的话，
全世界统统学英文、用英文，还要Unicod干嘛，只要有ASCII就够了）？
况且说句不好听的话，就算是真的象Unicode理想里的那样（实际上，
Unicode根本就无法实现当初制定Unicode时那样的目标），英国人的计算机上可以显示出中文来，
香港人的计算机上可以显示出简体来，日本人的计算机上可以显示出韩文来，
但是如果这个英国人不懂中文、香港人只认繁体字、日本人看韩文如蝌蚪，
那和显示出乱码来又有何区别？
就本质上而言，语言这东西，本来就是区域化、多样化的东西，在语言本身多样化的情况下，
非要为多样化的语言弄一个什么全球统一的编码标准出来，我看也并不一定就是好事，
更何况，Unicode根本就不是一个语言学家弄出来的东西，不过就是一帮程序员而已，
根本算不上是什么科学或者先进的东西，顶多也就是一个编程方便罢了，而为了这么一个东西，
为此增加一系列的麻烦和成本，甚至于要放弃一些国家、民族的东西作为代价，
真的有那么必要吗？
在 Mon, 14 Aug 2006 13:17:09 +0800 时, Lu Wei <inv...@address.invalid> 写了:
--
>流星99 wrote on 06-8-13 21:50:
>> 基本上不反对，某种意义上而言，Unicode/UTF本身就是西方强加于亚洲地区的标准，
>> 实际上根本就没有考虑到亚洲地区的传统编码体系，甚至在某些字符的映射上，
>> 出现了歧义的情况（举例而言，在部分日文字符上就出现了转换时的歧义，
>> 引起了多对一和一对多的糟糕情况，这也是很多日本人坚决抵制UTF的原因），
>> 如果亚洲地区不分青红皂白全盘接受的话，确实有可能导致很多问题.......
>>
>> 可惜我没有足够的影响力和时间，否则我也想发动一场抵制UTF-8的运动呢~~
>我觉得这应该通过加入标准的讨论、制定过程来解决。计算机上的各种基础标准几
>乎都是“西方”的，这是历史事实，哪能说都是“强加”过来的呢，实际上是我们必须
>“拿过来”。要是没有NNTP标准我们哪能在这发帖啊。至少现在由于技术的发展标准
>的制定也国际化了，unicode的计划里几乎包含了全球的语言，有各国的专家在里
>面，加入、推动这个协作才是更有意义的事情。GB***有这么完整的解决方案吗？
>能在技术上成为国际标准吗？
--
流星99
迫不得已加入了GB18030支持（其实你从Windows2000到Windows Vista的GB18030支持的发展，
就能看出来，微软根本就没做好GB18030的支持准备，另外，Windows9X由于内核问题，
无法支持4字节语言编码，所以WIN9X是不可能通过安装支持程序来支持GB18030的，
微软的支持程序只是For WIN2000的），但是，不得不说，微软的多语言支持，
是所有的软件当中最好的，甚至比国内那些“自主”修改的*NIX系统都要好得多
（实际上这个也是我很不喜欢*NIX的一个地方--中文支持实在是太差了）......
在 Mon, 14 Aug 2006 12:48:08 +0800 时, "batch" <chin...@hotmail.com> 写了:
--
>Windows并不是没有打算到要支持。在GB18030方案出台的时候，微软就立刻发布了GB18030 Support Pack，用于各种Windows版本支持GB18030。而Windows
>XP/2003则已经有GB18030的支持，只需要安装GB18030的字体就立刻可以用，而不像Win9x/2000那样需要安装支持程序。
>到了Windows Vista就更加彻底了，连内置的中文字体(像宋体)都是GB18030支持包的字体，各方面也是支持GB18030。
>这对我来说是好事情，因为我更加偏向用GB18030。
>
>"GoldenMouse" <golden...@sina.com.cn> 写入消息 news:ebo20e$8pp$1...@news.yaako.com...
>> UTF兼容的是英文系统，例如ASCII和8859，它与现有中文系统甚至所有主流非拉丁 系统都不兼容。所谓兼容，是说现有文档可以不必转换直接使用，也就是说所有的 “字”在两种系统中使用相同的编码。例如，某个字在GB2312中的编码是“A8A8”，这 个字在GB18030中的编码还是“A8A8”，而在UTF中
>> 的编码却成了“A8A8A8”，这时候可 以说GB18030是兼容GB2312的，但UTF是与GB2312不兼容的。兼容与“可以容纳”是两 个不同的概念，UTF对于包括中文系统在内的非拉丁系统是“可以容纳”，而不是“兼 容”。
>>
>> 如果欧美国家使用UTF，他们的系统没有任何变化，或者变化很小。而中国等亚洲 国家使用UTF则成本高昂。首先，软件系统要修改，大量的检索、统计、翻译、存 储程序以及大屏幕显示系统的驱动程序和嵌入系统等都需要升级甚至重写。然后， 原有数据必须转换，海量的资料、文档、记录等都要重新
>> 编码。更要命的是，从 GB2312转到UTF后，多数中文字从两字节变成了三字节，你的存储能力和传输能力 凭空就减少了三成，这可不是一次性的，是要跟你一辈子的。
>>
>> 有不少人拿博客说事儿，举例说改成UTF以后如何如何方便。我建议还是不要说这 种小儿科的话吧，制定国家标准，博客基本可以忽略不计的。我们个人喜欢用什么 编码其实无所谓，但是对于应用系统则必须有个标准，这个标准当然是中国国家标 准而不是外国标准，即使它冠以“国际”的名义。GB2312
>> 和GB18030是中国强制执行 的国家标准，也就是说必须要支持的，GBK是个建议标准。GB18030包含并兼容 GB2312。不支持GB18030的系统，在中国被禁止销售。虽然个人喜欢用什么编码无 所谓，但是使用符合中国国家标准的编码对我们自己相当有好处。
>>
>> 我现在使用GB18030。而Linux对GB18030的支持非常好，Windows则差些，因为微软 本来不打算支持GB18030的。
>>
>> 终极super 写道:
>>> UTF-8是不是可以支持各国的文字？那样他的编码当然就复杂了，
>>> 你能不能介绍一下UTF-8的技术细节
>>>
--
流星99
在 Mon, 14 Aug 2006 00:57:01 +0000 (UTC) 时, 東瓜 <dong...@use.net> 写了:
--
>MesNews发的UTF－8编码帖子，用XanaNews看都是乱码。
>--
>
>流星99 wrote:
>> UTF编码是个非常复杂的体系，包括UTF-7、UTF-8、UTF-16以及UTF-32，
>> 都是属于Unicode体系的变体，而Unicode体系就更加复杂了，包括了一些统一码区，
>> 以及无数个自定义码区，所以，UTF-8并不是一帖整治乱码的良药，相反，
>> 因为UTF-8造成的乱码有时候比以前的各国的各自编码更多.......
>> 举个不恰当的例子，正如现在的域名体系，已经统一定义了.COM/.NET/ORG乃至于.CN/.TW/.JP等等，
>> 但是对于其它的却没有统一，或许你在使用163.com、google.cn、yahoo.tw时都没有问题，
>> 但是如果你想使用"网易.com"或者"谷歌.cn"或者"奇摩.tw"就会问题成堆.......
流星99
在 Mon, 14 Aug 2006 04:45:40 +0800 时, GoldenMouse <golden...@sina.com.cn> 写了:
--
>无需抵制。凡是使用UTF的人，他们的影响力更小，小到可以忽略。真正有影响力
>的人，不管他喜欢不喜欢，他必定使用GB编码，因为那是国家标准，要和其他也有
>影响力的人交流，就得使用国家标准。
>
>流星99 写道:
>>
>> 可惜我没有足够的影响力和时间，否则我也想发动一场抵制UTF-8的运动呢~~
流星99
比如广东话里的“冇”就是典型的GBK字符，但是即使你用GB2312，在使用Windows编码平台的任何一款软件上，
这个汉字也都可以正常显示和输入，只有在*NIX操作系统或者为*NIX系统编写的软件上，
才有GB2312和GBK的区别（在IE和OE的编码菜单里你甚至找不到GBK的项目而只有GB2312）
在 Sun, 13 Aug 2006 21:56:28 +0800 时, "batch" <chin...@hotmail.com> 写了:
--
>如果某个程序有GB2312、GBK、GB18030供选择，我会首先把GB2312排除在外，GBK和GB18030任用。
>因为在粤语地区多数会偏向用GBK、GB18030，写入粤语文字的需要用到。
>"流星99" <bian...@bianlule.3322.org> 写入消息 news:44ef2dde...@127.0.0.1...
>> GB2312确实是过时了，但是GBK并不过时，而对于Windows NT内核而言，
>> GB2312=GBK（对于*NIX系统，我个人建议把GB2312映射为GBK，以GBK为默认），
>> 所以说GB2312/GBK过时，是不准确的（其实GB18030并不比GBK多多少字符），
>> 也基于此点，我坚持使用GB2312/GBK，估计在将来很长一段时间内可能依然如此......
>>
>> 在 Sun, 13 Aug 2006 19:37:01 +0800 时, "batch" <chin...@hotmail.com> 写了:
>> --
>>
>>>GB2312早就过时了。有很多字符GB2312根本不行，所以我要么用UTF-8，要么用GB18030。
>>>"终极super" <zhongj...@gmail.com> 写入消息 news:ebmrji$v31$1...@news.yaako.com...
>>>> 一直在琢磨这个问题，按理UTF-8兼容GB2312、BIG5、EUC-JP等多种国家的语言编码，至少台湾，香港等海外朋友都可以看到我的blog，而且不会出现乱码！但那天我在链接cnblog的最新链接的时候，发现他们提供的都是GB2312，结果出来一堆乱码，这让我很矛盾。看来国内的bloger还是太局限于GB2312编码，虽然是国家标准码，但UTF-8应该是大趋所势，看看对岸的台湾兄弟大都采用了UTF-8，觉得就比较国际话。
>>>>
>>>> 想想又不想放弃对GB2312的支持，又不想太局限与GB2312，真是郁闷呀：（
>>>>
>>>> 大家说呢？
--
batch
batch
"流星99" <bian...@bianlule.3322.org> 写入消息 news:44f0da49...@127.0.0.1...
batch
我现在的OE默认用GB18030，而不是GB2312。
有时候我实在受不了GB2312(如果是GBK当作GB2312的情况就例外)。
"流星99" <bian...@bianlule.3322.org> 写入消息 news:44f8da58...@127.0.0.1...
yong
这些都不是UTF-8,一般是UTF-7和UTF-16
流星99 <bian...@bianlule.3322.org> writes:
> 在微软新闻组，很多UTF-8的帖子哪怕用OE看也都是乱码.......
>
> 在 Mon, 14 Aug 2006 00:57:01 +0000 (UTC) 时, �|瓜 <dong...@use.net> 写了:
> --
>
>>MesNews发的UTF－8编码帖子，用XanaNews看都是乱码。
>>--
>>
>>流星99 wrote:
>>> UTF编码是个非常复杂的体系，包括UTF-7、UTF-8、UTF-16以及UTF-32，
>>> 都是属于Unicode体系的变体，而Unicode体系就更加复杂了，包括了一些统一码区，
>>> 以及无数个自定义码区，所以，UTF-8并不是一帖整治乱码的良药，相反，
>>> 因为UTF-8造成的乱码有时候比以前的各国的各自编码更多.......
>>> 举个不恰当的例子，正如现在的域名体系，已经统一定义了.COM/.NET/ORG乃至于.CN/.TW/.JP等等，
>>> 但是对于其它的却没有统一，或许你在使用163.com、google.cn、yahoo.tw时都没有问题，
>>> 但是如果你想使用"网易.com"或者"谷歌.cn"或者"奇摩.tw"就会问题成堆.......
>
> --
> 我是流星，虽然一闪而过，
> 也希望能留下美丽的光芒。
> 欢迎光临 news://news.cn99.com/cn.fan
> 中国fans的新闻组，中国fans的家......
--
batch
yong
GB18030也是变长的
单字节，其值从0到0x7F。
双字节，第一个字节的值从0x81到0xFE，第二个字节的值从0x40到0xFE（不包括0x7F）。
四字节，第一个字节的值从0x81到0xFE，第二个字节的值从0x30到0x39，第三个字节的值从0x81到0xFE，第四个字节的值从0x30到0x39。
流星99 <bian...@bianlule.3322.org> writes:
> 作为一个文字编码标准，不能仅仅考虑到程序员的方便和利益，更要考虑到方方面面更多的东西
> （别的不说，哪怕是个PHP+MYSQL的论坛，如果你用UTF-8的话，你就得为多出来的将近50%的MYSQL数据库容量，
> 多付一笔钱给虚拟主机商），所以我还是那句话，有时候，单靠民主和专业人士是不能解决问题的，
> 适当的来一点强制和暴力，并非就是罪恶，某种意义上讲，当年如果不是秦始皇，
> 或许我们就会象欧洲那样弄出几十种语言文字出来了.......
>
beckyer
你是否知道google和其它搜索引擎用的是什么编码？
beckyer
utf-8是国际标准，gb18030是国家标准，难道你要做井底之蛙不成？？
GoldenMouse wrote:
> 事情不是这么简单的。
>
> 任何标准本身都只是一个建议，只有在国家的支持下才有了强制性。国家永远只能代表一部
> 分人的利益，支持什么样的标准要看是否符合本国的利益。事实上，从来就没有出现过国际
> "标准"，只有国际"建议"，国家标准才是真正的"标准"。不遵守国际标准，别人也不能把你
> 怎么样；但是不遵守国家标准，你就失去了一个市场。
>
> 技术并不是制定标准的真正目的，也不是成为标准的首要障碍。说某项技术落后，在很多情
> 况下只不过是一个借口。而所谓"国际化"，也只是为了推行标准而说的托词。执行标准的动
> 力，在于这个标准带来的利益。标准，是以己之长攻人之短的最强利器。三流企业搞生产，
> 二流企业搞设计，一流企业搞标准。
>
> 古语云：条条大路通罗马。解决问题的办法不只一个。就字符编码来说，我们完全能以
> GB18030为基础进行扩展，所有GB18030现有字符保持不变，把未包含的字符包含进来，甚至
> 给"外星"语言留出位置，两字节不够扩成三字节，三字节不够就扩成四字节......弄个GB18030-
beckyer
> 国际的不一定就是好的，说句不客气的话，英文现在全世界最通用，
> 是不是为了交流，我们就全民放弃中文，全部改用英文作为母语（果真那样的话，
> 全世界统统学英文、用英文，还要Unicod干嘛，只要有ASCII就够了）？
各国文字有个国际编码标准是必须的，否则你现在用google搜索能如此之爽？
> 况且说句不好听的话，就算是真的象Unicode理想里的那样（实际上，
> Unicode根本就无法实现当初制定Unicode时那样的目标），英国人的计算机上可以显示出中文来，
> 香港人的计算机上可以显示出简体来，日本人的计算机上可以显示出韩文来，
> 但是如果这个英国人不懂中文、香港人只认繁体字、日本人看韩文如蝌蚪，
> 那和显示出乱码来又有何区别？
能否正确显示各国文字跟能否读懂是两回事。unicode做到的是前者，不是后者。
> 就本质上而言，语言这东西，本来就是区域化、多样化的东西，在语言本身多样化的情况下，
> 非要为多样化的语言弄一个什么全球统一的编码标准出来，我看也并不一定就是好事，
> 更何况，Unicode根本就不是一个语言学家弄出来的东西，不过就是一帮程序员而已，
> 根本算不上是什么科学或者先进的东西，顶多也就是一个编程方便罢了，而为了这么一个东西，
> 为此增加一系列的麻烦和成本，甚至于要放弃一些国家、民族的东西作为代价，
> 真的有那么必要吗？
讲到文字编码，不能扯到国家、民族、爱国之类的东西上去。没有unicode，google能发展起来？
beckyer
他不知道gb18030的多数四字节编码汉字，如果用utf8的话，只需三个字节即可。
utf8的容错性比gb18030要好的多。
beckyer
四不象
google是为了兼容其他语言才使用utf-8的
如果是纯中文搜索引擎，最好还是用gb2312
----
为了防止世界被破坏,为了维护世界的和平,坚持爱和真实的罪恶,最有魅力的IT人士,跨
过银河的代码工人,白色的未来有光明的明天在等待,我们只是为中国社会主义建设事业
做出自己微不足道的一点贡献。
> 你是否知道google和其它搜索引擎用的是什么编码？
> GoldenMouse wrote: > 无需抵制。凡是使用UTF的人，他们的影响力更小，小到可以
忽略。真正有影响力
??>> 的人，不管他喜欢不喜欢，他必定使用GB编码，因为那是国家标准，要和其他也
有
??>> 影响力的人交流，就得使用国家标准。
??>>
??>> 流星99 写道:
??>>>
??>>> 可惜我没有足够的影响力和时间，否则我也想发动一场抵制UTF-8的运动呢~~
??>>>
beckyer
什么叫"纯中文搜索引擎"？既然是搜索，谁愿意用那个"纯中文搜索引擎"？
四不象 wrote:
> baidu使用gb2312编码的
> google是为了兼容其他语言才使用utf-8的
> 如果是纯中文搜索引擎，最好还是用gb2312
>
beckyer
流星99 wrote:
> 这个倒也不是，实际上GBK就已经包含了中日韩三国文字了，
> GB18030甚至包括了欧洲字符、俄语以及部分少数民族字符，
> 表达上来说，基本上是OK的，要说不方便，大概只有交流方面的问题了。
gb18030有100多万个码位，包括了unicode的所有字符。可是有哪个OS支持显示gb18030编码的汉字吗？答案是NO。
>
> 我前面说过，Unicode实际上就是一帮程序员弄出来的东西，所以，
> 用Unicode写代码不方便的话，那才真叫见了Ghost了，但是正如Linux一样，
> 一个东东单纯靠程序员来弄，是永远不可能平易近人的.......
>
> 作为一个文字编码标准，不能仅仅考虑到程序员的方便和利益，更要考虑到方方面面更多的东西
> （别的不说，哪怕是个PHP+MYSQL的论坛，如果你用UTF-8的话，你就得为多出来的将近50%的MYSQL数据库容量，
> 多付一笔钱给虚拟主机商），所以我还是那句话，有时候，单靠民主和专业人士是不能解决问题的，
> 适当的来一点强制和暴力，并非就是罪恶，某种意义上讲，当年如果不是秦始皇，
> 或许我们就会象欧洲那样弄出几十种语言文字出来了.......
你只是考虑到多占用了一些码位，为什么没有考虑到utf8使得汉字和其它文字并存，比如德文、法文等等。gbk能够做到这点吗？
beckyer
流星99 wrote:
> 在微软新闻组，很多UTF-8的帖子哪怕用OE看也都是乱码.......
beckyer
big5？兼容hkscs？兼容ksc？兼容sjis？兼容法文？兼容德文？兼容西班牙文？
beckyer
说utf8是技术歧视，是不是自己心中没底自信心不足导致的幻觉？
GoldenMouse wrote:
> UTF-8是与GB2312不兼容的，UTF-8本身就是偏向欧美的设计。如果大家都用UTF-
> 8，欧美国家的人们可以用底成本达到编码统一，但是象中国等非英语国家则面临
> 巨大的转换成本和将来的运行成本。说UTF-8是技术歧视似乎并不算过。
>
> 终极super 写道:
beckyer
流星99 wrote:
> 因为UTF-8造成的乱码有时候比以前的各国的各自编码更多.......
beckyer
unicode是面对世界各国文字的，必然无法考虑到亚洲地区的传统编码体系。
所谓多对1或者1对多的问题，是unicode本身制定不够完美的问题，不是unicode是否应该存在的根据。
beckyer
如果我是法国人，我要用汉字和法文，你不建议我用utf8，建议我用gbk？gbk编码的汉字和拉丁文能并存吗？
流星99 wrote:
> UTF-8以及Unicode在处理大陆、台湾两岸字符上确实有一定优势，所以在博客上使用的比较多一些，
> 但是并不意味着UTF-8/UNICODE就是整治乱码的万能良方，在某些场合，UTF-8/Unicode甚至可能引起新的乱码，
> 因此，假如你的访问者不仅仅是华人的话，不建议你用UTF-8，而在博客以外的场合（比如邮件、网站网页、
> 新闻组帖子等等等），也不建议使用UTF-8.......
>
beckyer
金箭
用的Oracle是支持的，嘿嘿。
beckyer 写道:
金箭
流星99 写道:
> 即使是做学问、搞研究，GBK也不会过时的，除非是搞古代文学的，
> 当然，对于搞考古的来说，恐怕世界上还没有哪种编码可以描述甲骨文的.......
>
> 在 Tue, 15 Aug 2006 20:20:09 +0800 时, yong <yong.pers...@gmail.com> 写了:
> --
>
>> GBK还没过时,只要国内的网民大部分还停留在聊QQ灌天涯的地步GBK就过不了时.哈哈
>>
>> 流星99 <bian...@bianlule.3322.org> writes:
>>
>>> GB2312确实是过时了，但是GBK并不过时，而对于Windows NT内核而言，
>>> GB2312=GBK（对于*NIX系统，我个人建议把GB2312映射为GBK，以GBK为默认），
>>> 所以说GB2312/GBK过时，是不准确的（其实GB18030并不比GBK多多少字符），
>>> 也基于此点，我坚持使用GB2312/GBK，估计在将来很长一段时间内可能依然如此......
>>>
>>> 在 Sun, 13 Aug 2006 19:37:01 +0800 时, "batch" <chin...@hotmail.com> 写了:
>>> --
>>>
>>>> GB2312早就过时了。有很多字符GB2312根本不行，所以我要么用UTF-8，要么用GB18030。
>>>> "终极super" <zhongj...@gmail.com> 写入消息 news:ebmrji$v31$1...@news.yaako.com...
>>>>> 一直在琢磨这个问题，按理UTF-8兼容GB2312、BIG5、EUC-JP等多种国家的语言编码，至少台湾，香港等海外朋友都可以看到我的blog，而且不会出现乱码！但那天我在链接cnblog的最新链接的时候，发现他们提供的都是GB2312，结果出来一堆乱码，这让我很矛盾。看来国内的bloger还是太局限于GB2312编码，虽然是国家标准码，但UTF-8应该是大趋所势，看看对岸的台湾兄弟大都采用了UTF-8，觉得就比较国际话。
>>>>>
>>>>> 想想又不想放弃对GB2312的支持，又不想太局限与GB2312，真是郁闷呀：（
>>>>>
>>>>> 大家说呢？
>
beckyer
GoldenMouse wrote:
> UTF兼容的是英文系统，例如ASCII和8859，它与现有中文系统甚至所有主流非拉丁
> 系统都不兼容。所谓兼容，是说现有文档可以不必转换直接使用，也就是说所有的
> "字"在两种系统中使用相同的编码。例如，某个字在GB2312中的编码是"A8A8"，这
> 以说GB18030是兼容GB2312的，但UTF是与GB2312不兼容的。兼容与"可以容纳"是两
> 个不同的概念，UTF对于包括中文系统在内的非拉丁系统是"可以容纳"，而不是"兼
你的意思是说，utf8跟拉丁语系是兼容的了？以前的法文、德文都是单字节编码，现在utf8里编程了双字节，兼容吗？
> 如果欧美国家使用UTF，他们的系统没有任何变化，或者变化很小。而中国等亚洲
> 国家使用UTF则成本高昂。首先，软件系统要修改，大量的检索、统计、翻译、存
> 储程序以及大屏幕显示系统的驱动程序和嵌入系统等都需要升级甚至重写。然后，
> 原有数据必须转换，海量的资料、文档、记录等都要重新编码。更要命的是，从
> GB2312转到UTF后，多数中文字从两字节变成了三字节，你的存储能力和传输能力
> 凭空就减少了三成，这可不是一次性的，是要跟你一辈子的。
拉丁文四通utf8编码，存储能力和传输能力增加了一倍，人家毫无怨言。汉字只是增加了三成，你就叫了？你大概还不知道有些汉字，gb18030要4字节，utf8只要3字节，谁的存储量更大？
金箭
> gb18030有100多万个码位，包括了unicode的所有字符。可是有哪个OS支持显示gb18030编码的汉字吗？答案是NO。
什么意思？不明白。
> 你只是考虑到多占用了一些码位，为什么没有考虑到utf8使得汉字和其它文字并存，比如德文、法文等等。gbk能够做到这点吗？
关键既不是码位，也不是并存，而是实现这些特点各自付出的代价是否值当。
金箭
beckyer 写道:
金箭
beckyer 写道: