一個本機版的 base64 轉 hex API 替代方案，是一種瀏覽器端的工具，可以在符合 RFC 4648 的標準加了補位的 Base64，與精確的小寫十六進位位元組之間互相轉換，而不需要把輸入內容送到遠端端點。Base64 轉 Hex 轉換器會在你的瀏覽器中執行這個轉換，並採用嚴格的驗證規則：Base64 輸入必須是四個字元的整數倍、必須有需要的等號補位、不能有空白，而且只能使用標準字母表；十六進位輸入則必須是每個位元組剛好兩位數，不能有 0x 前綴，也不能有分隔符號。解碼之後，這個轉換器會把位元組重新編碼，藉此拒絕任何非零的補位位元——這種情況會為同一份資料，產生第二種非標準的寫法。這個頁面把解碼後的輸入上限設在 500,000 個位元組，轉換時使用數字位元組陣列，而不是透過瀏覽器的文字型別轉換，而且只有在你按下複製時，才會複製轉換後的數值。整個過程不會上傳任何內容，所以很適合用來檢查通訊協定測試資料、雜湊摘要、二進位識別碼與簽章過的內容，而不需要把它們暴露給第三方服務。
一個本機版的 Base64 轉 Hex API 替代方案是什麼樣子
一個遠端的 Base64 轉 hex 端點，會接受你的字串，在伺服器端執行程式碼，然後回傳一個 hex 字串。每一次呼叫都會多一次網路來回，可能會被計入速率限制，還會讓你的內容經過你無法控制的基礎設施。對於內部除錯工作、簽章資料檢查，以及離線測試來說，這種延遲與資料暴露面通常都是不必要的。一個瀏覽器端的替代方案，保留了同樣的轉換邏輯，但把它搬進本機執行的程式碼中。這些位元組永遠不會離開分頁，沒有速率限制，而且在網路中斷，或上游 API 發生事故時，這個工具仍然能繼續運作。
改用本機工具，也改變了驗證的模型。許多公開的端點，你送什麼它就接受什麼，伺服器算出什麼就回傳什麼，包括把 Base64 中的空白直接去除、缺少補位，或即時把 base64url 字元替換掉。這種寬鬆的做法，會掩蓋掉真正重要的輸入錯誤——當這串位元組要餵進雜湊、簽章，或通訊協定解析器時，這些錯誤就會造成影響。Base64 轉 Hex 轉換器刻意做得很嚴格：它會用明確的錯誤訊息拒絕格式不正確的輸入，也絕不會產生部分結果，所以輸出欄位裡顯示的位元組，就是你管線下一步會用到的那些位元組，完全一致。
轉換器內部嚴格的 RFC 4648 驗證
這個轉換器實作了 RFC 4648 中對 Base64 定義的四字元量子（quantum）與字母表，以及 Base16 的兩位數位元組表示法。這個 Base64 解碼器會強制執行五項具體檢查，而一般的遠端 API 通常都不會做：
- 總長度必須是四個字元的整數倍。
- 當最後一組只有一個或兩個原始位元組時，必須有對應的等號補位。
- 等號只能出現在字串的結尾。
- 輸入中任何地方出現空白都算是錯誤，不會被悄悄去除。
- 每一個字元都必須屬於標準 Base64 字母表：大寫 A 到 Z、小寫 a 到 z、數字 0 到 9，以及加號和斜線。
成功解碼之後，這個轉換器會把位元組重新編碼，並和原始輸入做比對。如果不一致，就代表最後一個量子中的補位位元不是零，這會為同一份資料，產生一種非標準的寫法。即使底層的位元組序列其實完全相同，這種非標準的輸入仍然會被拒絕。當你在比對簽章過的資料、通訊協定測試資料、快取鍵，或必須逐位元組符合某個規格的序列化數值時，這一點就很重要。
十六進位剖析器遵循一套平行的規則。輸入必須是連續的序列，每個位元組剛好兩位數，不能有 0x 前綴、不能有分隔符號、不能有底線，也不能有落單的半位元組。大寫與小寫的數字都能接受，但輸出一律採用小寫，以維持格式一致。字串 0f 代表一個位元組；單獨的字串 f 則不完整，會被拒絕。想了解字母表、補位與長度規則更多的結構性細節，請參閱Base64 解碼速查表。
用三個步驟把 Base64 轉成 Hex，或把 Hex 轉成 Base64
這個轉換器使用單一頁面，搭配一個方向選擇器、一個輸入欄位、一個輸出欄位，以及一個複製按鈕。完整的操作流程如下：
- 選擇Base64 轉十六進位或十六進位轉 Base64，並確認來源真的使用標準的 RFC 4648 Base64，而不是 base64url 或 MIME 格式。
- 貼上不含空白、符合標準補位的 Base64，或貼上每個位元組剛好兩位數、不含前綴或分隔符號的 hex。
- 執行轉換，確認預期的位元組長度，以及 hex 中顯示出來的任何開頭 00 位元組，然後複製確切的結果。
方向的選擇很重要，因為這兩種表示法表面上看起來很像，但在傳輸線路上代表的意義並不相同。一個用連字號和底線取代加號和斜線的 base64url 字串，會被直接拒絕；你必須先依照它自己的規範轉換它。同樣的道理，也適用於含有換行的 MIME 包裝 Base64，或從除錯器畫面複製出來、帶有 0x 前綴的 hex 字串。這個轉換器不會悄悄猜測輸入所屬的格式，因為用猜的可能會掩蓋真正的輸入錯誤，產生出一個解碼後得到你原本沒打算要的位元組的 hex 字串。
本機瀏覽器工具與一般遠端 API 的比較
大多數一般的 Base64 轉 hex API，都是為了臨時使用而設計的。它們接受寬鬆的輸入，回傳算出來的任何結果，並藉由忽略 RFC 4648 較嚴格的規則，來維持簡單。下表把一個瀏覽器端的嚴格轉換器，和這種寬鬆的常見基準做嚴謹程度上的比較。
| 輸入特徵 | 本機嚴格轉換器 | 一般遠端 API（典型情況） |
|---|---|---|
| Base64 輸入中含有空白 | 以明確錯誤拒絕 | 通常會被悄悄去除 |
| 缺少結尾等號補位 | 拒絕 | 通常會被接受並重新補位 |
| base64url 字母表（連字號、底線） | 拒絕 | 通常會自動偵測 |
| 非零補位位元 | 拒絕（標準性檢查） | 通常會被接受 |
| hex 輸入中含有 0x 前綴 | 拒絕 | 通常會被接受並去除 |
| 奇數長度的 hex（落單的半位元組） | 拒絕 | 通常會被悄悄補位或直接接受 |
| 開頭的零位元組 | 在 hex 中保留為 00 | 來回轉換後可能會遺失 |
| 是否需要網路 | 否 | 是 |
| 內容位元組是否會離開你的機器 | 否 | 是 |
這種嚴謹程度上的差異，在 hex 字串會被餵進某個對位元組做雜湊的驗證步驟時，或當這個來回轉換的數值必須完全符合某個公開發布的測試向量時，就很重要。如果只是想快速用肉眼檢查一下隨意的資料，一個寬鬆的 API 就夠用了。但只要位元組會被簽章、雜湊，或拿去和某個規格比對，嚴格的做法就是比較安全的選擇，而本機轉換器不需要使用者另外選擇，就會強制執行這套規則。
一個實際範例：對「foo」測試向量做來回轉換
RFC 4648 發布了一小組測試向量，任何符合規範的 Base64 實作都必須能正確處理。其中最簡單的一個，就是三個位元組的 ASCII 字串 foo。這個轉換器處理這個案例的方式如下。
第 1 步：從位元組 66 6F 6F（十六進位）開始，這是 f、o、o 這三個字元的 ASCII 編碼。
第 2 步：把它們串接成二進位：01100110 01101111 01101111。
第 3 步：從左邊開始，切成六位元一組：011001、100110、111101、101111，換算成十進位分別是 25、38、61 與 47。
第 4 步：在標準 Base64 字母表中查出這些索引值對應的字元。25 對應到 Z，38 對應到 m，61 對應到 9，47 對應到 v。輸入內容剛好是三個位元組，所以不需要補位。
第 5 步：得到的 Base64 字串是 Zm9v。
把 Zm9v 貼進 Base64 轉 Hex 轉換器的「Base64 轉十六進位」方向，會得到 666f6f。把 666f6f 貼進「十六進位轉 Base64」方向，會得到 Zm9v。這個來回轉換沒有任何損失，使用的是標準字母表，也不需要補位，因為輸入內容本來就是三個位元組的整數倍。這正是內部用來確保兩個方向正確性的同一組測試向量，其他還包括空字串、f、fo、foob、fooba、foobar，以及一段會用到字母表數值 62 與 63 的位元組序列。
什麼時候你仍然應該呼叫遠端 API
本機轉換器很適合用來檢查、除錯，以及在不同表示法之間複製位元組。但它不能取代那些在這些位元組之上，執行語意層工作的服務。當你需要憑證解析、MIME 組裝、影像解碼、JSON 解析、JWT 簽章驗證，或任何其他會去解讀位元組內容、而不只是轉換其表示法的層級時，就該去呼叫遠端 API。這個轉換器不會把位元組解讀成 UTF-8、數字、憑證、影像、JSON、密碼學金鑰、檢查碼或檔案，也不會加上 MIME 標頭、data-URL 前綴、換行包裝，或檢查碼欄位。如果某個應用程式需要上述其中一種容器格式，請把轉換出來的位元組當成其中一層來使用，再另外獨立驗證外圍的格式。
請記住，Base64 與 hex 都是可逆的編碼方式，不是加密、雜湊、簽章、壓縮，也不是存取控制。輸出的內容和輸入完全是同一組位元組，所以如果裝置或瀏覽器工作階段是共用的或會被記錄，就不要把憑證、權杖、私密金鑰或個人紀錄貼到任何工具頁面上，就算是本機工具也一樣。對於安全性敏感的通訊協定，請把最終的表示法拿去和權威規格或官方測試向量做比對，而不要把轉換成功當成語意上的驗證。當這串位元組序列的意義超出其原始數值本身時，RFC 4648 文件，以及針對具型別資料容器的RFC 8949，就是權威的參考依據。
延伸閱讀：不需要上傳的本機凱撒密碼解碼器替代方案。