Base64 編解碼

Base64 字串編碼與解碼

Base64 把任意內容重新編排成只有 A–Z、a–z、0–9、+、/、= 的 ASCII 字串，讓它能安全穿過只認得純文字的通道——HTTP header、email、YAML、環境變數。這個工具做的是文字與 Base64 的雙向轉換，用瀏覽器內建的 btoa / atob 搭配 UTF-8 轉換，所以中文與 emoji 不會變成亂碼；輸入不會離開這台電腦，這點對 Base64 特別重要，因為貼進來的通常是 Basic Auth 憑證、JWT payload 或 Kubernetes Secret 的內容。

使用步驟

  1. 先用上方兩顆按鈕選方向：「文字 → Base64」或「Base64 → 文字」。切換方向會同時清空左右兩個框，所以想把剛才的結果拿回來解碼，要先按複製再切。
  2. 把內容貼進左邊的輸入框（標題會隨方向變成「原始文字」或「Base64 字串」）。
  3. 按輸入框下方的「編碼」／「解碼」按鈕。這不是即時轉換：改完輸入後右邊仍然是上一次的結果，要再按一次才會更新。
  4. 結果出現在右邊的唯讀框，用它右上角的複製按鈕帶走；輸出為空時複製按鈕是停用狀態。
  5. 解碼失敗時，輸出框會被清空，並在下方出現紅色的「無效的 Base64 字串」。編碼方向不會顯示錯誤。

什麼時候用得上

看懂 Kubernetes Secret 與 CI 變數裡的值

kubectl get secret -o yaml 印出來的每個值都是 Base64，光看不知道存了什麼。貼進來解碼就能確認是不是接錯環境的連線字串；反過來，要寫進 Secret 的值也可以先在這裡編好再貼上。YAML 裡折成多行的值可以整段貼，換行會被忽略。

生成或還原 Basic Auth 憑證

Authorization: Basic 後面那串就是 user:password 的 Base64。要測一支 API 時在這裡編一個貼進 curl；反過來，從抓包或日誌裡撈到的那串解回來，通常一眼就看出是帳號打錯還是密碼多了空白。

讀 JWT 的 payload

把 JWT 用 . 切開後，中間那一段貼進來解碼，就能看到 sub、exp、scope 這些 claim，確認 token 是不是真的過期了或權限不對。注意那是 base64url 變體，做法見下方注意事項。

解 email 標頭的 MIME encoded-word

原始信件標頭裡的中文主旨長得像 =?UTF-8?B?5L2g5aW9?=。把 ?B? 和 ?= 之間那段貼進來解碼就能讀出原文，在追查退信、比對寄件主旨、或除錯自己寄出的信時很實用。

限制與注意事項

  • 編碼走的是 btoa(unescape(encodeURIComponent(text)))：先把文字轉成 UTF-8 位元組再編碼，所以中文、日文、emoji 都能正確往返。直接對中文呼叫 btoa 會丟 InvalidCharacterError，這正是許多手寫的網頁工具一遇到非英文就壞掉的原因。
  • 輸出使用標準 Base64 字母表（含 +、/、結尾 = padding），永遠是單行，不做 MIME 的 76 字元換行。要放進 URL query 或檔名，請自行改成 base64url：+ 換 -、/ 換 _、去掉 =。
  • 解碼端不接受 base64url，字串裡有 - 或 _ 會被判為無效。padding 可以省略（SGVsbG8 與 SGVsbG8= 都能解），但長度除以 4 餘 1 的字串（例如 SGVsb）一定失敗。中間的空白與換行會被忽略，所以 76 字元換行的 MIME 區塊、或 YAML 裡折行的值都能直接貼。
  • 這個工具只處理文字，沒有檔案選擇器，也不輸出二進位。PNG、PDF、PEM 憑證的 Base64 解出來不是合法 UTF-8，會顯示「無效的 Base64 字串」——那不是你的 Base64 有問題，而是這裡只能輸出文字。要把圖片轉成 data URI，請用「圖片轉 Base64」工具。順帶一提，這行錯誤訊息目前固定是中文，英文介面下也一樣，而且同時代表「有非法字元或長度不對」與「解出來的位元組不是 UTF-8」兩種情況。
  • 換行會被正規化：貼進輸入框的 CRLF 會被瀏覽器轉成 LF。所以同一份 Windows 文字檔在這裡編碼，和用命令列的 base64 編碼，結果可能不同（差在每行結尾少了 0D）。要逐位元組一致，請用命令列工具。
  • Base64 不是加密，只是換一種寫法，任何人都能解回原文，而且體積會膨脹約 33%。它的用途是讓資料能安全通過純文字通道，不是保護資料。

常見問題

為什麼中文和 emoji 在別的線上工具會變亂碼，這裡不會？

因為瀏覽器的 btoa 只接受 Latin-1（每字元 0–255），碰到「你」這種字元會直接丟例外或被截斷。這裡在編碼前先用 encodeURIComponent 把文字轉成 UTF-8 位元組序列，解碼時再用 decodeURIComponent 轉回來，所以整條路徑都是 UTF-8。反過來說，如果對方那串 Base64 是用 Latin-1 或 Big5 編出來的，在這裡多半會被判為無效，因為那些位元組不是合法 UTF-8。

我貼上的內容會被上傳嗎？

不會。編解碼用的是瀏覽器內建的 btoa 與 atob，在你的裝置上跑完就結束，沒有任何請求帶著輸入框的內容出去。你可以斷網後再操作一次驗證——工具照樣運作。頁面本身會載入廣告等第三方資源，那些請求不包含你輸入或轉換的任何資料。

整串 JWT 貼進來為什麼解不開？

兩個原因。第一，JWT 是用 . 串起來的三段，. 不是合法的 Base64 字元，整串貼會直接失敗——請只貼中間那一段 payload。第二，JWT 用的是 base64url，- 與 _ 在這裡不被接受；把 - 換成 +、_ 換成 / 再貼就能解。padding 不需要補回去，除非長度除以 4 剛好餘 1。

可以編碼圖片或檔案嗎？

不行，畫面上只有文字輸入框，沒有檔案上傳。把二進位檔案的內容貼進文字框也不會成功，因為複製貼上的過程已經破壞了原始位元組。圖片請用「圖片轉 Base64」工具，它會直接讀檔案並產生可貼進 CSS 或 <img> 的 data URI。

為什麼我改了輸入，結果卻沒變？

這個工具是按鈕觸發，不是即時轉換。每次改動輸入後都要重新按一次「編碼」或「解碼」，在那之前右邊顯示的是上一次的舊結果。另外要注意切換方向會清空兩邊的內容，所以要把編碼結果拿去解碼驗證，先複製再切換。

解碼成功了，但結果是一堆亂碼或方塊，怎麼辦？

表示位元組是合法 UTF-8，但原本不是給人讀的文字——例如壓縮過、加密過，或是序列化的二進位結構。另一種情況是原始文字用的是 Big5、Shift-JIS 這類非 UTF-8 編碼，多數時候會直接報無效，偶爾湊巧構成合法 UTF-8 就會解出亂碼。這個工具固定以 UTF-8 解讀，不提供選擇編碼。