《CSS蝉意花园读书精记》(基础篇---------上.资料篇1)
?這一篇文章主要是翻譯書中提到的國際化的一篇文章,并讓大家了解軟件開發中字符編碼的眾多問題,被翻譯的文章寫得比較早,可能從技術的角度來看不是很有意義的,作者在文中是概括主流的字符編碼,并不能讓大家深入的了解每一種編碼的特性,但他本身也是做國際化的軟件,所以他告訴大家軟件國際化中各字符編碼的使用會有怎樣的特點和注意的問題.其實總的就是注意在你的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==========
總結
以上是生活随笔為你收集整理的《CSS蝉意花园读书精记》(基础篇---------上.资料篇1)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： HDU 1407 测试你是否和LTC
- 下一篇： CSS：盒模型