工具說明

關於 Base64 與十六進位互轉工具

Base64 to Hex 會把編碼過的內容轉成底層位元組的純十六進位檢視，讓你能一個位元組一個位元組地讀懂二進位資料，而不必猜一整片 Base64 字元裡究竟裝了什麼。

它支援雙向轉換，會自動去除 data URI 前綴與 PEM 標頭行，接受帶或不帶 0x 與分隔符號的十六進位輸入，並回報位元組數；當開頭位元組符合已知特徵碼時，還會標示偵測到的檔案類型。

如何使用 Base64 to Hex

把編碼後的值貼進輸入框；data:image/png;base64, 這類前綴，或 PEM 區塊的 BEGIN 與 END 行都會自動移除，空白字元也會被忽略。
用方向按鈕在 Base64 to Hex 與 Hex to Base64 之間切換。
十六進位輸入方面，你的工具產出什麼形式就貼什麼：純數字、帶 0x 前綴，或以空格、冒號、連字號分隔的位元組都行。
開啟大寫輸出或位元組之間加空格，以符合你的除錯器或通訊協定文件所用的排版。

什麼時候會用到

把憑證或金鑰的 PEM Base64 主體轉成十六進位，手動走過 DER 結構來檢視原始位元組。
檢查檔案或圖片開頭的識別碼，確認它真正的類型，而不是信任副檔名。
為二進位通訊協定封包、韌體酬載，或以十六進位記載卻以 Base64 傳輸的密碼學測試向量除錯。
把封包擷取工具產出的十六進位傾印轉成 Base64，好貼進設定檔或 API 請求主體。

Base64 與十六進位如何表達同一批位元組

兩者都是同一串位元組的文字表示法，只是在密度與可讀性之間做了相反方向的取捨。

Base64 把 3 個位元組塞進 4 個字元，因此編碼後的文字約比原始資料大 33 個百分點。
結尾的 = 是填補字元，當輸入長度不是 3 的倍數時才會加上。
十六進位讓 1 個位元組固定對應 2 個字元，體積加倍，但每個位元組的位移都是固定的。
這種固定對應正是十六進位在除錯時勝出的原因：第 12 個位元組永遠從第 24 個字元開始，規格書上的位移和你眼前所見完全對得上。

Base64 轉十六進位常見問題

為什麼我的 Base64 圖片或憑證，在一般 Base64 解碼器裡看起來像亂碼？: 多數解碼器會把結果當成 UTF-8 文字顯示。二進位內容含有不是合法文字的位元組值，於是被畫成替代字元或整個走樣。十六進位就沒有這個問題。
我可以直接貼完整的 PEM 區塊或 data URI 嗎？: 可以。BEGIN 與 END 標記行以及 data URI 前綴會在解碼前先行剝除，換行也會被忽略。
反方向時接受哪些十六進位格式？: 0x 前綴、純十六進位數字，以及用空格、冒號或連字號分隔的位元組都可以。分隔符號會在重新編碼位元組之前先移除。
偵測到的檔案類型是什麼意思？: 系統會把開頭位元組與 PNG、JPEG、GIF、PDF、ZIP、GZIP 及 DER 的已知特徵碼比對。若都不吻合，就不顯示類型，而不是給你一個猜測。
我的資料會被上傳到哪裡嗎？: 不會。解碼、重新編碼與特徵碼偵測全部都在你的瀏覽器裡進行，因此金鑰、憑證與擷取到的封包永遠不會送往 wetool.site。

Base64 to Hex 與以文字為導向的 Base64 解碼器

一般的 Base64 編解碼器走的是 UTF-8 文字路徑：先解碼 Base64，再把結果解讀成字串。對 JSON 和可讀的權杖來說這沒問題，但 PNG 標頭、DER 編碼的憑證，或二進位通訊協定封包，內含的位元組值並沒有合法的文字意義，於是輸出變成亂碼，換回去時還可能掉位元組。本頁完全不碰文字層，它在位元組層級於 Base64 與十六進位之間轉換，所以 0x00、0xFF 以及各種不合法的 UTF-8 序列，都能原封不動地完成來回轉換。

逐位元組讀懂十六進位傾印

只要內容變成十六進位，開頭幾個位元組通常就會告訴你手上拿的是什麼。

89 50 4e 47 是 PNG 檔，而 ff d8 ff 標示著 JPEG 資料的開頭。
25 50 44 46 是 PDF，50 4b 03 04 是 ZIP 或任何以 ZIP 為基礎的容器，1f 8b 則是 GZIP。
開頭的 30 82 是 DER 結構的 SEQUENCE 標籤，也就是憑證或金鑰主體在 PEM Base64 解碼後的樣子。
十六進位數字若是奇數個就無法組成完整位元組，這時請檢查複製來的傾印首尾是不是少了一位數。