base32/

Base32 把每 5 個位元組寫成 8 個字元，字元表只有 32 個（標準寫法是 A-Z 和 2-7），所以長度比原文多約 60%，Base64 只多約三分之一。好處是不分大小寫，也沒有數字 0、1、8、9，不容易和字母 O、I、B 搞混，適合手抄、口述和不區分大小寫的場合，例如 2FA 金鑰和檔名。

平常遇到的 Base32，包括 2FA 金鑰和大多數編碼函式庫的預設輸出，都是標準變體（RFC 4648 第 6 節，字母表 A-Z、2-7）。Base32Hex（第 7 節，字母表 0-9、A-V）的特點是編碼後的排序和原始位元組的排序一致，用在 DNSSEC 的 NSEC3 這類需要排序的地方。兩者無法互相解碼：選錯時常會出現「不是 Base32 字元」的錯誤，也可能解出一堆亂碼。

是。TOTP 的 secret（QR Code 裡 otpauth:// 連結的 secret 參數，或手動輸入的金鑰）一般是標準 Base32，通常是大寫、不帶 =，有的會以每 4 個字元一組、中間加空白的方式顯示，這裡解碼時都能辨識。解出來的是隨機位元組而不是文字，要勾選「結果顯示為 hex」才看得到，例如 JBSWY3DPEHPK3PXP 是 48 65 6c 6c 6f 21 de ad be ef。要產生動態驗證碼，請使用本站的 2FA 工具。

「長度不合法」是指去掉 = 之後，字元數除以 8 的餘數是 1、3 或 6，合法的 Base32 只會是 0、2、4、5、7，多半是複製時少了字元。「不是 Base32 字元」會指出是第幾個字元：標準變體裡沒有 0、1、8、9，也沒有標點符號和全形字元；如果內容裡有 0-9 和 A-V，可能是 Base32Hex，請切換變體。「= 只能出現在結尾」表示 = 後面還有內容，可能是幾段串在一起了，需要分開解碼。空白、換行、小寫字母和缺少的 = 都不會出錯。

= 用來把長度補到 8 的倍數，不屬於資料。解碼時有沒有都可以；編碼時「補齊 =」預設是勾選的，不需要就取消勾選。能不能省略要看接收方：Google Authenticator 的 otpauth 連結格式說明 secret 不需要補齊，通常會省略；Python 的 base64.b32decode 則要求一定要補齊，少了會出現 Incorrect padding。

表示解出的位元組不是 UTF-8 文字。2FA 金鑰、雜湊值、加密資料本來就是二進位資料，勾選「結果顯示為 hex」可以看到原始位元組。本工具只依 UTF-8 顯示文字，原文如果使用 GBK 等其他編碼，請先勾選 hex，再到本站的文字 / 十六進位工具選 GBK，把位元組轉回文字。

請先檢查三點：輸入結尾是不是多了換行或空白，本工具依 UTF-8 原樣編碼，不會去掉頭尾的空白；變體是否一致，Python 裡標準寫法是 base64.b32encode，Base32Hex 是 base64.b32hexencode（3.10 起提供）；有沒有補齊 =。Crockford、z-base-32 這類使用其他字母表的變體不在支援範圍內，結果不會相同。

不會。編碼和解碼都在瀏覽器裡完成，不會發出任何請求，也不會儲存，2FA 金鑰不會離開你的瀏覽器。