字符編碼課是一門 14 關的交互式教程，回答開發中反覆出現卻很少有人説清的幾個問題：一個漢字到底佔幾個字節？為什麼 "😀".length 是 2？Base64 末尾的 = 是幹什麼的？亂碼是文件壞了還是能救？每一關給你一段試驗文本（可以隨意改）和幾個視圖——每個字符的位、字節、Unicode 碼位、UTF-8 逐字節拆解、Base64 的 6 位分組、URL 百分號編碼、以及「按別的編碼解讀會看到什麼」——目標是讀出某個數、寫出某串十六進制、或者輸入一個滿足條件的字符，判定器即時打勾。

課程順序就是編碼史的順序：位與字節 → ASCII 的 128 個約定 → Unicode 給每個字符編號 → UTF-8 怎樣把編號變成 1 到 4 個字節 → UTF-16 與 JavaScript 字符串長度 → Base64 把字節搬進純文本 → URL 編碼 → 最後兩關專講亂碼：它怎樣產生、怎樣從 浣犲ソ 反推出 你好。

約 40 分鐘學完。面向前後端開發者、數據處理者，以及任何被亂碼、Base64、emoji 長度困擾過的人；只需要會數二進制。

1. 01看目標與試驗文本每關頂部是目標；試驗文本框裏預填了本關的樣本，你可以改成任何內容，所有視圖立即重算。
2. 02讀視圖本關相關的視圖會展開——「位」視圖逐字符顯示 8 位一組；「碼位」視圖列出 U+ 編號與 UTF-16 碼元；「UTF-8 拆解」把每個字節分成前綴位與載荷位並着色；「Base64 分組」按 3 字節 → 4 字符排布；「URL 編碼」標出哪些字符被轉成 %XX；「按其它編碼解讀」顯示同一串字節被當作 GBK、Latin-1、UTF-16 時的樣子。
3. 03作答多數關卡在答案框裏填數字、十六進制或字符串；少數關卡要求你把試驗文本本身改成滿足條件的內容（例如「恰好一個 3 字節字符」）；一關是選擇題。
4. 04判定結果條即時顯示通過或差在哪；十六進制答案不區分大小寫與空格。
5. 05提示、答案與進度「提示」給思路，「看答案」顯示參考答案並可填入；進度存在本機瀏覽器，?lesson=n 可直達某關。

第 6 關「UTF-8 兩字節」以 café 為樣本，要求寫出 é 的兩個字節：

第 14 關「反推亂碼」給出被當作 GBK 解讀的亂碼 浣犲ソ，要你在試驗文本里找出原文：

字符   碼位      二進制碼位          UTF-8 模板              字節
c      U+0063    1100011             0xxxxxxx                63
a      U+0061    1100001             0xxxxxxx                61
f      U+0066    1100110             0xxxxxxx                66
é      U+00E9    000 1110 1001       110xxxxx 10xxxxxx       C3 A9
                 → 11 位載荷 00011 101001 填進模板 → 11000011 10101001
答案   C3 A9   ✓

試驗文本   中文      UTF-8 字節  E4 B8 AD E6 96 87    按 GBK 讀 → 涓枃
試驗文本   你好      UTF-8 字節  E4 BD A0 E5 A5 BD    按 GBK 讀 → 浣犲ソ   ← 與題目一致
答案       你好   ✓

第 1 關：位與字節

計算機只有 0 和 1。一個位（bit）是一個開關；8 個位組成一個字節（byte），能表示 $2^8 = 256$ 個不同的值。按位權求和把二進制變成十進制：01000001 = 64 + 1 = 65。所有文字最終都是一串字節，「字符編碼」就是一張表，規定哪個數代表哪個字符——不同的表，就是不同的編碼。

第 2–3 關：ASCII

1963 年的 ASCII 用 7 位定義 128 個字符：0–31 是換行、製表、響鈴這類控制字符，48–57 是數字 0–9，65–90 是大寫字母，97–122 是小寫字母。表不是隨意排的：大小寫只差 32（二進制第 6 位），所以 c | 0x20 把大寫變小寫；數字字符減 48 就是數值。十六進制是讀字節的慣用寫法，兩位正好一個字節：0x48 0x69 = Hi。ASCII 只用了 7 位，第 8 位空着——後來各國各自填充這一位（Latin-1、GBK、Shift_JIS……），互不兼容，這正是亂碼的歷史根源。

第 4 關：Unicode 碼位

Unicode 給全世界的字符統一編號，叫碼位（code point），寫成 U+ 加十六進制：A 是 U+0041，中 是 U+4E2D，😀 是 U+1F600。空間從 U+0000 到 U+10FFFF，分成 17 個「平面」，常用字符幾乎都在第 0 個基本平面（U+0000–U+FFFF），emoji 與生僻漢字在補充平面。關鍵的一點：碼位只是編號，它變成字節的方式由 UTF-8、UTF-16、UTF-32 這些「編碼形式」決定。「Unicode」不是一種編碼，utf-8 才是。

第 5–8 關：UTF-8 的變長模板

UTF-8（RFC 3629）用 1–4 個字節表示一個碼位，規則全部寫在首字節的前綴裏：

把碼位的二進制左側補零到載荷位數，依次填進 x，就得到字節。é = U+00E9 = 11101001，補到 11 位是 00011 101001，填入兩字節模板得到 11000011 10101001 = C3 A9。

這套設計有三個好處：ASCII 文本按 UTF-8 編碼後一個字節都不變（完全向下兼容）；任何後續字節都以 10 開頭，從字節流中間任意位置都能找到下一個字符的起點（自同步，丟一個字節不會讓整段錯位）；不同長度的編碼互不重疊，00 這樣的零字節永遠只代表 U+0000（C 字符串安全）。代價是中文每字 3 字節，比 GBK 的 2 字節多 50%；但英文、標點、代碼不受影響，因此 UTF-8 成為超過 98% 網頁的編碼。

第 7、8 關讓你親手輸入一個 3 字節字符與一個 4 字節字符。後者揭示一個至今常見的坑：MySQL 的 utf8 字符集其實只支持到 3 字節，存 emoji 會報錯或截斷，必須用 utf8mb4。

第 9 關：UTF-16 與 .length

JavaScript、Java、C#、Windows API 的字符串內部用 UTF-16：每個碼元（code unit）16 位。基本平面的字符佔一個碼元；補充平面的碼位拆成兩個碼元，叫代理對（surrogate pair），範圍 D800–DBFF 與 DC00–DFFF。所以 "😀".length === 2，"😀".split("") 會切成兩個無意義的半個，str[0] 拿到的是高位代理。要按真實字符數計數，用 [...str].length（按碼位迭代）；要按用户感知的「一個字」計數（含組合 emoji、變音符），用 Intl.Segmenter。

第 10–11 關：Base64

Base64（RFC 4648）不是加密，是把任意字節變成 64 個可打印 ASCII 字符（A–Z a–z 0–9 + /）的搬運方式，為的是把二進制塞進只接受文本的地方：郵件附件、JSON 字段、data: URL、JWT。做法是每 3 個字節 = 24 位，切成 4 段 6 位（$2^6 = 64$），每段查表得一個字符：Man = 4D 61 6E = 01001101 01100001 01101110 → 010011 010110 000101 101110 → T W F u。體積因此膨脹到原來的 4/3。

字節數不是 3 的倍數時最後一組不滿：缺 1 個字節補一個 =，缺 2 個補兩個 =，保證輸出長度總是 4 的倍數。A 一個字節 8 位補零到 12 位，切成 010000 01(0000) → QQ，再加 ==。URL-safe 變體把 + / 換成 - _（避免在 URL 中被轉義），並常省略 =，解碼時按長度補回。

第 12 關：URL 百分號編碼

URL 裏只有一小部分 ASCII 字符可以原樣出現（RFC 3986 §2）。空格、&、=、?、/ 這類有語法含義的保留字符，以及全部非 ASCII 字符，都要寫成 % + 字節的十六進制。所以 URL 編碼是先 UTF-8，再逐字節加 %：中 → E4 B8 AD → %E4%B8%AD，一個漢字變 9 個字符。JavaScript 裏 encodeURIComponent 編碼最徹底（連 / ? & = 都編），適合放進參數值；encodeURI 保留結構字符，適合整條地址。表單提交的 application/x-www-form-urlencoded 還會把空格寫成 +——這是 HTML 表單的歷史約定，不是 RFC 3986 的一部分。

第 13–14 關：亂碼從哪來，怎麼救

亂碼不是數據損壞，而是寫的時候用編碼 A、讀的時候用編碼 B。UTF-8 的 中 是 E4 B8 AD：

• 按 Windows-1252 / Latin-1（一字節一字符）讀：三個字節變成 中 三個西歐字母——帶變音符的字母串是「UTF-8 被當西歐編碼讀」的標誌。
• 按 GBK（兩字節一漢字）讀：E4 B8 是一個漢字 涓，剩下 AD 只有半個——「怪漢字 + 半個字」是「UTF-8 被當 GBK 讀」的標誌，浣犲ソ、涓枃 都是這一類。
• 反過來 GBK 文本被當 UTF-8 讀，遇到不合法的字節序列會大量出現替換字符 �（U+FFFD）。

只要原始字節沒丟，用正確的編碼重新解讀，文字就完好如初。因此修復亂碼的第一原則是保留原文件、不要反覆轉換：每轉一次都可能把不合法字節替換成 ? 或 �，那才是真正的信息丟失。第 14 關要你做一次逆向：把亂碼 浣犲ソ 按 GBK 變回字節 E4 BD A0 E5 A5 BD，再按 UTF-8 讀出 你好。現代做法是在 HTTP 頭、HTML <meta charset>、數據庫連接、文件保存對話框裏統一聲明 UTF-8，讓錯配沒有機會發生。

BOM 與字節序

UTF-16 有大端 / 小端兩種字節順序，文件開頭常放一個字節順序標記 BOM（FE FF 或 FF FE）。UTF-8 沒有字節序問題，但 Windows 記事本曾默認寫入 UTF-8 BOM EF BB BF，導致 shell 腳本第一行報錯、CSV 首列名前多出不可見字符。課程的 UTF-8 拆解視圖裏若看到這三個字節開頭，就知道來源。

編碼

詳細講 ASCII、UTF-8、UTF-16、Base64、URL 編碼；GBK 與 Windows-1252 只用於亂碼演示，依賴瀏覽器的 TextDecoder，不講 GB18030、Big5、Shift_JIS 的內部結構。

Unicode 進階

不講規範化（NFC/NFD）、組合字符序列、雙向文本、字素簇邊界算法；emoji 的膚色修飾與 ZWJ 組合只在提示中提及。

Base64

只講標準與 URL-safe 兩種字母表；不講 Base32、Base16、MIME 每 76 字符換行的規則。

判定方式

十六進制答案不區分大小寫與空格；「輸入字符」類關卡按 UTF-8 字節數與字符數判定，允許任何滿足條件的字符。

不做什麼

不是批量轉碼工具（處理真實數據請用「Base64 編解碼」「URL 工具」）、不檢測文件編碼、不修復上傳的文件。

• 「Unicode 是一種編碼」：Unicode 是字符集（編號表），UTF-8 / UTF-16 才是編碼。「保存為 Unicode」在 Windows 記事本里其實是 UTF-16 LE。
• 「一個漢字 2 字節」：GBK 裏是 2，UTF-8 裏是 3，UTF-16 裏基本平面是 2 而擴展 B 區的生僻字是 4。先問「哪種編碼」。
• 「Base64 是加密」：任何人都能解碼，它只是換一種表示；要保密請用真正的加密。
• 「亂碼了就是文件壞了」：絕大多數亂碼只是解讀方式錯了，換編碼重新打開即可；反覆「轉換」才會真的丟字。
• 「length 就是字符數」：在 JavaScript 裏是 UTF-16 碼元數，emoji 與部分生僻字算 2；數據庫 VARCHAR(n) 的 n 在不同數據庫裏可能是字節數也可能是字符數。
• 「URL 裏的中文直接寫就行」：瀏覽器地址欄會替你編碼顯示，但拼接請求時必須用 encodeURIComponent，否則 &、#、空格會破壞結構。

課程全部在瀏覽器本地運行：試驗文本的編碼、解碼、Base64 與 URL 編碼都由頁面內的 TextEncoder / TextDecoder 與純函數完成，不發送到任何服務器；通關進度存在本機 localStorage。

• F. Yergeau，RFC 3629，UTF-8, a transformation format of ISO 10646（2003）——四種字節模板、自同步性與合法序列的定義，課程第 5–8 關的依據：https://www.rfc-editor.org/rfc/rfc3629（访问日期：2026-09-09）
• S. Josefsson，RFC 4648，The Base16, Base32, and Base64 Data Encodings（2006）——Base64 字母表、填充規則與 URL-safe 變體，§10 的測試向量被課程單元測試直接引用：https://www.rfc-editor.org/rfc/rfc4648（访问日期：2026-09-09）
• T. Berners-Lee 等，RFC 3986，Uniform Resource Identifier (URI): Generic Syntax，§2.1 Percent-Encoding 與 §2.2 保留字符：https://www.rfc-editor.org/rfc/rfc3986#section-2.1（访问日期：2026-09-09）
• The Unicode Consortium，The Unicode Standard，Core Specification，Chapter 2 General Structure（碼位、平面、編碼形式、代理對）：https://www.unicode.org/versions/latest/（访问日期：2026-09-09）
• WHATWG，Encoding Standard——瀏覽器 TextDecoder 支持的編碼及其解碼算法，課程亂碼演示所用 GBK / windows-1252 解碼器的規範：https://encoding.spec.whatwg.org/（访问日期：2026-09-09）
• Joel Spolsky，The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets（2003）——「沒有純文本這回事」的經典入門：https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/（访问日期：2026-09-09）