字元編碼

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

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

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

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

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

有時，為強調其所使用的方式而使用其他術語，譬如：為說明「電腦系統『內部』

處理文字資料所使用的字元編碼」時，會使用。為「不同電腦系統之間，為了『交換』資料所採用的字元編碼」時，會使用。

簡單字元集

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

現代編碼模型

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

抽象字元表（Abstract character repertoire）是一個系統支援的所有抽象字元的集合。字元表可以是封閉的，即除非建立一個新的標準（ASCII 和多數 ISO/IEC8859 系列都是這樣的例子），否則不允許新增新的符號；字元表也可以是開放的，即允許新增新的符號（統一碼和一定程度上內碼表是這方面的例子）。特定字元表中的字元反映瞭如何將書寫系統分解成線性資訊單元的決定。例如拉丁、希臘和斯拉夫字母表分為字母、數字、變音符號、標點和如空格這樣的一些少數特殊字元，它們都能按照一種簡單的線性序列排列（儘管對它們的處理需要另外的規則，如帶有變音符號的字母這樣的特定序列如何解釋 —— 但這不屬於字元表的範疇）。為了方便起見，這樣的字元表可以包括預先編號的字母和變音符號的組合。其它的書寫系統，如阿拉伯語和希伯萊語，由於要適應雙向文字和在不同情形下按照不同方式交叉在一起的字形，就使用更為複雜的符號表表示。
編碼字元集（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 個編碼字元集就是把抽象字元對映為碼位值。
字元編碼表（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。
字元編碼方案（CES:Character Encoding Scheme），也稱作 "serialization format"。將定長的整型值（即碼元）對映到 8 位位元組序列，以便編碼後的資料的檔案儲存或網路傳輸。在使用 Unicode 的場合，使用一個簡單的字元來指定位元組順序是大端序或者小端序（但對於 UTF-8 來說並不需要專門指明位元組序）。然而，有些複雜的字元編碼機制（如 ISO/IEC 2022）使用控制字元轉義序列在幾種編碼字元集或者用於減小每個單元所用位元組數的壓縮機制（如 SCSU、BOCU 和 Punycode）之間切換。
傳輸編碼語法（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 位元長。碼值（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 不是一個意思.

字元編碼（不全）

ASCII
EBCDIC

4.1 西歐標準

ISO-8859-1
ISO-8859-5
ISO-8859-6
ISO-8859-7
ISO-8859-11
ISO-8859-15
ISO/IEC 646

4.2 DOS 字元集（又稱 IBM 內碼表）

CP437
CP737
CP850
CP852
CP855
CP857
CP858
CP860
CP861
CP863
CP865
CP866
CP869

4.3 Windows 字元集

Windows-1250
Windows-1251：用於西裡爾字母表
Windows-1252
Windows-1253
Windows-1254
Windows-1255：用於希伯萊語
Windows-1256：用於阿拉伯語
Windows-1257
Windows-1258：用於越南語

4.4 亞洲字元集

尤其是。

4.4.1 臺灣

大五碼
中文資訊交換碼
中文標準交換碼
EUC

4.4.2 日本

ISO/IEC 2022
Shift JIS
EUC

4.4.3 中國大陸及港澳

GB/T 2312
GB/T 12345
EUC
GBK（規定檔案為 GB13000）
GB 18030
香港增補字元集

4.4.4 朝鮮半島

EUC
KOI8-R
KOI8-U
KOI7
MIK

4.4.5 越南

越南資訊交換標準程式碼

4.4.6 印度

印度文字資訊交換碼

4.4.7 統一碼

統一碼
UTF-7
UTF-8
UTF-16
UTF-32

字元轉換工具

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

跨平臺：

網頁瀏覽器–大多數現代的網頁瀏覽器都具有此功能。一般是在選單 "檢視"（View）/"字元編碼"（Character Encoding）
iconv –程式與程式設計 API，用於字元編碼轉換
convert_encoding.py –基於 Python 的轉換工具.

decodeh.py –用於啟發性猜測編碼方案的演算法與模組.

國際統一碼部件 –一套 C 語言與 Java 語言的開源庫，由 IBM 提供，用於統一碼等多語言編碼的轉換、實現.

chardet – Mozilla 的編碼自動檢測程式碼的 Python 語言實現.

新版本的 Unix 命令 File 做字元編碼的檢測.（cygwin 與 mac 都有此命令）

Linux:

recode –
utrac – 將整個檔案內容從一種字元編碼轉換到另外一種
cstocs –
convmv –轉換檔名.

enca –分析編碼模式.

Microsoft Windows:

Encoding.Convert – .NET API
MultiByteToWideChar/WideCharToMultiByte – Windows API
cscvt –轉換工具
enca –分析編碼方法

參閱

:Category: 字元編碼 — 關於通用字元編碼的文章
:Category: 字元集 — 關於特殊字元編碼的文章
亂碼 — 非對映字元集
內碼表
字形
點陣圖
畫素
體素
中文軟體
中文系統