这一篇文章主要是翻译书中提到的国际化的一篇文章,并让大家了解软件开发中字符编码的众多问题,被翻译的文章写得比较早,可能从技术的角度来看不是很有意义的,作者在文中是概括主流的字符编码,并不能让大家深入的了解每一种编码的特性,但他本身也是做国际化的软件,所以他告诉大家软件国际化中各字符编码的使用会有怎样的特点和注意的问题.其实总的就是注意在你的HTML中加<meta http-equiv="Content-Type" content="text/html; charset=utf-8">这是最基本的.

.还有就是愿文中有很非技术的地方话，我不知道暗示的是什么！
请多指正.我天天都在网上可以随时改正

地址http://www.joelonsoftware.com/articles/Unicode.html

---

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
绝对最小的每一个软件开发者完全地,肯定地必须知道的Unicode和字符集)
By Joel Spolsky
Wednesday, October 08, 2003

也许对我的内容标签感到惊奇?你知道,在这篇文章中期望你能进入HTML中并里面一定会有从未完全了解的部分,是什么拉?
(I've been dismayed to discover just how many software developers aren't really completely up to speed on the mysterious world of character sets, encodings, Unicode, all that stuff. A couple of years ago, a beta tester for FogBUGZ was wondering whether it could handle incoming email in Japanese. Japanese? They have email in Japanese? I had no idea. When I looked closely at the commercial ActiveX control we were using to parse MIME email messages, we discovered it was doing exactly the wrong thing with character sets, so we actually had to write heroic code to undo the wrong conversion it had done and redo it correctly. When I looked into another commercial library, it, too, had a completely broken character code implementation. I corresponded with the developer of that package and he sort of thought they "couldn't do anything about it." Like many programmers, he just wished it would all blow over somehow.

But it won't. When I discovered that the popular web development tool PHP has almost complete ignorance of character encoding issues, blithely using 8 bits for characters, making it darn near impossible to develop good international web applications, I thought, enough is enough.

So I have an announcement to make: if you are a programmer working in 2003 and you don't know the basics of characters, character sets, encodings, and Unicode, and I catch you, I'm going to punish you by making you peel onions for 6 months in a submarine. I swear I will.)原来无聊的话我就不翻译哦;

---

一:IT'S NOT THAT HARD.

在这篇文章中我将写一个每一个在工作中的程序员都应该知道的知识,关于"plain text = ascii = characters are 8 bits",这不只是错误而且还是绝望的错误,如果你仍然有这样的设计方法,你也比体检医生不相信有细菌好不了多少(you're not much better than a medical doctor who doesn't believe in germs),请不要写任何一行代码,直到你看完这遍文章前;

我开始之前,我应该警告你,如果你是一个知道国际化的杰出人士,你将发现我全部讨论少量二进制过分简单(a little bit oversimplified),我是实在地试着让每一个人都能在最小的阻力下,正在写代码又希望能与其他英语以外的任何语言文本上合作的每一个人都能懂得,并警告字符操作只是你创建这软件工作于国际化中微小的一部分,但我能在今天有限的时间中只写一点东西就要完成这个问题,那就是字符集.

(2)A Historical Perspective

以下的你很容易的了解到的这按年带顺序排列的资料.

你可能意识到我将会谈非常老的字符集像EBCDIC,好,我愿意.EBCDIC不会和你的生活有关,我们没有回到很远的时期.

(Back in the semi-olden days)回到很古老的时期,当UNIX被创造和K&B写C Programming Language出现时,每件事物是非常的简单,EBCDIC已经开始走出,这个字符集唯一的问题是一些很好的老的不发音的英语单词上,但我们已经有一个编码被叫做ASCII,每一个编码都用32到127之间的数字来显示.如Space是一个32,这个"A"是65,这个能方便的存储在7bits.大部分电脑在这个时期都是使用8-bit bytes,所有你每一个都能ASCII来存储字符,但你已经完全二进制体系,如果你是没有道德的,你使用你自己的偏僻意图:(the dim bulbs at WordStar actually turned on the high bit to indicate the last letter in a word, condemning WordStar to English text only). 无光的球型物在WordStar事实上转换成更高的位显示在一个文本的最后一个字母后,申讨WordStar到英文文字.编码在32以下的被看做不道德和被使用者漫骂的,只有取笑(Just kidding),他们使用为控制字符,像7就是制造你的电脑哗哗声,还有12 引起纸的当前页打印冲出和新的一页被反馈.

还有更好的,傲慢的英语演讲者.

 
因为二进制有空间是8位,很多人开始想"糟糕,我们能使用的代码是128-255才适合我们使用",麻烦的是很多人在同时有一些想法,和他们自己想特有空间都是128-255,IBM-PC已经有些东西带来为被成为OEM提供一些欧洲语言重音字符字符和一个线条串绘制字符,horizontal bars, vertical bars,horizontal bars关于很少摇摆抖动,摇摆成左边图:
并且你能使用这些线绘制出的字符去在屏幕上制作好看的盒子形状和线,你还能看到它们运行在8088电脑上,如在你的干洗店中,实际一开始买美国出口的PC就各种不同的OEM字符集就被设计出来,所有使用的都是最高128字符为他们特有的用途.例如一些PC字符码为130显示是é,但电脑卖到以色列它是 "Hebrew letter Gimel (希伯文),所以当美国发送他们的金额到以色列,他们到达时候就是as rsums."  ",很多案例啊,如俄罗斯,有很多不同的概念,需要不同大写128字符,所以你不能有可靠的与俄罗斯交流的文档.

最后这个OEM可以自由参与的编码ANSI标准诞生,在ANSI标准中,每一个人同意使用128以下,这是接近ASCII,但有很多不同方式操作字符是在128之上,依赖于128之上的而活着,这些不同的系统被调用code pages .

所以例如在以色列DOS使用一个code page 被叫做862,当Greek用户使用的是737.他们是并不是在128下,不同是在128之上,所有字符居住这儿,在国际的MS-DOS已经很多这些code pages, 操作每一件事物来于英语到冰岛和他们的曾经有的 很少的"多语言" code pages 能做世界语和加利西亚人在同样的电脑上!呼叫,但得到,说,希伯来人和希腊人同样在电脑上是完全不可能的,除非你自己定制写一个使用位图来显示,因为希伯来人和希腊人必须不同的编码页(code pages)不同的高级翻译(with different interpretations of the high numbers).

其间,在亚洲,甚至更疯狂东西将考虑亚洲字母表实际上有数千个字符,决不适合8位,这通常被杂乱的系统调用DBCS(double-byte character set，双字节字符集，用于对 Chinese, Japanese and Korean语言的支持。)解决,这个"double byte character set"是一些字符被存储在一个btye和其他两个btye,它是很容易前移字符串,但最重要去向后移动.程序员鼓励不使用s++和s--来后一个或前一个,但取代之的是调用函数如Windows'AnsiNext 和 AnisPrev,能很好的分配杂乱的一切.

但仍然,大部分人仅仅虚假知道一个byte是一个字符和一个字符是8byte和可能你从未将一个电脑上的一个字符串移到另一个电脑上或者使用更多种语言分类别保持良好工作,但一来到Internet上字符串就从一台电脑移动其他电脑是非常常见拉,并且造成完全的混乱(and the whole mess came tumbling down).幸好,Unicode被发明.

Unicode

Unicode 是一个勇敢努力的去创建一个单字符集包含在这个星球上每一个合理的输入系统和某一个方言,一些人误解Unicode是每一个字符都带有一个16位数字,就简单认为Unicode是简单的16位字符,因此可能有65.536字符,这并不是这样的,事实上它是个别部分Unicode是虚构的,所以如果你是这样认为,会别感觉很不舒服.
  实际,Unicode已经有一个不同考虑字符的方式,和只有你已经懂得Unicode考虑方式,否则将会产生误解.
到目前为止,我们已经假设一个字符影射成位(bits),保存在硬盘和内存中:

A -> 0100 0001

在Unicode,一个字符影射成一些东西上调用一个编码点,这仍然是一个理论上的,编码点是被在内存或硬盘描绘是一个完全是虚构的(How that code point is represented in memory or on disk is a whole nuther story.).

在Unicode,字符"A"是一个理想的主意,(It's just floating in heaven)它正好是不固定在理想中的部分:

A

这是理想中"A"与"B"不同,和"a"不同,但不同字体的A and A是相同的,这个主意A在是a Times New Roman字体与a Helvetica字体是相同的,但小写的"a"是不同的,不需要争论,但在同一语言中正好断定一个字符是会能引起争论.如德国的字母"B"是一个真实的字母或只是"SS(纳粹)"一个不同写的方式,如果一个字母的形状改变,是一个不同的字母吗??,希伯文说"yes"阿拉伯文说"no".无数个回答,聪明的人在Unicode协会已经指出这个问题在大约十年前,被大量行政辩论,和你不得不担心这个问题.他们已经有答案件.

每一个理想字母在每一个字母表是被Unicode 协会分配一个魔幻数字是U+0639.这个魔幻数字被调用一个编码点.U+是代表"Unicode"和一个十六位进制数.U+0639是阿拉伯文字母Ain.这个英语字母A是U+0041.你能发现他们所有使用魔法的有效性使在Windows 2000/XP/2003或看the Unicode web site.

没有真实限制多少个字母能被Unicode定义,实际已经他们有超出65.536,所以不是每一个unicode字母能真实被挤进两bytes.(but that was a myth anyway.)

好,现在说字符串:

Hello

这个在Unicode,适合5个编码点:

U+0048 U+0065 U+006C U+006C U+006F.

只是一个捆绑的编码点(code points).数字,真的.我们还没有任何事情关于怎样存储这个内存中或描绘它在一个email信息中.

Encodings

这是encodings的引入

这最好的主意是Unicode encoding,带着这两个bytes的故事继续,让我们存储这些数字在两个btyes.所以hello 变成:
00 48 00 65 00 6C 00 6C 00 6F

对嘛?不是那样!是这样吗:
48 00 65 00 6C 00 6C 00 6F 00 ?

well,技术上,是对的,我相信它是对的,但在实际中,早期执行应该存储他们的Unicode编码点在high-endian或low-endian 模式下.无论选择那一个他们的CPU都是最快的,接着看,它就像晚上和早上时分为两种来方法存储Unicode样,所以人们被强迫提出奇异的存储协议一个"FE""FF"做为每一个Unicode字符串的开始;这要被叫做一个Unicode Byte Order Mark 和如果你要交换你的高级和低级的Bytes它将像一个FF FE样且一个人读取你的字符串将会知道他们是否有与其他byte交换.哟(Phew).一开始没有每一个字符串在他们的外部都有一个Unicode byte order mark.

暂时它看似已经足够哦,但程序员是在抱怨哦.他们说"Look at all those zeros!"以前他们是美国人和他们很少使用在编码点U+00FF之上来查看英语文本.还有在加里弗里亚他们是自由主意西皮士,他们要保存.如果他们是德克萨斯的他们将要狂饮两次的字节数的思想(If they were Texans they wouldn't have minded guzzling twice the number of bytes.).当这些无用的加里弗里亚人不能以任何方式担负被查看双倍存储总数的字符串时,他们所有该死的文档输出都是使用各种不同的ANSI和DBCS字符集,谁将来传换他们?MOI?因为在这几年大部分人决定不理睬Unicode并且在这段时期事态还变得更糟糕.

因此是创造这个更闪光的UTF-8概念.UTF-8是其他系统为存储你的Unicode编码点字符串,这些魔法U+数字,在存储器使用8位字节.在UTF-8,每一个编码点来0-127被存储在单一字节.只编码点128和被存储在使用2,3,之上,实际上,等于6字节.

这已经有灵活的副作用英语文本关注严密地UTF-8如同ASCII,所以美国人不能即使提示任何错误.只不过世界其余已经越过hoops.详细如,Hello,U+0048 U+0065 U+006C U+006C U+006F, 将储存为 48 65 6C 6C 6F,看!同使用ASCII存储一样,和ANSI,在这个星球上每一个OEM字符集.现在,如果你是粗体像使用重音字母或希腊字母或Klingon letters,,你将有一个使用几个字节存储单一编码点,但美国人将决不注意到.(UTF-8 also has the nice property that ignorant old string-processing code that wants to use a single 0 byte as the null-terminator will not truncate strings).

到目前为止我谈论你三个encoding Unicode的方式.在传统存储(store-it-in-two-byte)方法被叫UCS-2(因为已经有两个字符)或者UTF-16(因为他是16bits),和你仍然要指出它是high-endian UCS-2 还是 low-endian UCS-2.和有流行新的UTF-8标准已经有很好的协同工作的特性,如果你陶醉于你的英语文本良好的一致性和大脑编程是完整地一致,这个任何事情都比ASCII好.

这实际encoding Unicode还有其他捆绑方式.这个就被叫做UTF-7,这很像UTF-8但它会保证较高位的将始终是0,所以如果你有通过使用这一种Unicode在一些严格国家机构email系统上我想7位是完全足够的,感谢,它仍然刚好够用.还有UCS-4是存储每一个编码点在4个字节中,已经有一个每一个很精密的属性单一编码点能被存储在同一字节数,但,神啊,恰适德客萨斯人将不能被粗体耗费更多内存了.

并且事情上现在你所想的事物是按照理想中的被Unicode编码点描述的字母,这些Unicode编码点能被编码在一些老学校编码模式中,太好!例如,你能用编码Unicode为字符串Hello(U+0048 U+0065 U+006C U+006C U+006F)在ASCII中使用,或者在老的OEM希腊文编码,或希伯来文ANSI边名，或更多几百中编码被创造,捕获方式:一些字母不能被显露!如果有没使用和Unicode编码点相配的编码,你要尝试将编码呈现现出来,你常常得到是一些问号"?"或如果你已经作得很好啦,你会得到->.

有许多传统的编码能只用保存一些编码点正确和转换其他非正确的编码点为问好"?".一些流行的英语文字编码是Windows-1252 (the Windows 9x standard for Western European languages) 和ISO-8859-1,aka Latin-1 (also useful for any Western European language).但尝试保存俄罗斯或希伯来人字母在这写编码得到一串问号.UTF7,8,16和32这些很好的属性,能储存任何正确的编码点.

The Single Most Important Fact About Encodeings

如果你完全忘记我刚才说的任何事物,请记得一个最重要的实践.有意义的一个字符串不知道他的编码使用,(It does not make sense to have a string without knowing what encoding it uses.)你能不再粘贴你的头部分和制作一个假的"无格式"ASCII文本.

There Ain't No Such Thing As Plain Text.(无格式不是完全不对)

如果你有一个字符串,在内存中,或在一个文件,或一个email中,你已经知道编码是怎样执行的,或你不能解释它,或显示它给你用户正确的.

几乎每一个愚蠢的"我的站点发现像乱码"或"当我使用重音她不能读我的emails"的问题涉及一个天真的程序员不懂得简单事实,如果你不能告诉我一个特别的字符串是否被使用UTF-8 or ASCII or ISO 8859-1 (Latin 1) or Windows 1252 (Western European),那你不能把它正确显示或从未出它现的最后结果.有超过数百个编码和都在编码点127之上的,所有赌博都要取消.

我怎样才能保存，提供一些信息给将要编码的这些字符串时使用啦?好,有标准的做法.如一个email,你预先就有一些字符串Content-Type: text/plain; charset="UTF-8"放在头部,如一个web页面,最初的主意是在web服务器简单的Content-Type的http头和web页面一起返回,但注意并没有将它放在HTML中,但这样的话在发送HTML时前,就要先响应Http头（header）.

这样引起一问题.假想你有一大的web服务器有更多站点和上百个页面被很不同语言不同的人访问，又如这样做后再编码后拷贝到Microsoft FrontPage你看会产生什么, web服务器自己都不能真正的知道是那一个文件该怎样编码,所以它不能发送Content-Type header.

如果 能将Content-Type放在HTML文件中它将变得更方便拉.当然这是理论上的疯狂,你能读HTML文件直到你知道它是怎样编码，可能吗?!很幸运,几乎每一个编码在共同使用时,字符集都是在32和127,所以你能始终得到从远处发来的全整HTML页面，只要没有使用有趣的字母，如下面这样
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

但现在Meta标签已经最首先放在<head>中,因为一开始Web 浏览器就能看到这个标签,它将停止编译页面并当由指定编码类型开始全部重新解释.

如果浏览器没有找到Content-Type,http headers,meta tag会做什么拉?Internet Explorer做的十分有趣:它是尝试去猜,根据各种不同的二进制出现在文本特征和在各种语言中编码特征的频率去猜,使用的什么语言,什么编码,因为各种老的8位编码页趋向于放他们的国际字母在128-255不同的范围,和因为每一人的语言字母已经有不同特征,事实上偶尔也回有正常工作的机会.它真不可思意,但它可以用当你不知道你需要那种Content-Type的时候,你就用它来运行一下,你就知道哦.知道有一天,他们写一些东西不正确遵照他们本地语言文字的频率分布(letter-frequency-distribution ),和Internet Explorer决定它是给朝鲜人显示的.因此,校对是成功的,我想指出"Postel'的律师的观点是"保守派在于的发表和自由主义者来赞成"是十分直白不是一个很好的工程原理,总之,可怜网页的读者,是在保加利亚写的,但显示是给朝鲜人(and not even cohesive Korean)的,他使用的View|Encoding 菜单和尝试一个捆绑不同的编码(东欧至少有20种语言)直到像图片中一样的普通文字显示出来,如果他都知道做什么,大部分人也应该知道.
 

最后是城市办公桌面(CityDesk)的版本,我的公司发布web页面的管理软件,我们决定每一个东西内部都使用UCS-2 Unicode,新的VisualBasic,COM,和WindowsNT/2000/XP使用他们本地字符串类型,在C++代码我们只是定义一个字符串如wchar_t代替char和使用 wcs函数代替str函数(例如wcscat和wcslen代替strcat和strlen).这样在C代码中创建一个UCS-2字符,你只需要在"Hello"前面放一个L,就可以显示.

当城市办公桌发布页面,它是被转换成UTF-8 encoding,已经被很多浏览器很好的支持了很多年.Joel软件被编码后有29种语言版本,我们还未听到一个人说不能够查看它们.

这篇文章很长,我覆盖每一个字符编码和Unicode的知识,但我希望如果你读后,你知识累积足够后再返回去编程,使用抗生素代替吸血鬼和符咒,我有一个任务.先离开拉.

============================================

什么是EBCDIC?

EBCDIC（广义二进制编码的十进制交换码）（读作"ehb-suh-dik"或"ehb-kuh-dik"），是字母或数字字符的二进制编码，是IBM为它的更大型的操作系统而开发的。它是为IBM的S/390上的IBMOS/390操作系统上使用的文本文件的编码，并且数千个公司为它们的遗留应用程序和数据库使用这种编码。在一个EBCDIC的文件里，每个字母或数字字符都被表示为一个8位的二进制数（一个0、1字符串）。256个可能的字符被定义（字母，数字和一些特殊字符）。　　

IBM的个人计算机和工作站操作系统不使用它们所有的EBCDIC编码。相反的，它们使用文本的工业标准编码，ASCII码。转化程序允许不同的操作系统从一种编码到另一种编码的转化。　　

也可参见统一的字符编码标准。Name=ear and mouthCName=听说接口Site=searchEnterpriseVoiceCategory=Def=　　

听说接口是一种IP网络上的语音技术，它使用带有耳机（或听筒）的传统的电话筒来收听接收的音频，用扩音器（或话筒）来传送音频。使用E&M 接口的电话可以用专用分组交换机(PBX)做成、也可以接收PBX的信号、或可以由PBX 断开连接，而这些同样可以由支持VoIP 技术的计算机来完成。　　

E&M 的主要优点是它可以允许PBX可靠的检测断开的（挂起的）信号。这就消除了可能会在终端的电话呼叫锁定的计算机端口上出现的问题，这样就使占用不必要的大量网络资源的危险减小到最低。这种听说接口有时也用作电话筒本身的同步或允许免提功能德听筒和扩音器的连接同步。

什么是ASCII码?

鉴于信息交换的重要及为统一文字符号的编码标准，让不同厂牌机型的计算机皆能使用同一套标准化的信息交换码，于是美国国家标准局特别制定了ASCII码(America Standard Code for Information Interchange，美国信息交换标准码)，作为数据传输的标准码。早期使用7 个位来表示英文字母、数字0~9及其它符号，现在则使用8个位，共可表示256个不同的文字与符号，为目前各计算机系统中使用最普遍也最广泛的英文标准码，相对于ASCII code，中文系统使用最广泛的内码则为Big-5码

什么是ANSI?(www.ansi.org)
 1、 美国国家标准学会(ANSI)简介
1918年，美国材料试验协会(ASTM)、与美国机械工程师协会(ASME)、美国矿业与冶金工程师协会(ASMME)、美国土木工程师协会 (ASCE)、美国电气工程师协会(AIEE)等组织，共同成立了美国工程标准委员会(AESC)。美国政府的三个部(商务部、陆军部、海军部)也参与了该委员会的筹备工作。
1928年，AESC改组为美国标准协会(ASA)。1966年8月，又改组为美利坚合众国标准学会(USASI)。1969年10月6日改成现名：美国国家标准学会(American National Standard Institute, ANSI)。ANSI现有工业学、协会等团体会员约200个，公司(业)会员约1400个。领导机构是由主席、副主席及50名高级业务代表组成的董事会。董事会闭会期间，由执行委员会行使职权，执行委员会下设标准评审委员会，由15人组成。总部设在纽约，卫星办公室设在华盛顿。ANSI下设四个委员会：学术委员会、董事会、成员议会和秘书处。
2、 ANSI标准编制程序
美国国家标准学会本身很少制订标准。其ANSI标准的编制，主要采取以下三种方式：
1、由有关单位负责草拟，邀请专家或专业团体投票，将结果报ANSI设立的标准评审会审议批准。此方法称之为投票调查法。
2、由ANSI的技术委员会和其他机构组织的委员会的代表拟订标准草案，全体委员投票表决，最后由标准评审会审核批准。此方法 称之为委员会法。
3、从各专业学会、协会团体制订的标准中，将其较成熟的，而且对于全国普遍具有重要意义者，经ANSI各技术委员会审核后，提 升为国家标准(ANSI)并冠以ANSI标准代号及分类号，但同时保留原专业标准代号。
美国国家标准学会的标准，绝大多数来自各专业标准。另一方面，各专业学会、协会团体也可依据已有的国家标准制订某些产品标准。当然，也可不按国家标准来制订自己的协会标准。

什么是unicode?
点这里Unicode

---

下一篇还是<<CSS蝉意花园读书精记>>(基础篇---------上.资料篇)只不过是2...hihi  ....谢谢大家.

=========================works guo==========