ASCII定義了128個字符，它們映射到數字0–127。Unicode定義（少于2個）^21個字符，類似地，它們映射到數字0–2 ²¹（盡管當前并非所有數字都被分配，而某些數字是保留的）。

Unicode是ASCII的超集，數字0–127在ASCII中的含義與在Unicode中的含義相同。例如，數字65表示“拉丁大寫字母'A'”。

因為Unicode字符通常不適合一個8位字節，所以有許多種將Unicode字符存儲在字節序列中的方法，例如UTF-32和UTF-8。

首先了解為什么要創建ASCII和Unicode，這有助于我理解兩者之間的區別。

ASCII，起源

如其他答案所述，ASCII使用7位來表示字符。通過使用7位，我們最多可以有2 ^ 7（= 128）個不同的組合*。這意味著我們最多可以表示128個字符。

等一下7位 但是為什么不使用1個字節（8位）呢？

最后一位（第8位）用作奇偶校驗位以避免錯誤。這與多年前有關。

大多數ASCII字符是字母的可打印字符，例如abc，ABC，123，？＆！等。其他字符是控制字符，例如回車，換行，制表符等。

參見下面幾個ASCII字符的二進制表示形式：

0100101 -> % (Percent Sign - 37)

1000001 -> A (Capital letter A - 65)

1000010 -> B (Capital letter B - 66)

1000011 -> C (Capital letter C - 67)

0001101 -> Carriage Return (13)

請參閱此處的完整ASCII表。

ASCII僅用于英語。

什么？為什么只用英語？有那么多語言！

因為當時計算機行業的中心在美國。結果，他們不需要支持重音符號或其他標記，例如á，ü，?，?等（又稱變音符號）。

ASCII擴展

一些聰明的人開始使用第8位（用于奇偶校驗的位）來編碼更多字符以支持其語言（例如，以法語支持“é”）。只需使用一個額外的位，就可以將原始ASCII表的大小增加一倍，以映射最多256個字符（2 ^ 8 = 256個字符）。而不是像以前一樣2 ^ 7（128）。

10000010 -> é (e with acute accent - 130)

10100000 -> á (a with acute accent - 160)

該“ ASCII擴展到8位而不是以前的7位”的名稱可以簡稱為“擴展ASCII”或“ 8位ASCII”。

正如@Tom在下面的評論中指出的那樣，沒有諸如“ extended ASCII ”之類的東西，但這是引用此8位技巧的簡便方法。8位ASCII表有很多變體，例如ISO 8859-1，也稱為ISO Latin-1。

Unicode，崛起

ASCII擴展解決了基于拉丁字母的語言的問題……其他人需要完全不同的字母怎么辦？希臘語？俄語？中國人喜歡嗎？

我們將需要一個全新的字符集……這就是Unicode背后的原理。Unicode并不包含每種語言的每個字符，但它確實包含大量的字符（請參閱此表）。

您不能將文本以“ Unicode”保存到硬盤驅動器。Unicode是文本的抽象表示。您需要“編碼”此抽象表示。這就是編碼發揮作用的地方。

編碼：UTF-8與UTF-16與UTF-32

這個答案在解釋基本知識方面做得很好：

UTF-8和UTF-16是可變長度編碼。

在UTF-8中，一個字符可能至少占用8位。

在UTF-16中，字符長度以16位開始。

UTF-32是32位的固定長度編碼。

UTF-8將ASCII設置用于前128個字符。這很方便，因為這意味著ASCII文本在UTF-8中也有效。

助記符：

UTF- 8：最少8位。

UTF- 16：最少16位。

UTF- 32：最小和最大32位。

注意：

為什么是2 ^ 7？

這對于某些人來說是顯而易見的，但以防萬一。我們有七個可用0或1（二進制代碼）填充的插槽。每個可以有兩個組合。如果我們有七個點，則我們有2 * 2 * 2 * 2 * 2 * 2 * 2 = 2 ^ 7 = 128個組合?？梢詫⑵湎胂鬄榫哂衅邆€輪子的密碼鎖，每個輪子只有兩個數字。

資料來源：Wikipedia，這篇很棒的博客文章和Mocki，我最初在其中發布了此摘要。

ASCII具有128個代碼點，從0到127。它可以容納在單個8位字節中，值128到255傾向于用于其他字符。選擇不兼容會導致代碼頁災難。假定或猜測另一代碼頁的程序無法正確讀取在一個代碼頁中編碼的文本。

Unicode來解決這一災難。第1版以65536個代碼點開始，通常以16位編碼。后來在版本2中擴展到110萬個代碼點。當前版本是6.3，使用了110187個可用代碼點中的110,187個。這不再適合16位。

v2出現時，通常采用16位編碼，例如Microsoft和Apple操作系統使用的。還有像Java這樣的語言運行時。v2規范提出了一種將110萬個代碼點映射為16位的方法。一種稱為UTF-16的編碼，一種可變長度編碼，其中一個代碼點可以占用2或4個字節。原始的v1代碼點占用2個字節，添加的代碼點占用4個字節。

在* nix操作系統和工具中使用的另一種非常常見的可變長度編碼是UTF-8，一個代碼點可以占用1到4個字節，原始ASCII碼需要1個字節，其余的則更多。唯一的可變長度編碼是UTF-32，一個代碼點需要4個字節。不經常使用，因為它很浪費。還有其他一些字符，例如UTF-1和UTF-7，被廣泛忽略。

UTF-16 / 32編碼的問題是字節的順序將取決于創建文本流的計算機的字節順序。因此，將UTF-16BE，UTF-16LE，UTF-32BE和UTF-32LE添加到混合中。

擁有這些不同的編碼選擇會在某種程度上帶給代碼頁災難，以及程序員之間關于UTF選擇“最佳”的激烈爭論。它們與操作系統默認值的關聯幾乎可以劃清界限。一種對策是定義BOM，字節順序標記，在文本流開頭的特殊代碼點（U + FEFF，零寬度空間），指示如何對其余流進行編碼。它既指示UTF編碼又指示字節序，并且對于文本呈現引擎而言是中立的。不幸的是，它是可選的，許多程序員聲稱有權忽略它，因此事故仍然很常見。