Base32 編碼解碼

一般文字會先按 UTF-8 編碼，再轉換成 Base32。
0 輸入字元

在線完成 Base32 編碼、解碼與檔案轉換，支援 4 種變體、padding 處理、Hex 檢視與本地下載，適合 TOTP 金鑰、可讀 ID 與二進位除錯情境。

相關推薦

Base58 編碼解碼

Base64 編碼

URL Safe Base64

十六進位轉換

檔案轉 Base64

Base64 解碼

什麼是 Base32？

Base32 是把二進位資料映射為 32 個可列印字元的編碼方案。標準版來自 RFC 4648，預設字元表是 A-Z 與 2-7，每 5 bit 資料對應 1 個輸出字元，因此結果通常比原始位元組大約多 60%。

Base32 的優勢不是最精簡，而是更適合不分大小寫、人工抄錄，或需要避免 + / 等特殊字元的情境。TOTP 金鑰、某些 DNS / 設定值、人工校驗碼與可讀 ID 都常見 Base32。

不同變體會改變字元表與容錯規則。本頁同時支援 RFC 4648 標準 Base32、Base32hex、Crockford Base32 與 z-base-32，並提供嚴格校驗、padding 開關、換行輸出、文字 / 檔案互轉與十六進位檢視，方便你在不同協定與工具鏈中直接驗證結果。

適用場景

  • 檢查 TOTP / OTP 金鑰是否為標準 Base32，或需要改寫成 Crockford、z-base-32 等更易讀形式時使用。
  • 把二進位設定、憑證片段、離線啟用碼或資源指紋轉為不含特殊符號的可讀字串時使用。
  • 排查第三方系統回傳的 Base32 字串是否缺少 padding、混用了錯誤變體，或需要嚴格驗證長度時使用。
  • 收到一段 Base32 內容但不確定是文字還是檔案時，可先解碼查看 UTF-8 / Hex，再決定是否下載原始二進位。

使用方法

  1. 先選擇要處理的變體：如果對方文件明確寫 RFC 4648、Base32hex、Crockford 或 z-base-32，就按照同一種變體操作。
  2. 編碼時選擇「文字」或「檔案」輸入，再按需求決定是否輸出 padding、是否轉小寫，以及是否按 64 / 76 字元換行。
  3. 解碼時貼上 Base32 字串；如果需要更嚴謹的結果，開啟嚴格校驗來檢查長度與 padding 是否符合規則。
  4. 查看輸出結果：文字內容可直接複製，非文字內容可切到 Hex，或下載還原後的檔案繼續排查。

功能特點

  • 4 種 Base32 變體同頁切換：RFC 4648、Base32hex、Crockford、z-base-32。
  • 文字與檔案雙模式：可把 UTF-8 文字編碼為 Base32，也可把任意檔案轉成 Base32 字串。
  • 解碼結果可直接查看 UTF-8 文字、Hex，或下載還原後的二進位檔案。
  • 支援 padding、大小寫與換行控制：可依 RFC 風格每行 64 / 76 字元輸出，也能自訂寬度。
  • 嚴格校驗與本地處理並存：需要時可檢查長度與 padding，所有編解碼過程都在瀏覽器內完成。

該用 Base32、Base64 還是 Base58？

這幾種編碼都能把二進位轉成可列印字元，但適合的任務不一樣。先看你更在意相容性、字元安全還是輸出長度。

格式更適合取捨
Base32TOTP 金鑰、可讀 ID、不分大小寫的環境字元集更安全、較適合人工抄錄，但輸出比 Base64 更長。
Base64通用文字 / 檔案傳輸、Data URL、API 載荷結果更緊湊，但可能出現 + / = 等特殊字元；URL 或檔名情境常要換成 URL-safe 變體。Base64 編碼Base64 URL Safe
Base58人工抄寫地址、QR 字串、區塊鏈地址不含 0/O/I/l，更適合防混淆，但不是 RFC 4648 體系，不能取代 TOTP / 標準協定中的 Base32。Base58 編碼解碼

最佳实践

先確認對方要求的是哪一種變體

Base32 問題最常見的坑不是演算法，而是標準不一致。對方若要求 Base32hex、Crockford 或 z-base-32，必須按對應字元表處理，否則結果看似合理，實際卻無法被對方系統接受。

除錯失敗時先切到 Hex 再判斷是不是文字問題

Base32 解碼後的原始位元組不一定是 UTF-8 文字。先看 Hex，能更快分辨它到底是憑證、圖片頭、壓縮包、隨機金鑰還是純文字。

需要人工輸入的字串優先考慮 Crockford 或 z-base-32

如果重點是降低人工輸入錯誤，而不是嚴格對接 RFC 4648，Crockford 與 z-base-32 會比標準 Base32 更友善，能減少 O/0、I/1 這類誤讀。

要串接郵件、API 或檔案工具時別只盯著 Base32

很多實際任務的下一步不是繼續 Base32，而是轉成 Base64、Hex 或直接下載原檔繼續處理。依任務鏈切換到更適合的格式，通常比硬把所有流程都塞進 Base32 更省事。

Base64 編碼Hex 轉換

常見問題

Base32 和 Base64 該怎麼選？

想要更短、更常見的傳輸格式時，優先用 Base64；想降低特殊字元、相容不分大小寫的環境，或處理 TOTP 金鑰、人工抄錄字串時，更適合 Base32。Base32 結果會更長，但字元集更克制。

RFC 4648、Base32hex、Crockford、z-base-32 有什麼差別？

核心差異在字元表與容錯策略。RFC 4648 是通用標準；Base32hex 以數字排序為主；Crockford 適合人工輸入，會容忍 O/0、I/1、L/1；z-base-32 預設小寫，常用於更重視可讀性的短字串。編碼與解碼必須使用同一變體。

為什麼有些 Base32 字串會帶 =，有些沒有？

RFC 4648 與 Base32hex 常使用 = padding 來補齊長度；Crockford 與 z-base-32 通常不帶 padding。本頁編碼時可控制是否輸出 =，解碼時也能在寬鬆模式下處理缺少 padding 的字串。

解碼後出現亂碼怎麼辦？

這通常不是 Base32 演算法錯誤，而是原始內容不是 UTF-8 文字，例如圖片、憑證、壓縮包或任意二進位資料。此時請切換到 Hex 檢視，或直接下載還原後的檔案。

支援檔案 Base32 編碼與檔案還原嗎？

支援。編碼模式下可上傳任意檔案並生成 Base32；解碼模式下可把 Base32 還原為二進位並下載。對憑證、設定包、圖片與金鑰材料都很實用。

上傳的文字或檔案會送到伺服器嗎？

不會。當前頁面的 Base32 編解碼、Hex 檢視與檔案下載都在瀏覽器本地完成，內容不會上傳到遠端伺服器。

故障排查

明明可以解碼，為什麼和第三方結果對不上？

先檢查是否選錯了變體。標準 Base32、Base32hex、Crockford 與 z-base-32 的字元表不同，就算只差幾個字元，整體結果也會完全不一樣。

開啟嚴格校驗後報長度錯誤怎麼辦？

通常代表輸入缺少 padding、混入錯誤字元，或根本不是該變體生成的 Base32。可以先關閉嚴格模式確認大致內容，再回頭修正來源字串。

為什麼解碼後得到空白或亂碼文字？

原始資料可能不是 UTF-8 文字，而是二進位檔案或隨機位元組。請切換到 Hex 模式，或直接下載解碼後的二進位檔案繼續分析。

術語表

RFC 4648 Base32
最常見的標準 Base32 變體，字元表為 A-Z 與 2-7，可帶 = padding。
Base32hex
RFC 4648 定義的十六進位排序變體，字元表為 0-9 與 A-V，便於依數值順序比較。
Crockford Base32
強調人工可讀性與容錯的變體，去掉 I、L、O、U，並把 O/0、I/1、L/1 視為等價。
z-base-32
偏向人工輸入與短字串傳輸的變體，預設小寫，通常不使用 = padding。
padding
標準 Base32 末尾用來補齊長度的 = 字元。RFC 4648 與 Base32hex 常見，Crockford 與 z-base-32 一般不用。

4 種 Base32 變體速查

如果你不確定該選哪個變體，先看字元表與典型用途。

變體字元表是否常用 =典型情境
RFC 4648A-Z + 2-7常用TOTP / 標準 Base32 相容
Base32hex0-9 + A-V常用依數值順序比較或特定協定欄位
Crockford0-9 + A-Z（去 I/L/O/U）通常不用人工輸入、短碼、容錯校驗
z-base-32ybndrfg8ejkmcpqxot1uwisza345h769通常不用更重視可讀性的短字串

標準 Base32 長度與 padding 關係

RFC 4648 / Base32hex 編碼時，末尾 = 的數量取決於原始位元組長度。

原始位元組數有效 Base32 字元需要補的 =
126
244
353
471
580

Authoritative References