Base32 解碼是一種可逆的文字編碼方式，它將一個 32 個符號的字母表——大寫字母 A 到 Z 加上數字 2 到 7——轉換回原先組成位元組的五位元群組；你所需要的速查表記錄了字母位置、八個字元對應五個位元組的比例、將不完整群組轉為有效輸出時的填補規則，以及能夠阻止格式錯誤的值被默默接受的精準驗證錯誤。RFC 4648 第 6 節定義了每個標準實作所用的正式字母表與等號填補，因此一份實用的速查表會將每個字母對應到它的十進位索引，列出特定輸入長度需要多少個等號，並標記常見錯誤（例如字串中間出現等號、填補數量錯誤，或未使用的尾端位元不為零）。這個頁面提供你那份參考資料：完整的字母表、長度與填補的對應關係、三步驟解碼流程、你可以預期的失敗訊息，以及一段簡短的實作範例，帶你走過 RFC 公布的測試向量，並說明為何每個解碼後的字串都能乾淨復原或通過驗證器。請將此頁加入書籤，以便在解碼 TOTP 密鑰、授權金鑰，或任何以 ASCII 中 32 個符號子集送達的文字時能快速查閱。
Base32 字母表一覽
你所遇到的每個 Base32 字串都取自 RFC 4648 第 6 節定義的同一個 32 個符號的表格。只要牢記它，就能一眼消除一整類的解碼錯誤：
| 索引 | 字元 | 索引 | 字元 | 索引 | 字元 | 索引 | 字元 |
|---|---|---|---|---|---|---|---|
| 0 | A | 8 | I | 16 | Q | 24 | Y |
| 1 | B | 9 | J | 17 | R | 25 | Z |
| 2 | C | 10 | K | 18 | S | 26 | 2 |
| 3 | D | 11 | L | 19 | T | 27 | 3 |
| 4 | E | 12 | M | 20 | U | 28 | 4 |
| 5 | F | 13 | N | 21 | V | 29 | 5 |
| 6 | G | 14 | O | 22 | W | 30 | 6 |
| 7 | H | 15 | P | 23 | X | 31 | 7 |
六個錨點掌握了大部分的診斷價值：0 → A、7 → H、17 → R、25 → Z、26 → 2、31 → 7。字母表刻意從 Z 跳到 2 而非繼續編列 0 與 1，因為人眼很容易混淆 0/O 與 1/I——這個跳躍正是 Base32 速查表必須查閱而非憑記憶的原因。解碼器在查找前會將小寫字母標準化為大寫，因此以小寫輸入的字串解碼結果完全相同；然而編碼器一律輸出大寫的正式結果，所以你的參考值在各種工具之間會保持一致。
如何以三個步驟解碼 Base32
RFC 4648 實作的解碼端遵循三個具體步驟。請開啟 Base32 編碼／解碼 工具，然後：
- 為一個 RFC 4648 Base32 值選擇解碼（取消勾選編碼）。
- 將 Base32 字串貼入輸入區，並讀取還原後的 UTF-8 文字或特定的驗證錯誤。
- 複製輸出，或使用「交換」將它送回輸入區，確認編碼能重現原始字串。
整個轉換程序都在當前的瀏覽器分頁中執行。UTF-8 轉換、位元分組、驗證以及剪貼簿準備皆在本地完成，不會上傳任何資料——當承載的內容是你不想分享給伺服器的私密密鑰時，這點特別有用。舊的輸出無法繼續附加於較新的文字之後：每次結果都是根據當下的輸入與當下的模式重新產生，而剪貼簿拒絕絕不會改變轉換結果。
你必須檢查的填補與長度規則
Base32 之所以會擴增資料，是因為八個編碼字元永遠正好代表五個輸入位元組——這是在加上任何填補之前的情況。輸出長度會以等號進位至八的倍數，因此所需的等號數量僅取決於輸入位元組數量除以五的餘數：
- 0 個位元組 → 輸出為空，不填補。
- 1 個位元組 → 輸出為 8 個字元，其中 6 個為等號。
- 2 個位元組 → 輸出為 8 個字元，4 個等號。
- 3 個位元組 → 輸出為 8 個字元，3 個等號。
- 4 個位元組 → 輸出為 8 個字元，1 個等號。
- 5 個位元組 → 輸出為 8 個字元，完全不填補。
快速的解碼檢查可以反向套用此規則：計算尾端的等號數量、查出對應的位元組數量，並驗證資料部分的長度是否相符。另外兩條規則同樣重要。最後一個不完整群組內的尾端位元必須為零，且等號只能出現在字串的最末端。字串中間的填補、錯誤的填補數量，或尾端位元不為零，這些情況都會觸發特定的驗證錯誤，而非默默將不同位元組解讀出來——這正是當輸入來自不可靠來源時你所需要的行為。
常見的解碼錯誤及其意義
當 Base32 字串無法解碼時，一個專注的工具會顯示具名的原因，而非單一籠統的失敗訊息。認得這些措辭能加速除錯，因為每個錯誤都指向一個明確的疏失：
- 無效字元：標點符號、超出 2 到 7 範圍的數字，或夾雜的 0 或 1 溜過了驗證器。允許的字母表僅限大寫 A–Z 與數字 2–7——別無其他。
- 等號不在結尾：等號出現在最後一個位置之前。等號只能作為填補出現在字串的最尾端。
- 填補數量錯誤：尾端等號的數量與位元組長度所需的數量不符。上方的填補表能告訴你正確的數量。
- 無效資料長度：未填補字串長度 mod 8 的結果無法對應任何位元組對齊的解讀——例如六個字元永遠不可能是有效的 Base32 長度。
- 未使用的位元不為零：最後一個不完整群組中，在解碼器本應忽略的位置仍有具意義的位元。這代表輸入並非由正式編碼產生，應使用標準字母表重新產生。
請將這些訊息視為「動手修」的訊號，而非「動腦猜」的訊號：使用相同的字母表重新產生編碼後的字串，而非手工修正它，因為差一個字元的手工修正就可能改變多個輸出位元組。
有效字串卻解碼失敗的情況
Base32 是一種二進位轉文字的編碼，因此一個字串語法上完全正確，卻仍可能無法產生可讀的文字。解碼後的位元組可能代表任意的二進位內容——影像片段、加密金鑰、壓縮片段——而它們根本不是有效的 UTF-8。一個專注的文字解碼器會明確回報這項限制，而非以替換字元（例如 Unicode 問號）取代無效的位元組序列。如果你需要的是位元組本身而非文字，就必須使用支援二進位的解碼器，並檢視原始位元組串流。
七個官方 RFC 測試向量涵蓋了從零到五個位元組的所有填補情境，這讓專注的解碼器有東西可以驗證，也讓你有一份測試清單可以測試自己的程式碼：
- 空輸入保持為空。
- f 編碼為 MY======（1 個位元組，6 個等號）。
- fo 編碼為 MZXQ====（2 個位元組，4 個等號）。
- foo 編碼為 MZXW6===（3 個位元組，3 個等號）。
- foob 編碼為 MZXW6YQ=（4 個位元組，1 個等號）。
- fooba 編碼為 MZXW6YTB（5 個位元組，無填補）。
- foobar 編碼為 MZXW6YTBOI======（6 個位元組，第二個區塊中有 6 個等號）。
每一列都遵循上述填補規則，且每個編碼後的字串在貼回同一個工具再走一次解碼時都能乾淨往返。解碼後，點擊「交換」然後對還原後的文字點「編碼」——一個乾淨的往返會逐字重現原始字串，這是在本地端最強的驗證，證明你的解碼器符合公開規格。
本速查表的限制
本參考資料僅涵蓋 RFC 4648 Base32。它並未實作 Base32hex（0–9 A–V 字母表）、Crockford Base32（折疊視覺上易混淆的字母）、z-base-32（加入小型校驗和）、TOTP 金鑰佈建規則、區分大小寫的數字 0 與 1、任意字母表、串流檔案，或任何校驗和變體。當編碼伴隨校驗和後綴或非標準字母表出現時，請改用該協定專屬的實作：通用解碼器無法僅從字母表判斷出它收到的是哪個變體。一個能一鍵還原的有用配套，是將 Base32 字串一鍵解碼回可讀文字的指南，它採取更偏工具優先的方式處理同一項任務。
本頁所使用的字母表位置、填補規則以及測試向量，皆遵循 RFC 4648 規格第 6 節，因此任何宣稱符合 RFC 的標準函式庫都應該與上方每個錨點及測試案例一致——包括位於索引 0、25、26、與 31 的字母錨點，分別對應 A、Z、2 與 7。最後一個值得寫在頁面上的提醒：Base32 是一種編碼，而非加密、雜湊、簽章或壓縮。任何持有該編碼字串的人都能還原原始位元組，其中並未涉及任何金鑰、密鑰或完整性檢查。永遠不要把一個編碼後的值視為受到保護——如果你需要保密性，你需要的是真正的加密器（例如 AES-GCM），而非更長的字母表。
如果你正在權衡各種選項，Base64 解碼入門：白話指南詳細介紹了這項內容。