若要在 macOS 上解碼 Base32，請將 RFC 4648 值貼到瀏覽器式 Base32 Encode / Decode 工具中，並選擇 Decode 模式。當該值同時通過 Base32 驗證與文字解碼時，結果會顯示為嚴格的 UTF-8 文字；否則，頁面會回報特定的驗證錯誤。轉換完全在目前的瀏覽器分頁中進行，因此不會上傳貼上的值。
此工作流程適合代表文字的一般標準 Base32 字串。它不會讓轉換器變成通用的二進位檔案解碼器，也不支援替代的 Base32 字母表。Base32 也是一種編碼，而非加密，因此不應假設已解碼的密碼或機密內容曾受到保護。
在瀏覽器中解碼 macOS 上的 Base32
- 在 Mac 上開啟轉換器。 在您於 macOS 上使用的瀏覽器中載入 Base32 Encode / Decode 頁面。該頁面就是操作介面，因此此工作流程不需仰賴獨立的桌面應用程式。
- 選擇 Decode 模式。 若要將現有的 Base32 值轉回文字，正確方向是 Decode。只有在您從 UTF-8 文字開始並想建立新的 Base32 值時，才應選擇 Encode。
- 貼上值。 請保留原始字串，以便在其他地方調用與結果比較。字母可以維持原本的大小寫，貼上的空格或換行也會被忽略。不要移除有效的填補字元，也不要只為讓值看起來更整潔而變更字元。
- 檢視目前的輸出或錯誤。 有效的值會產生已解碼的 UTF-8 文字。格式錯誤的值會產生特定的驗證錯誤，而不是靜默替換後的結果。變更輸入前請先閱讀錯誤類別，因為每種拒絕原因都不盡相同。
- 複製已解碼的文字。 選取輸出後，使用 Copy output 控制項。只有在您選擇此動作時，它才會寫入瀏覽器剪貼簿；如果剪貼簿存取遭拒，轉換結果本身不會改變。
- 選擇性檢查相反方向。 成功轉換後，請選擇 Swap。成功的輸出會移至相反的輸入欄位，因此您可以重新編碼並比較標準形式，以確認轉換結果。
Mac 解碼器可接受的內容
支援的格式是 RFC 4648 第 6 節定義的標準字母表：A 到 Z 的字母，以及 2 到 7 的數字。編碼器會輸出大寫字母，而標準填補會使用等號，直到編碼後長度為 8 個字元的倍數。填補前，8 個 Base32 字元代表 5 個位元組，這就是編碼輸出大於原始位元組數的原因。
解碼以相反方向進行。它會正規化字母大小寫、移除貼上的空白、驗證字母表、長度、填補及未使用的尾端位元，然後重新建立位元組序列。該位元組序列必須是有效的 UTF-8，才能顯示為文字。官方測試向量之一是，foobar 會編碼為 MZXW6YTBOI======，而解碼該值會傳回 foobar。
| 貼上的情況 | macOS 上的解碼器行為 |
|---|---|
| 大寫或小寫的 RFC 4648 字母 | 接受；字母大小寫會正規化。 |
| 值中插入空格或換行 | 解碼前移除。 |
| 完全標準的填補 | 接受。 |
| 結構有效且未填補的值 | 長度有效時接受。 |
| 標點符號、2–7 以外的數字，或置中的等號 | 以格式錯誤拒絕。 |
| 錯誤的填補數量或不可能的資料長度 | 拒絕，而不會解碼成不同的位元組。 |
| 非零的未使用尾端位元 | 以非標準形式拒絕。 |
| 代表非 UTF-8 位元組的有效 Base32 | UTF-8 階段會回報已解碼的位元組不是有效文字。 |
空白容許範圍僅適用於 Base32 值的格式。插入 Base32 字元之間的空格或換行會被捨棄。相對地，被編碼文字中的普通空格屬於其 UTF-8 位元組的一部分，解碼後會保留。
Base32 值在 Mac 上仍可能失敗的原因
Base32 驗證與 UTF-8 驗證回答的是不同問題。一個值在結構上可能是完美的 Base32，但當解碼器嘗試以嚴格 UTF-8 顯示其位元組時仍會失敗。當通訊協定會編碼二進位金鑰、憑證、壓縮物件或其他非文字內容時，這項區別十分重要。
首先，解碼器會檢查 Base32 容器本身。標點符號不屬於標準字母表。數字 0、1、8 和 9 無效，而等號只有在結尾處作為正確填補時才允許使用。結構有效且未填補的字串會被接受，但不可能的長度、錯誤的填補數量或置中的等號則不會。尾端位元檢查要求未使用的位元必須為零，因此不會接受非標準拼寫。
其次，重新建立的位元組會經過嚴格 UTF-8 解碼器處理。無効的 UTF-8 會被回報，而不會以可見的替換字元取代。若您正在處理檔案或二進位物件，請使用能保留位元組的 Base32 解碼器，不要將所有內容都強制透過這個僅供文字使用的頁面。
以往返轉換驗證已解碼的值
成功解碼後，往返轉換很有用，因為它能確認文字可以依相同規則再次編碼。這不是簽章檢查：輸出相符表示轉換可逆，並不能顯示是誰提供原始值，或該值是否在傳輸過程中被變更。
- 從成功的 Decode 結果開始，並讓已解碼的文字保持可見。
- 選擇 Swap。只有成功的輸出才會移至相反的輸入欄位。
- 檢視 Encode 輸出，它使用大寫字母及標準等號填補。
- 將它與原始 Base32 值的標準形式比較。標準的大寫、已填補輸入應完全重現；小寫、空白或缺少有效填補，都可能使顯示的形式有所不同。
- 複製下一步所需的標準 Base32 文字。
結果會依據目前的輸入與模式產生，因此舊輸出不會一直附著在新貼上的文字上。這讓您可以在同一個分頁中比較原始值與交換後的值，不會把一個結果誤認為另一個結果。
何時需要其他 macOS Base32 工作流程
此轉換器刻意只支援標準 RFC 4648 Base32。它未實作 Base32hex、Crockford Base32、z-base-32、任意字母表、對零與一等數字進行的大小寫折疊替換，或校驗和變體。它也未實作 TOTP 機密配置規則。來自採用上述其中一種慣例的通訊協定之值，需要使用該通訊協定自己的實作。
這也是文字頁面，而非串流檔案轉換器。Base32 檔案可能恰好解碼成有效的 UTF-8，但也可能包含任意位元組，並觸發嚴格 UTF-8 的限制。如果需求是保留每個位元組，請使用具備二進位支援的程式庫或檔案工作流程，不要將已解碼的結果複製到這個工具中。
若要在 macOS 應用程式或指令碼中進行可重複的自動化作業，請使用您所用語言或框架提供的 Base32 實作。Python 的標準函式庫 Base32 文件說明了一個可用選項。瀏覽器工作流程最適合檢查值、閱讀清楚的驗證結果，以及執行最後的往返轉換，而不必手動處理原始位元組。
本機處理不等於保密
UTF-8 轉換、Base32 分組、驗證及結果準備，都會在目前的瀏覽器分頁中於本機進行；不會上傳任何內容。這表示此工作流程不會將貼上的值傳送至遠端轉換伺服器。Copy output 控制項是獨立的功能：只有在使用者選取後，它才會使用瀏覽器剪貼簿，而剪貼簿存取遭拒不會改變轉換結果。
Base32 本身不提供保密性、真實性、完整性保護或密碼儲存。任何取得編碼文字的人都能解碼。它既不是雜湊，也不是簽章，也不會壓縮輸入。本機處理處理的是轉換發生的位置，但不會讓編碼值變成受保護的機密內容。
若要執行 Mac 文字解碼工作，請保留原始 Base32 值，修正工具回報的確切驗證問題，並在適當時使用 Swap 確認最終文字。
如果您正在比較各項選擇，在 Python 中解碼 Base58：原始位元組與 UTF-8有詳細說明。
如果您正在比較各項選擇，二進位轉文字轉換器：無須猜測即可解碼位元組有詳細說明。