跳至主要內容
Lizely

Base32 編碼 / 解碼

將 UTF-8 文字編碼為標準 RFC 4648 Base32,或將填充與未填充的 Base32 解碼回嚴格 UTF-8。

隱私權:你的檔案不會離開裝置,所有處理均在瀏覽器本機完成。

使用方式

  1. 1.選擇編碼用於 UTF-8 文字,或選擇解碼用於 RFC 4648 Base32 值。
  2. 2.貼上輸入並檢視產生的輸出或特定驗證錯誤。
  3. 3.複製輸出或交換方向以驗證完整迴圈。

關於Base32 編碼 / 解碼

Base32 編碼 / 解碼將 plain UTF-8 文字轉換為 RFC 4648 節 6 所定義的標準字母表。選擇編碼可將文字轉換為使用 A 到 Z 和數字 2 到 7 的大寫 Base32,或選擇解碼以從 Base32 值恢復文字。轉換過程完全在當前瀏覽器分頁中進行,不會上傳任何內容。

編碼首先將 JavaScript 字串轉換為 UTF-8 位元組,使用瀏覽器 TextEncoder。它將這些位元組視為五位元組串流,將每個組對映到 RFC 字母表,用零位元填滿最後的不完整組,並附加等號直到編碼長度為八的倍數。空輸入保持為空。這產生 RFC 測試向量中使用的標準填充形式。

解碼接受大寫或小寫字母,移除貼上的空白字元,並允許精確標準填充或無填充形式,前提是長度有效。它拒絕標點符號、超出 2 到 7 的數字、中間的等號、不可能的資料長度、錯誤的填充數量以及非零的未使用尾端位元。這些檢查防止錯誤的值被靜默地解釋為不同的位元組。

解碼後的位元組陣列會傳遞給致命 UTF-8 解碼器。如果位元組無效 UTF-8,工具會報告此限制,而不是用佔位符元字元取代無效序列。因此,這頁是文字轉換器,而非通用二進位檔案解碼器。二進位資料載入可能是有效的 Base32,但對於此文字輸出仍可能無效。

七個官方 RFC 測試向量涵蓋空字串以及逐步輸入 f, fo, foo, foob, fooba, 和 foobar。字母表錨點另外驗證索引 0、25、26 和 31 分別對應 A、Z、2 和 7。額外測試涵蓋小寫輸入、插入的空白字元、多語言 UTF-8、表情符號、無效填充以及非標準尾端位元。

交換方向控制會將成功的輸出移至對應的輸入,使編碼後再解碼的過程容易檢視。複製輸出僅在使用者選擇後才會使用瀏覽器剪貼簿。剪貼簿被拒絕時,不會改變轉換結果。結果來自當前輸入與模式,因此舊的輸出無法與更新的文字繫結。

Base32 會增加大小,因為每個編碼的字元代表 5 個輸入位元組,且在任何補碼前皆如此。這是一種編碼方式,而非加密、雜湊、簽名或壓縮。任何人擁有這段文字都可以解碼,且它不提供任何保密性、真實性、完整性保護或密碼儲存功能。請勿將編碼的秘密視為受保護。

空白字元的容忍度僅限於解碼的便利性。移除的換行與空格並非解碼資料的一部分,而原始文字中的空白字元會被保留,因為它們被編碼為 UTF-8 位元組。編碼的大小寫字母被視為相同,但編碼器總是輸出大寫標準結果。補碼會明確顯示,讓使用者可以與協議範例與標準函式庫實作比較。

此實現故意僅支援 RFC 4648 Base32 標準。它不實作 Base32hex、Crockford Base32、z-base-32、TOTP 秘密配置規則、零與一的大小寫數字、任意字母表、串流檔案或校驗和變體。若需要其他字母表或安全規則,請使用專屬協議的實現。

方法與來源

將 UTF-8 位元組轉換為五位元 RFC 4648 字元集索引,最後一組補零,並在八的倍數上加入標準等號補碼。解碼前需先進行大小寫統一與空白字元移除;驗證字元集、長度、補碼以及末尾零位元;重新組合位元組;之後使用致命錯誤 UTF-8 解碼。驗證七個已發表的 RFC 文字向量、字元集錨點以及錯誤輸入案例。

常見問題

Base32 是加密嗎?
不是。這是一種可逆的二進位至文字編碼,沒有保密性或完整性保護。
我可以解碼小寫或未補碼的輸入嗎?
可以。小寫會被標準化,貼上的空白字元會被忽略,且結構上有效的未補碼輸入會被接受。
為何有效的 Base32 會作為文字失敗?
解碼後的位元組可能是二進位而非有效的 UTF-8,此專注工具僅輸出嚴格的 UTF-8 文字。
文字會離開我的瀏覽器嗎?
編號 UTF-8 的轉換、位元群組、驗證以及剪貼簿準備動作皆在本機執行。

編碼與加密 使用指南

查看全部