RFC 4648 Base64 與 Base16 十六進位以兩種不同的字母表描述完全相同的位元組序列，因此兩者之間的轉換是純粹的重新對應，不會造成資訊遺失 — 每個位元組都保持可識別，包括其他工具有時會去除的前導 00 值。對於極大載荷高達 500,000 個解碼後位元組的情況，Base64 轉 Hex 轉換器在數值位元組陣列中於本地端執行整個管線，因此一個 300 KB 的日誌片段、測試固件或雜湊值可以在不截斷、不上傳且不靜默強制轉型的情況下從一種表示法轉換為另一種。嚴格的解碼器要求標準的填充式 Base64（反向時則為標準的每個位元組兩位數十六進位），在相同的規範下拒絕 base64url 與 MIME 行換行，並重新編碼已解碼的位元組以剔除非零填充位元，否則這些填充位元會為相同的資料產生第二種拼法。由於結果是精確的，位元組計數與前導零符合主導規範的標識，這正是你在比較已簽署值、快取鍵、協定欄位或任何一個多餘位元組就會改變意義的載荷時所需要的。
「大型文字」實際開始產生影響的時機
「大型文字」這個詞可能指截然不同的事物。一個 40 字元的 API 權杖可以容忍於大多數解碼器毫不費力處理的範圍內，但一個 200 KB 的 WebSocket 載荷、一個 2 MB JSON 檔案的壓縮主體、一個內嵌的 SVG，或從網路擷取中擷取的原始固件，就不再能容忍一個馬虎的解碼器了。每增加一千位元組，來自上游系統的一個多餘的空白字元、一個額外的等號或一個非標準拼法混入的機率就會倍增。base64-to-hex 批次工作流程對 500,000 位元組的載荷與 50 位元組的載荷採取相同的處理方式：透過位元組陣列運作，而非字面上的文字，所以輸出的位元組計數、填充與前導零僅取決於你實際貼上的位元組。
對於已簽署的資料、憑證指紋、MAC 標籤表示法以及其他安全性敏感的欄位，「有效」與「與規範逐位元組相同」之間的差別，就是綠色勾號與僅在正式環境中才會出現的靜默不符之間的差別。透過兩個解碼器轉換相同的雜湊值應該會產生相同的十六進位字串，而嚴格的往返轉換才能讓這種比較值得信賴。任何將位元組強制轉為文字、然後再將文字強制轉回位元組的過程，都可能在邊緣情況下產生偏移。將大型文字視為已格式化的位元組，而不是需要解讀的東西，才能保留那些邊緣情況。
將大型 Base64 文字轉換為十六進位
- 選擇方向。當來源是標準填充式 Base64 且目的地需要每個位元組的小寫十六進位時，選擇 Base64 → Hex。當來源是每個位元組恰好兩位數的連續十六進位字串時，選擇 Hex → Base64。
- 確認來源規範。確認資料使用標準的 RFC 4648 Base64 — 大寫與小寫字母、數字、加號與斜線，並在結尾帶有必要的等號。如果來源包含連字號、底線或換行符，則屬於不同的規範，應先進行標準化。
- 貼上載荷時不要修改。不要在位元組之間插入空格、不要去除填充、不要加上 0x 前綴或逗號，也不要在 76 字元處換行。貼上欄位要求的是精確的來源表示法；任何「為了讓它更易讀」所做的更改，都是對資料的更改。
- 執行轉換。頁面會解析輸入，透過嚴格的 RFC 4648 Base64 路徑解碼位元組，重新編碼已解碼的位元組以確認標準填充與零填充位元，然後將輸出呈現為小寫十六進位。
- 驗證大小。十六進位長度應該是預期位元組計數的兩倍，並且來源中的任何前導零位元組仍應以兩個十六進位數字 (00) 出現在字串左側。較短的輸出、缺失的 00 或出現意外的大寫字母，都代表流程中較早的環節出了問題。
- 僅複製轉換後的值。使用複製動作僅將十六進位字串移至剪貼簿，不包含任何標籤、標頭或說明文字。
保護大型載荷的輸入規則
解碼器刻意設計為嚴格，因為在規模放大時，寬鬆會變成負債。Base64 輸入長度必須是 4 的倍數。結尾必須出現必要的等號，中間不得出現填充，絕不會忽略空白字元，並且每個字元都必須屬於標準字母表 — 不允許連字號、底線、換行符或空白字元。解碼器還會重新編碼已解碼的位元組，並檢查沒有非零填充位元存活於字母表中，因此若某個拼法的最後一個字元將非填充位元帶入填充位元位置，則無法被視為與標準形式等價。這種重新編碼正是讓結果可逆的原因：任何未來解碼相同輸入的工具都會取回相同的位元組。
十六進位解析器遵循相同的紀律。每個位元組恰好兩位數，沒有 0x 前綴，沒有分隔符，沒有空白字元，沒有底線，沒有奇數的尾端半位元組。大寫與小寫皆可接受，但輸出會標準化為小寫。值 0f 代表一個位元組；單獨的 f 會因不完整而被拒絕。像 0f0a 這樣的四位數字串代表兩個位元組，永遠不會被視為一個其值取決於空白字元的位元組。這些規則使位元組邊界明確，並防止改變預期二進位值的強制轉型 — 當載荷夠長，而一次安靜的重新詮釋可能偏移數百個位元組時，這一點最為重要。
500,000 位元組的解碼上限約束了瀏覽器記憶體與輸出大小。該上限是按解碼後位元組計算，而非按 Base64 字元計算，所以只要未超出上限，同樣的限制可容納一個小檔案、一個長的憑證鏈欄位，或來自封包擷取的大型十六進位傾印。轉換全程使用數值位元組陣列，輸出絕不會被靜默截斷，格式錯誤的輸入會產生明確的錯誤，而不是你可能誤認為有效的部分結果。
大型編碼文字常見的失敗之處
- base64url 混入。某些網頁 API 將加號與斜線替換為連字號與底線，並經常省略填充。這是不同規範下的不同字母表。將 base64url 字串貼到標準解碼器中會產生明確的錯誤，而非錯誤的答案，這正是轉換器不會自動偵測規範的原因。
- MIME 行換行。電子郵件載荷會在每行 76 字元處換行 Base64。MIME 方法在其自身的環境中是有效的，但轉換器會將換行視為錯誤，因為標準的 RFC 4648 規範並不包含行換行。
- 填充缺失或過多。2 位元組的值必須以 == 結尾，1 位元組的值必須以 = 結尾。去除等號會使長度不再是 4 的倍數，解碼器會拒絕這種輸入。
- 非零填充位元。尾端群組中最後一個 Base64 字元若將非填充位元帶入填充位元位置，則屬於非標準形式。重新編碼步驟會拒絕它，即使底層位元組計數恰好相符。
- 前導零遺失。某些基於字串的轉換器會去除前導 00 位元組，因為整數或文字解析會判定前導零不重要。位元組陣列管線會保留它們，因此像十六進位中的 000abc 這樣的值在往返轉換後，會變回一個 Base64 字串，其前四個字元編碼的是一個真正的零位元組。
Base64 規範變體一覽
| 規範 | 字母表 | 填充 | 行換行 | 可原樣接受 |
|---|---|---|---|---|
| 標準 RFC 4648 | A–Z, a–z, 0–9, +, / | 必要 (= 或 ==) | 否 | 是 |
| base64url (RFC 4648 §5) | A–Z, a–z, 0–9, -, _ | 通常省略 | 否 | 否 — 請先標準化 |
| MIME 風格 Base64 | 與標準相同 | 必要 | 是（每行 76 字元） | 否 — 請先去除換行 |
相同的位元組序列恰好只能作為其中一種規範下的有效輸入。在貼上之前先確認規範，是保持大型文字轉換乾淨的最重要做法。RFC 4648 本身定義了第一列；其他兩種規範雖記載於同一份 RFC 中，但不可靜默互換。當位元組必須原封不動地往返轉換時，重新檢查填充與填充位元的嚴格模式，才能為你提供一個真正的「是／否」答案，而非一個近似答案。
以一個已知向量錨定轉換
錨定大型文字轉換的具體運算，就是 RFC 4648 的「Man」向量。三個輸入位元組為 0x4D 0x61 0x6E（ASCII 字元 M, a, n）。以三個為一組分組後，其 24 個位元拆成四個 Base64 字元 TWFu，由於位元組計數已經是 3 的倍數，因此沒有等號。反過來執行，這四個 Base64 字元解碼回相同的 3 個位元組，並重新編碼為 6 個小寫十六進位數字 4d616e。這個 6 字元的十六進位字串，就是 3 位元組輸入的逐位元組相同輸出：位元組計數的兩倍、小寫、無前綴、無分隔符。
在不失任何位元組的情況下完成轉換
大型文字轉換的實用檢查清單很短。決定方向。確認規範是標準的 RFC 4648，而非 base64url 或 MIME 換行格式。貼上載荷時不要重新排版。執行，然後計算：十六進位長度應該是預期位元組計數的兩倍，Base64 長度應該是每 3 個位元組 4 個字元，再加上 0 到 2 個結尾等號。如果任一計數不符，最常見的原因是來自不同規範的多餘空白字元或填充規則。Base64 轉 Hex 轉換器會在這些情況下印出明確的錯誤，而非傳回部分結果，這讓你能將輸出視為管線下一步的可靠依據。請參閱 RFC 4648 以了解轉換器強制執行的標準字母表與填充規則；當你需要相同位元組序列的另一種表示法，而非對它的重新詮釋時，請使用本頁。
相關閱讀：在不安裝軟體的情況下於 Windows 上進行二進位轉文字。
相關閱讀：大型文字的凱薩密碼解碼器：閱讀長篇段落。