00000002.htm

一份很好的linux入门资料

数的字节都是这样的(Bigendian&nbsp;convention).&nbsp;将一个&nbsp;ASCII&nbsp;或&nbsp;Latin-1&nbsp;的文件转换&nbsp;<BR>
成&nbsp;UCS-2&nbsp;只需简单地在每个&nbsp;ASCII&nbsp;字节前插入&nbsp;0x00.&nbsp;如果要转换成&nbsp;UCS-4,&nbsp;则必须在&nbsp;<BR>
每个&nbsp;ASCII&nbsp;字节前插入三个&nbsp;0x00.&nbsp;<BR>
在&nbsp;Unix&nbsp;下使用&nbsp;UCS-2&nbsp;(或&nbsp;UCS-4)&nbsp;会导致非常严重的问题.&nbsp;用这些编码的字符串会包&nbsp;<BR>
含一些特殊的字符,&nbsp;比如&nbsp;'\0'&nbsp;或&nbsp;'/',&nbsp;它们在&nbsp;文件名和其他&nbsp;C&nbsp;库函数参数里都有特&nbsp;<BR>
别的含义.&nbsp;另外,&nbsp;大多数使用&nbsp;ASCII&nbsp;文件的&nbsp;UNIX&nbsp;下的工具,&nbsp;如果不进行重大修改是无&nbsp;<BR>
法读取&nbsp;16&nbsp;位的字符的.&nbsp;基于这些原因,&nbsp;在文件名,&nbsp;文本文件,&nbsp;环境变量等地方,&nbsp;UCS-&nbsp;<BR>
2&nbsp;不适合作为&nbsp;Unicode&nbsp;的外部编码.&nbsp;<BR>
在&nbsp;ISO&nbsp;10646-1&nbsp;Annex&nbsp;R&nbsp;和&nbsp;RFC&nbsp;2279&nbsp;里定义的&nbsp;UTF-8&nbsp;编码没有这些问题.&nbsp;它是在&nbsp;U&nbsp;<BR>
nix&nbsp;风格的操作系统下使用&nbsp;Unicode&nbsp;的明显的方法.&nbsp;<BR>
UTF-8&nbsp;有一下特性:&nbsp;<BR>
UCS&nbsp;字符&nbsp;U+0000&nbsp;到&nbsp;U+007F&nbsp;(ASCII)&nbsp;被编码为字节&nbsp;0x00&nbsp;到&nbsp;0x7F&nbsp;(ASCII&nbsp;兼容).&nbsp;这&nbsp;<BR>
意味着只包含&nbsp;7&nbsp;位&nbsp;ASCII&nbsp;字符的文件在&nbsp;ASCII&nbsp;和&nbsp;UTF-8&nbsp;两种编码方式下是一样的.&nbsp;<BR>
所有&nbsp;&gt;U+007F&nbsp;的&nbsp;UCS&nbsp;字符被编码为一个多个字节的串,&nbsp;每个字节都有标记位集.&nbsp;因此&nbsp;<BR>
,&nbsp;ASCII&nbsp;字节&nbsp;(0x00-0x7F)&nbsp;不可能作为任何其他字符的一部分.&nbsp;<BR>
表示非&nbsp;ASCII&nbsp;字符的多字节串的第一个字节总是在&nbsp;0xC0&nbsp;到&nbsp;0xFD&nbsp;的范围里,&nbsp;并指出这&nbsp;<BR>
个字符包含多少个字节.&nbsp;多字节串的其余字节都在&nbsp;0x80&nbsp;到&nbsp;0xBF&nbsp;范围里.&nbsp;这使得重新&nbsp;<BR>
同步非常容易,&nbsp;并使编码无国界,&nbsp;且很少受丢失字节的影响.&nbsp;<BR>
可以编入所有可能的&nbsp;231个&nbsp;UCS&nbsp;代码&nbsp;<BR>
UTF-8&nbsp;编码字符理论上可以最多到&nbsp;6&nbsp;个字节长,&nbsp;然而&nbsp;16&nbsp;位&nbsp;BMP&nbsp;字符最多只用到&nbsp;3&nbsp;字&nbsp;<BR>
节长.&nbsp;<BR>
Bigendian&nbsp;UCS-4&nbsp;字节串的排列顺序是预定的.&nbsp;<BR>
字节&nbsp;0xFE&nbsp;和&nbsp;0xFF&nbsp;在&nbsp;UTF-8&nbsp;编码中从未用到.&nbsp;<BR>
下列字节串用来表示一个字符.&nbsp;用到哪个串取决于该字符在&nbsp;Unicode&nbsp;中的序号.&nbsp;<BR>
U-00000000&nbsp;-&nbsp;U-0000007F:&nbsp;&nbsp;0xxxxxxx&nbsp;<BR>
U-00000080&nbsp;-&nbsp;U-000007FF:&nbsp;&nbsp;110xxxxx&nbsp;10xxxxxx&nbsp;<BR>
U-00000800&nbsp;-&nbsp;U-0000FFFF:&nbsp;&nbsp;1110xxxx&nbsp;10xxxxxx&nbsp;10xxxxxx&nbsp;<BR>
U-00010000&nbsp;-&nbsp;U-001FFFFF:&nbsp;&nbsp;11110xxx&nbsp;10xxxxxx&nbsp;10xxxxxx&nbsp;10xxxxxx&nbsp;<BR>
U-00200000&nbsp;-&nbsp;U-03FFFFFF:&nbsp;&nbsp;111110xx&nbsp;10xxxxxx&nbsp;10xxxxxx&nbsp;10xxxxxx&nbsp;10xxxxxx&nbsp;<BR>
U-04000000&nbsp;-&nbsp;U-7FFFFFFF:&nbsp;&nbsp;1111110x&nbsp;10xxxxxx&nbsp;10xxxxxx&nbsp;10xxxxxx&nbsp;10xxxxxx&nbsp;10xxx&nbsp;<BR>
xxx&nbsp;<BR>
xxx&nbsp;的位置由字符编码数的二进制表示的位填入.&nbsp;越靠右的&nbsp;x&nbsp;具有越少的特殊意义.&nbsp;只&nbsp;<BR>
用最短的那个足够表达一个字符编码数的多字节串.&nbsp;注意在多字节串中,&nbsp;第一个字节的&nbsp;<BR>
开头&quot;1&quot;的数目就是整个串中字节的数目.&nbsp;<BR>
例如:&nbsp;Unicode&nbsp;字符&nbsp;U+00A9&nbsp;=&nbsp;1010&nbsp;1001&nbsp;(版权符号)&nbsp;在&nbsp;UTF-8&nbsp;里的编码为:&nbsp;<BR>
11000010&nbsp;10101001&nbsp;=&nbsp;0xC2&nbsp;0xA9&nbsp;<BR>
而字符&nbsp;U+2260&nbsp;=&nbsp;0010&nbsp;0010&nbsp;0110&nbsp;0000&nbsp;(不等于)&nbsp;编码为:&nbsp;<BR>
11100010&nbsp;10001001&nbsp;10100000&nbsp;=&nbsp;0xE2&nbsp;0x89&nbsp;0xA0&nbsp;<BR>
这种编码的官方名字拼写为&nbsp;UTF-8,&nbsp;其中&nbsp;UTF&nbsp;代表&nbsp;UCS&nbsp;Transformation&nbsp;Format.&nbsp;请勿&nbsp;<BR>
在任何文档中用其他名字&nbsp;(比如&nbsp;utf8&nbsp;或&nbsp;UTF_8)&nbsp;来表示&nbsp;UTF-8,&nbsp;当然除非你指的是一&nbsp;<BR>
个变量名而不是这种编码本身.&nbsp;<BR>
&nbsp;<BR>
什么编程语言支持&nbsp;Unicode?&nbsp;<BR>
在大约&nbsp;1993&nbsp;年之后开发的大多数现代编程语言都有一个特别的数据类型,&nbsp;叫做&nbsp;Unico&nbsp;<BR>
de/ISO&nbsp;10646-1&nbsp;字符.&nbsp;在&nbsp;Ada95&nbsp;中叫&nbsp;Wide_Character,&nbsp;在&nbsp;Java&nbsp;中叫&nbsp;char.&nbsp;<BR>
ISO&nbsp;C&nbsp;也详细说明了处理多字节编码和宽字符&nbsp;(wide&nbsp;characters)&nbsp;的机制,&nbsp;1994&nbsp;年&nbsp;9&nbsp;<BR>
&nbsp;月&nbsp;Amendment&nbsp;1&nbsp;to&nbsp;ISO&nbsp;C&nbsp;发表时又加入了更多.&nbsp;这些机制主要是为各类东亚编码而设&nbsp;<BR>
计的,&nbsp;它们比处理&nbsp;UCS&nbsp;所需的要健壮得多.&nbsp;UTF-8&nbsp;是&nbsp;ISO&nbsp;C&nbsp;标准调用多字节字符串的&nbsp;<BR>
编码的一个例子,&nbsp;wchar_t&nbsp;类型可以用来存放&nbsp;Unicode&nbsp;字符.&nbsp;<BR>
在&nbsp;Linux&nbsp;下该如何使用&nbsp;Unicode?&nbsp;<BR>
在&nbsp;UTF-8&nbsp;之前,&nbsp;不同地区的&nbsp;Linux&nbsp;用户使用各种各样的&nbsp;ASCII&nbsp;扩展.&nbsp;最普遍的欧洲编&nbsp;<BR>
码是&nbsp;ISO&nbsp;8859-1&nbsp;和&nbsp;ISO&nbsp;8859-2,&nbsp;希腊编码&nbsp;ISO&nbsp;8859-7,&nbsp;俄国编码&nbsp;KOI-8,&nbsp;日本编码&nbsp;<BR>
&nbsp;EUC&nbsp;和&nbsp;Shift-JIS,&nbsp;等等.&nbsp;这使得&nbsp;文件的交换非常困难,&nbsp;且应用软件必须特别关心这&nbsp;<BR>
些编码的不同之处.&nbsp;<BR>
最终,&nbsp;Unicode&nbsp;将取代所有这些编码,&nbsp;主要通过&nbsp;UTF-8&nbsp;的形式.&nbsp;UTF-8&nbsp;将应用在&nbsp;<BR>
文本文件&nbsp;(源代码,&nbsp;HTML&nbsp;文件,&nbsp;email&nbsp;消息,&nbsp;等等)&nbsp;<BR>
文件名&nbsp;<BR>
标准输入与标准输出,&nbsp;管道&nbsp;<BR>
环境变量&nbsp;<BR>
剪切与粘贴选择缓冲区&nbsp;<BR>
telnet,&nbsp;modem&nbsp;和到终端模拟器的串口连接&nbsp;<BR>
以及其他地方以前用ASCII来表示的字节串&nbsp;<BR>
在&nbsp;UTF-8&nbsp;模式下,&nbsp;终端模拟器,&nbsp;比如&nbsp;xterm&nbsp;或&nbsp;Linux&nbsp;console&nbsp;driver,&nbsp;将每次按键转&nbsp;<BR>
换成相应的&nbsp;UTF-8&nbsp;串,&nbsp;然后发送到前台进程的&nbsp;stdin&nbsp;里.&nbsp;类似的,&nbsp;任何进程在&nbsp;stdou&nbsp;<BR>
t&nbsp;上的输出都将发送到终端模拟器,&nbsp;在那里用一个&nbsp;UTF-8&nbsp;解码器进行处理,&nbsp;之后再用一&nbsp;<BR>
种&nbsp;16&nbsp;位的字体显示出来.&nbsp;<BR>
只有在功能完善的多语言字处理器包里才可能有完全的&nbsp;Unicode&nbsp;功能支持.&nbsp;而广泛用在&nbsp;<BR>
&nbsp;Linux&nbsp;里用于取代&nbsp;ASCII&nbsp;和其他&nbsp;8&nbsp;位字符集的方案则要简单得多.&nbsp;第一步,&nbsp;Linux&nbsp;终&nbsp;<BR>
端模拟器和命令行工具将只是转变到&nbsp;UTF-8.&nbsp;这意味着只用到&nbsp;级别1&nbsp;的&nbsp;ISO&nbsp;10646-1&nbsp;&nbsp;<BR>
实现&nbsp;(没有组合字符),&nbsp;且只支持那些不需要更多处理的语言象&nbsp;拉丁,&nbsp;希腊,&nbsp;斯拉夫&nbsp;和&nbsp;<BR>
许多科学用符号.&nbsp;在这个级别上,&nbsp;UCS&nbsp;支持与&nbsp;ISO&nbsp;8859&nbsp;支持类似,&nbsp;唯一显著的区别是&nbsp;<BR>
现在我们有几千种字符可以用了,&nbsp;其中的字符可以用多字节串来表示.&nbsp;<BR>
总有一天&nbsp;Linux&nbsp;会当然地支持组合字符,&nbsp;但即便如此,&nbsp;对于组合字符串,&nbsp;预作字符(如&nbsp;<BR>
何可用的话)仍将是首选的.&nbsp;更正式地,&nbsp;在&nbsp;Linux&nbsp;下用&nbsp;Unicode&nbsp;对文本编码的首选的方&nbsp;<BR>
法应该是定义在&nbsp;Unicode&nbsp;Technical&nbsp;Report&nbsp;#15&nbsp;里的&nbsp;Normalization&nbsp;Form&nbsp;C.&nbsp;<BR>
在今后的一个阶段,&nbsp;人们可以考虑增加在日文和中文里用到的双字节字符的支持&nbsp;(他们&nbsp;<BR>
相对比较简单),&nbsp;组合字符支持,&nbsp;甚至也许对从右至左书写的语言如希伯来文&nbsp;(他们可不&nbsp;<BR>
是那么简单的)&nbsp;的支持.&nbsp;但对这些高级功能的支持不应该阻碍简单的平板&nbsp;UTF-8&nbsp;在&nbsp;拉&nbsp;<BR>
丁,&nbsp;希腊,&nbsp;斯拉夫和科学用符号方面的快速应用,&nbsp;以取代大量的欧洲&nbsp;8&nbsp;位编码,&nbsp;并提供&nbsp;<BR>
一个象样的科学用符号集.&nbsp;<BR>
&nbsp;<BR>
我该怎样修改我的软件?&nbsp;<BR>
有两种途径可以支持&nbsp;UTF-8,&nbsp;我称之为软转换与硬转换.&nbsp;软转换时,&nbsp;各处的数据均保存&nbsp;<BR>
为&nbsp;UTF-8&nbsp;形式,&nbsp;因而需要修改的软件很少.&nbsp;在硬转换时,&nbsp;程序将读入的&nbsp;UTF-8&nbsp;数据转&nbsp;<BR>
换成宽字符数组,&nbsp;以在应用程序内部处理.&nbsp;在输出时,&nbsp;再把字符串转换回&nbsp;UTF-8&nbsp;形式.&nbsp;<BR>
&nbsp;<BR>
大多数应用程序只用软转换就可以工作得很好了.&nbsp;这使得将&nbsp;UTF-8&nbsp;引入&nbsp;Unix&nbsp;成为切实&nbsp;<BR>
可行的.&nbsp;例如,&nbsp;象&nbsp;cat&nbsp;和&nbsp;echo&nbsp;这样的程序根本不需要修改.&nbsp;他们仍然可以对输入输出&nbsp;<BR>
的是&nbsp;ISO&nbsp;8859-2&nbsp;还是&nbsp;UTF-8&nbsp;一无所知,&nbsp;因为它们只是搬运字节流而没有处理它们.&nbsp;它&nbsp;<BR>
们只能识别&nbsp;ASCII&nbsp;字符和象&nbsp;'\n'&nbsp;这样的控制码,&nbsp;而这在&nbsp;UTF-8&nbsp;下也没有任何改变.&nbsp;&nbsp;<BR>
因此,&nbsp;这些应用程序的&nbsp;UTF-8&nbsp;编码与解码将完全在终端模拟器里完成.&nbsp;<BR>
而那些通过数字节数来获知字符数量的程序则需要一些小修改.&nbsp;在&nbsp;UTF-8&nbsp;模式下,&nbsp;它们&nbsp;<BR>
必须不数入&nbsp;0x80&nbsp;到&nbsp;0xBF&nbsp;范围内的字节,&nbsp;因为这些只是跟随字节,&nbsp;它们本身并不是字&nbsp;<BR>
符.&nbsp;例如,&nbsp;ls&nbsp;程序就必须要修改,&nbsp;因为它通过数文件名中字符数来排放给用户的目录表&nbsp;<BR>
格布局.&nbsp;类似地,&nbsp;所有的假定其输出为定宽字体,&nbsp;并因此而格式化它们的程序,&nbsp;必须学&nbsp;<BR>
会怎样数&nbsp;UTF-8&nbsp;文本中的字符数.&nbsp;编辑器的功能,&nbsp;如删除单个字符,&nbsp;必须要作轻微的修&nbsp;<BR>
改,&nbsp;以删除可能属于该字符的所有字节.&nbsp;受影响有编辑器&nbsp;(vi,emacs,&nbsp;等等)以及使用&nbsp;&nbsp;<BR>
ncurses&nbsp;库的程序.&nbsp;<BR>
Linux&nbsp;核心使用软转换也可以工作得很好,&nbsp;只需要非常微小的修改以支持&nbsp;UTF-8.&nbsp;大多&nbsp;<BR>
数处理字符串的核心功能&nbsp;(例如:&nbsp;文件名,&nbsp;环境变量,&nbsp;等等)&nbsp;都不受影响.&nbsp;下列地方也&nbsp;<BR>
许必须修改:&nbsp;<BR>
控制台显示与键盘驱动程序&nbsp;(另一个&nbsp;VT100&nbsp;模拟器)&nbsp;必须能编码和解码&nbsp;UTF-8,&nbsp;必须要&nbsp;<BR>
起码支持&nbsp;Unicode&nbsp;字符集的几个子集.&nbsp;从&nbsp;Linux&nbsp;1.2&nbsp;起这些功能已经有了.&nbsp;<BR>
外部文件系统驱动程序,&nbsp;例如&nbsp;VFAT&nbsp;和&nbsp;WinNT&nbsp;必须转换文件名字符编码.&nbsp;UTF-8&nbsp;已经加&nbsp;<BR>
入可用的转换选项的列表里了,&nbsp;因此&nbsp;mount&nbsp;命令必须告诉核心驱动程序用户进程希望看&nbsp;<BR>
到&nbsp;UTF-8&nbsp;文件名.&nbsp;既然&nbsp;VFAT&nbsp;和&nbsp;WinNT&nbsp;无论如何至少已经用了&nbsp;Unicode了,&nbsp;那么&nbsp;UTF&nbsp;<BR>
-8&nbsp;在这里就可以发挥其优势,&nbsp;以保证转换中无信息损失.&nbsp;<BR>
POSIX&nbsp;系统的&nbsp;tty&nbsp;驱动程序支持一种&nbsp;&quot;cooked&quot;&nbsp;模式,&nbsp;有一些原始的行编辑功能.&nbsp;为了&nbsp;<BR>
让字符删除功能工作正常,&nbsp;stty&nbsp;必须在&nbsp;tty&nbsp;驱动程序里设置&nbsp;UTF-8&nbsp;模式,&nbsp;因此它就不&nbsp;<BR>
会把&nbsp;0x80&nbsp;到&nbsp;0xBF&nbsp;范围内的跟随字符也数进去了.&nbsp;Bruno&nbsp;Haible&nbsp;那里已经有了一些&nbsp;&nbsp;<BR>
stty&nbsp;和核心&nbsp;tty&nbsp;驱动&nbsp;程序的&nbsp;Linux&nbsp;补丁&nbsp;了.&nbsp;<BR>
C&nbsp;对&nbsp;Unicode&nbsp;和&nbsp;UTF-8&nbsp;的支持&nbsp;<BR>
从&nbsp;GNU&nbsp;glibc&nbsp;2.1&nbsp;开始,&nbsp;wchar_t&nbsp;类型已经正式定为只存放独立于当前&nbsp;locale&nbsp;的,&nbsp;3&nbsp;<BR>
2位的&nbsp;ISO&nbsp;10646&nbsp;值.&nbsp;glibc&nbsp;2.2&nbsp;开始将完全支持&nbsp;ISO&nbsp;C&nbsp;中的多字节转换函数&nbsp;(wprin&nbsp;<BR>
tf(),mbstowcs(),等等),&nbsp;这些函数可以用于在&nbsp;wchar_t&nbsp;和包括&nbsp;UTF-8&nbsp;在内的任何依赖&nbsp;<BR>
于&nbsp;locale&nbsp;的多字节编码间进行转换.&nbsp;<BR>
例如,&nbsp;你可以写&nbsp;<BR>
&nbsp;&nbsp;wprintf(L&quot;Sch鰊e&nbsp;Gr