維基百科

字元編碼

字元編碼（英語：Character encoding）、字碼、字集碼是把字元集中的字元為指定集合中某一對象（例如：位元模式、自然數序列、八位元或者電脈衝），以便文字在電腦中儲存和通過通訊網絡的傳遞。

純就字面解釋，這些術語是有不同的概念，但在許多的中文語境，這些術語會混用，有相同的概念。字元集，是指「字元的集合」，如中文字元集、英文字元集，不牽涉到編碼。字元編碼、字集碼、字碼，則是「對於某個字元集，為其字元編碼」，根據語義，有時指單一字元的編碼，有時是指全部字元的編碼。

在計算機支援語言、文字的過程中，要支援某個文字，必然要搜集所使用的字元，為其編碼，因此，初期並未區分字元集和字元編碼的不同。譬如，大五碼、國標碼、ASCII既指字元集，又指針對此字元集的編碼方式。在統一碼之後，則細分字元集和編碼形式的不同。同一個字元集，可以有不同的編碼形式，如UTF-8、UTF-16。

常見的例子包括將拉丁字母表編碼成摩斯電碼和ASCII。其中，ASCII將字母、數字和其它符號編號，並用7位元的二進制來表示這個整數。通常會額外使用一個擴充的位元，以便於以1個位元組的方式儲存。

在電腦技術發展的早期，如ASCII（1963年）和EBCDIC（1964年）這樣的字元集逐漸成為標準。但這些字元集的局限很快就變得明顯，於是人們開發了許多方法來擴充它們。對於支援包括東亞CJK字元家族在內的寫作系統的要求能支援更大量的字元，並且需要一種系統而不是臨時的方法實現這些字元的編碼。

有時，為強調其所使用的方式而使用其他術語，譬如：為說明「電腦系統『內部』 處理文字資料所使用的字元編碼」時，會使用內碼。為「不同電腦系統之間，為了『交換』資料所採用的字元編碼」時，會使用交換碼。

簡單字元集

編輯

按照慣例，人們認為字元集和字元編碼是同義詞，因為使用同樣的標準來定義提供什麼字元並且這些字元如何編碼到一系列的代碼單元（通常一個字元一個單元）。由於歷史的原因，MIME和使用這種編碼的系統使用術語字元集來表示用於將一組字元編碼成一系列八位位元組數據的整個系統。

現代編碼模型

編輯

由統一碼和通用字元集所構成的現代字元編碼模型則沒有跟從簡單字元集的觀點。它們將字元編碼的概念分為：有哪些字元、它們的編號、這些編號如何編碼成一系列的「碼元」（有限大小的數字）以及最後這些單元如何組成八位位元組流。區分這些概念的核心思想是建立一個能夠用不同方法來編碼的一個通用字元集。為了正確地表示這個模型需要更多比「字元集」和「字元編碼」更為精確的術語表示。在Unicode Technical Report (UTR) #17中，現代編碼模型分為5個層次，所用的術語列在下面：

  1. 抽象字元表（Abstract character repertoire）是一個系統支援的所有抽象字元的集合。字元表可以是封閉的，即除非建立一個新的標準（ASCII和多數ISO/IEC 8859系列都是這樣的例子），否則不允許添加新的符號；字元表也可以是開放的，即允許添加新的符號（統一碼和一定程度上代碼頁是這方面的例子）。特定字元表中的字元反映了如何將書寫系統分解成線性資訊單元的決定。例如拉丁、希臘和斯拉夫字母表分為字母、數字、變音符號、標點和如空格這樣的一些少數特殊字元，它們都能按照一種簡單的線性序列排列（儘管對它們的處理需要另外的規則，如帶有變音符號的字母這樣的特定序列如何解釋——但這不屬於字元表的範疇）。為了方便起見，這樣的字元表可以包括預先編號的字母和變音符號的組合。其它的書寫系統，如阿拉伯語和希伯萊語，由於要適應雙向文字和在不同情形下按照不同方式交叉在一起的字形，就使用更為複雜的符號表表示。
  2. 編碼字元集（CCS:Coded Character Set）是將字元集 中每個字元對映到1個坐標（整數值對：x, y）或者表示為1個非負整數 。字元集及碼位對映稱為編碼字元集。例如，在一個給定的字元表中，表示大寫拉丁字母「A」的字元被賦予整數65、字元「B」是66，如此繼續下去。多個編碼字元集可以表示同樣的字元表，例如ISO-8859-1和IBM的頁碼037和頁碼500含蓋同樣的字元表但是將字元對映為不同的整數。由此產生了編碼空間（encoding space）的概念：簡單說就是包含所有字元的表的維度。可以用一對整數來描述，例如：GB 2312的漢字編碼空間是94 x 94。可以用一個整數來描述，例如：ISO-8859-1的編碼空間是256。也可以用字元的儲存單元尺寸來描述，例如：ISO-8859-1是一個8位元的編碼空間。編碼空間還可以用其子集來表述，如行、列、面（plane）等。編碼空間中的一個位置（position）稱為碼位（code point）。一個字元所佔用的碼位稱為碼位值（code point value）。1個編碼字元集就是把抽象字元對映為碼位值。
  3. 字元編碼表（CEF:Character Encoding Form），也稱為"storage format"，是將編碼字元集的非負整數值（即抽象的碼位）轉換成有限位元長度的整型值（稱為碼元code units）的序列。這對於定長編碼來說是個到自身的對映（null mapping），但對於變長編碼來說，該對映比較複雜，把一些碼位對映到一個碼元，把另外一些碼位對映到由多個碼元組成的序列。例如，使用16位元長的儲存單元儲存數字資訊，系統每個單元只能夠直接表示從0到65,535的數值，但是如果使用多個16位元單元就能夠表示更大的整數。這就是CEF的作用，它可以把Unicode從0到140萬的碼空間範圍的每個碼位對映到單個或多個在0到65,5356範圍內的碼值。最簡單的字元編碼表就是單純地選擇足夠大的單位，以保證編碼字元集中的所有數值能夠直接編碼（一個碼位對應一個碼值）。這對於能夠用使用八位元組來表示的編碼字元集（如多數傳統的非CJK的字元集編碼）是合理的，對於能夠使用十六位元來表示的編碼字元集（如早期版本的Unicode）來說也足夠合理。但是，隨着編碼字元集的大小增加（例如，現在的Unicode的字元集至少需要21位才能全部表示），這種直接表示法變得越來越沒有效率，並且很難讓現有電腦系統適應更大的碼值。因此，許多使用新近版本Unicode的系統，或者將Unicode碼位對應為可變長度的8位元位元組序列的UTF-8，或者將碼位對應為可變長度的16位元序列的UTF-16。
  4. 字元編碼方案（CES:Character Encoding Scheme），也稱作"serialization format"。將定長的整型值（即碼元）對映到8位元位元組序列，以便編碼後的數據的檔案儲存或網絡傳輸。在使用Unicode的場合，使用一個簡單的字元來指定位元組順序是大端序或者小端序（但對於UTF-8來說並不需要專門指明位元組序）。然而，有些複雜的字元編碼機制（如ISO/IEC 2022）使用控制字元跳脫序列在幾種編碼字元集或者用於減小每個單元所用位元組數的壓縮機制（如SCSU、BOCU和Punycode）之間切換。
  5. 傳輸編碼語法（transfer encoding syntax），用於處理上一層次的字元編碼方案提供的位元組序列。一般其功能包括兩種：一是把位元組序列的值對映到一套更受限制的值域內，以滿足傳輸環境的限制，例如Email傳輸時Base64或者quoted-printable，都是把8位元的位元組編碼為7位長的數據；另一是壓縮位元組序列的值，如LZW或者行程長度編碼等無損壓縮技術。

高層機制（higher level protocol）提供了額外資訊，用於選擇Unicode字元的特定變種，如XML屬性xml:lang

字元對映（character map）在Unicode中保持了其傳統意義：從字元序列到編碼後的位元組序列的對映，包括了上述的CCS, CEF, CES層次。

字元集、頁碼，與字元對映

編輯

術語字元編碼（character encoding），字元對映（character map），字元集（character set）或者頁碼，在歷史上往往是同義概念，即字元表（repertoire）中的字元如何編碼為碼元的流（stream of code units）–通常每個字元對應單個碼元。

碼元（Code Unit，也稱「代碼單元」）是指一個已編碼的文字中具有最短的位元組合的單元。對於UTF-8來說，碼元是8位元長；對於UTF-16來說，碼元是16位元長；對於UTF-32來說，碼元是32位元長[1]。碼值（Code Value）是過時的用法。

頁碼通常意味着面向位元組的編碼，但強調是一套用於不能語言的編碼方案的集合.著名的如"Windows"頁碼系列，"IBM"/"DOS"頁碼系列.

IBM的字元數據表示體系（Character Data Representation Architecture - CDRA）與編碼字元集識別碼（coded character set identifiers - CCSIDs） 常常把charset, character set, code page, or CHARMAP等類似意義的術語混用.

Unix或Linux不使用頁碼概念，它們用charmap，比locales具有更廣泛的含義.

與上文的編碼字元集（Coded Character Set - CCS）不同，字元編碼（character encoding）是從抽象字元到代碼字（code word）的對映. HTTP（與MIME）的用法中，字元集（character set）與字元編碼同義，但與CCS不是一個意思.

字元編碼（不全）

編輯

西歐標準

編輯

DOS字元集（又稱IBM頁碼）

編輯

Windows字元集

編輯

亞洲字元集

編輯

尤其是漢字編碼。

臺灣

編輯

日本

編輯

中國大陸及港澳

編輯

朝鮮半島

編輯

越南

編輯

印度

編輯

統一碼

編輯

字元轉換工具

編輯

由於有很多種字元編碼方法被使用，從一種字元編碼轉換到另一種，需要一些工具。

跨平台：

  • 網頁瀏覽器–大多數現代的網頁瀏覽器都具有此功能。一般是在選單"檢視"（View）/"字元編碼"（Character Encoding）
  • iconv –程式與編程API，用於字元編碼轉換
  • convert_encoding.py –基於Python的轉換工具.[2]
  • decodeh.py –用於啟發性猜測編碼方案的演算法與模組.[3]
  • 國際統一碼部件 –一套C語言與Java語言的開源庫，由IBM提供，用於統一碼等多語言編碼的轉換、實現.
  • chardet – Mozilla的編碼自動檢測代碼的Python語言實現.
  • 新版本的Unix命令File做字元編碼的檢測.（cygwin與mac都有此命令）

Linux:

  • recode – [4]
  • utrac – 將整個檔案內容從一種字元編碼轉換到另外一種[5]
  • cstocs –
  • convmv –轉換檔名.[6]
  • enca –分析編碼模式.[7]

Microsoft Windows:

  • Encoding.Convert – .NET API[8]
  • MultiByteToWideChar/WideCharToMultiByte – Windows API[9]
  • cscvt –轉換工具[10]
  • enca –分析編碼方法[11]

參考文獻

編輯
  1. ^ Glossary of Unicode Terms. [2012-04-07]. （原始內容存檔於2015-12-26）. 
  2. ^ Homepage of Michael Goerz – convert_encoding.py. [2012-03-23]. （原始內容存檔於2010-10-28）. 
  3. ^ Decodeh – heuristically decode a string or text file. [2012-03-23]. （原始內容存檔於2008-01-08）. 
  4. ^ Recode – GNU Project – Free Software Foundation (FSF). [2012-03-23]. （原始內容存檔於2021-02-10）. 
  5. ^ Utrac Homepage. [2006-05-12]. （原始內容存檔於2021-01-25）. 
  6. ^ Convmv – converts filenames from one encoding to another. [2012-03-23]. （原始內容存檔於2018-06-11）. 
  7. ^ Extremely Naive Charset Analyser. [2012-03-23]. （原始內容存檔於2010-12-04）. 
  8. ^ Microsoft .NET Framework Class Library – Encoding.Convert Method. [2012-03-23]. （原始內容存檔於2012-04-21）. 
  9. ^ MultiByteToWideChar/WideCharToMultiByte – Convert from ANSI to Unicode & Unicode to ANSI. [2012-03-23]. （原始內容存檔於2015-02-12）. 
  10. ^ Character Set Converter. [2012-03-23]. （原始內容存檔於2012-03-26）. 
  11. ^ Extremely Naive Charset Analyser. [2012-03-23]. （原始內容存檔於2012-03-15）. 

參閱

編輯

外部連結

編輯
取自 "https://zh.wikipedia.org/w/index.php?title=字符编码&oldid=84307776"