Base64 編碼解碼

什麼是 Base64？

Base64 是 1980 年代為 email 附件設計的編碼方式（RFC 4648），把任何「二進位資料」用 64 個 ASCII 可印字元（A-Z、a-z、0-9、+、/）重新表示。原意是讓二進位檔案能在「只接受純文字」的系統（如早期 SMTP email、HTTP headers）中安全傳輸，不被換行、空白、控制字元破壞。

今日 Base64 幾乎無所不在：email 附件（MIME）、JWT token、HTTP Basic Auth、Data URL（把圖片塞進 HTML / CSS）、API 傳檔（圖片轉 Base64 放進 JSON）。

Base64 把每 3 個位元組編成 4 個字元，長度會變成原來的約 4/3 倍（增加 33%）。這是設計使然——犧牲體積換取「能在純文字環境傳輸」。

如果原本資料不是 3 的倍數，結尾會補 =（padding）讓總長度是 4 的倍數。這就是為什麼 Base64 字串常以一個或兩個 = 結尾。

瀏覽器內建的 btoa() 碰到第一個中文字就會壞，因為它把字串裡的每個字元都當成一個位元組，超過 U+00FF 的字元一律丟出 InvalidCharacterError；中文、日文、韓文與 emoji 全部中槍。反方向的 atob() 回傳的是原始位元組，直接顯示就會得到「café 變成 café」那種亂碼。這頁進去先過 TextEncoder、出來再過 TextDecoder，所以中文與 emoji 來回一趟不會壞。

什麼時候會用到，又該用哪個變體

• JWT decode：JWT 的 header / payload 是 Base64 編碼，貼進來可看欄位內容
• HTTP Basic Auth：Authorization: Basic dXNlcjpwYXNz 解開就是 user:pass
• Data URL：把小圖直接寫進 HTML / CSS，減少 HTTP request，用圖片轉 Base64 工具更方便
• API 傳輸二進位：JSON 不能放 binary，用 Base64 包進去 string 欄位
• 看不明訊息：log 或網址中看到「SGVsbG8gV29ybGQ=」這種感覺像密碼的字串，解碼看看是不是普通文字

字母表則要看它最後要待在哪裡：

• 標準 Base64（RFC 4648 §4）：用 + /，結尾 = padding。本工具預設此種
• URL-safe Base64（RFC 4648 §5）：把 + 換 -、/ 換 _，避免在 URL 中需要再 escape。JWT 用這種；編碼時勾「URL-safe」就會輸出這種
• 無 padding 版本：省略結尾 =，JWT 也常用。本頁的 URL-safe 輸出就不補 =
• Base32 / Base16（HEX）：類似概念，字元集更小，用於特殊情境（OTP 密鑰常用 Base32）

email 內文用的是 MIME 版本（RFC 2045）：同一套標準字母表，但每 76 個字元折一行，PEM 憑證區塊則是每 64 個字元折一行，解碼器本來就該忽略這些換行。如果你要做的只是把文字塞進網址、而不是搬運二進位資料，那要的其實是百分比編碼，請用網址編碼工具。

怎麼做出 HTTP Basic Auth 標頭

1. 模式留在「文字 → Base64」。
2. 輸入帳號、一個半形冒號、密碼，冒號前後都不要空格。第一個冒號是分隔點，所以密碼裡可以有冒號，帳號裡不行。
3. 按「複製」，標頭寫成 Authorization: Basic 後面空一格再接編碼結果。
4. 把結果切回「Base64 → 文字」解一次確認。如果這串是在終端機產生的，標頭看起來明明沒錯卻一直 401，兇手通常是 echo 多補的換行。

這個標頭等於把帳密攤在明面上，任何攔得到請求的人都能還原，所以 Basic Auth 只能走 HTTPS。多數 HTTP 客戶端會幫你組好，例如 curl -u user:password。

解開在 log 或網址裡撿到的字串

1. 切到「Base64 → 文字」貼上。貼進來解不開，最常見的原因是把前後的引號或結尾的逗號一起複製了，先修掉再試。
2. 字串裡出現 - 或 _，那是 URL-safe 版本。不用自己換字元，本頁會照 base64url 解，結果下方也會註明；缺了結尾的 = 也會自動補上。
3. 解出來有 � 或看不懂的中文，原文多半不是 UTF-8。台灣舊系統（早期網頁、銀行與政府資料）常用 Big5，把「解碼字元集」切到 Big5 再看一次。
4. 字串中間有兩個點，你拿到的是 JWT 而不是單一段 Base64。交給JWT 解碼工具，它會幫你切段並處理 URL-safe 字母表。
5. 解出來是一堆符號而不是錯誤訊息，代表那些位元組本來就不是文字：壓縮過的內容、圖片或加密結果都會乾淨地解開，看起來仍然像雜訊。
6. 解出來是 JSON，就貼到JSON 格式化工具看結構，順便驗語法。

結果怎麼帶到該去的地方

輸出是不換行的一整串，這正是標頭、JSON 欄位與環境變數要的形狀。畫面上會自動折行顯示，看起來像好幾行，複製下來仍然是一整串。

• 貼進 JSON：直接當字串值貼。Base64 的字元都不需要跳脫，所以不會冒出反斜線。
• 貼進網址：標準 Base64 不是網址安全的。要嘛整串百分比編碼（+ 變 %2B、/ 變 %2F、= 變 %3D），要嘛編碼時勾「URL-safe」改用 base64url 再貼。
• 貼進 YAML 或設定檔：保持單行，並把編輯器「長行自動折行後寫回檔案」的設定關掉；被插進去的換行會改變這個值。

中文怎麼處理？各語言與命令列的差異

本工具用 UTF-8 編碼中文，與現代瀏覽器、Node.js、Python 3、Go 預設行為一致。一個中文字通常編成 3 個位元組，Base64 後變成 4 字元。

如果解碼後出現亂碼，通常是來源用了非 UTF-8 編碼（早期 Big5、GB2312 系統）。Base64 本身只規範「位元組到字元的對應」，不規範「位元組對應什麼字元集」。台灣舊系統的 Big5 資料，把上方的「解碼字元集」切到 Big5 就解得回來；GB2312 本頁不支援。

每個平台都內建 Base64，差別在預設值：用哪套字母表、寫不寫 padding、長輸出折不折行、解碼器嚴不嚴格。瀏覽器的 btoa() 與 atob() 只處理位元組，UTF-8 那一段要自己接：

const b64 = btoa(String.fromCharCode(...new TextEncoder().encode(text)))
const text = new TextDecoder().decode(
  Uint8Array.from(atob(b64), c => c.charCodeAt(0)),
)

Node.js 把位元組處理藏在 Buffer 裡，另外提供 base64url 這個編碼名稱，直接換成 URL-safe 字母表並去掉 padding：

Buffer.from(text, 'utf8').toString('base64')
Buffer.from(b64, 'base64').toString('utf8')
Buffer.from(text, 'utf8').toString('base64url')

Python 3 兩端都是 bytes，所以 b64encode 回傳的是 bytes 不是字串；URL-safe 是另一組函式，而且解碼器預設會忽略不認識的字元，要嚴格就傳 validate=True：

import base64
base64.b64encode(text.encode()).decode()
base64.b64decode(b64, validate=True).decode()
base64.urlsafe_b64encode(text.encode()).decode()

PHP 的字串本來就是位元組串，base64_encode() 與 base64_decode() 直接吃字串，UTF-8 中文不用另外轉；但檔案若是 Big5 存的，編出來的就是 Big5 位元組，解碼端照 UTF-8 讀一樣會是亂碼。Go 則把選擇攤開成 encoding/base64 的四種：StdEncoding 與 URLEncoding 寫 padding，RawStdEncoding 與 RawURLEncoding 不寫。

命令列是經典地雷區。echo 會多加一個換行，那個換行會被一起編進去，做出伺服器不認的憑證，所以要用 printf。GNU coreutils 還會在 76 欄折行，除非你關掉：

printf '%s' 'user:password' | base64 -w 0   # GNU，不折行
printf '%s' 'user:password' | base64        # macOS，預設就不折行
printf '%s' 'dXNlcjpwYXNz' | base64 -d      # 解碼

macOS 上的是 BSD 版本，沒有 -w；它長年接受 -D 解碼，較新的版本也收 -d，寫進腳本前先跑一次 base64 --help 確認。資料庫也有：PostgreSQL 的 encode 與 decode、MySQL 的 TO_BASE64() 與 FROM_BASE64()，兩邊預設都會把長輸出折成多行，從查詢結果撈出來的值可能要先把換行去掉。

限制與隱私

不會離開你的瀏覽器。轉換用 TextEncoder、TextDecoder 與內建的 btoa()、atob() 在本機完成，輸入不上傳、不儲存、不記錄，結果區也對錄影分析做了遮罩。即使如此，正式環境的憑證還是建議用本機指令處理：貼進任何網頁的活憑證，就是去過一個它本來不需要去的地方。

它不是安全機制，也不是壓縮。沒有金鑰所以沒有機密性，沒有檢查碼所以被改過的字串多半還是解得開。讀得懂 JWT 的 payload 只代表你知道它宣稱了什麼，不代表那是真的，那要驗簽章才算數。體積還會多出約三分之一，內嵌成 Data URL 的圖片沒辦法單獨被快取，嚴格的 CSP 也可能直接擋掉。

這個解碼器吃什麼、不吃什麼。解碼前會先去掉空白與換行，所以 MIME 折行的區塊照樣解得開；URL-safe 的 - 與 _ 會先換回標準字元，缺的 = 會補上，再交給瀏覽器照 WHATWG Infra 標準的 forgiving-base64 演算法解。長度除以 4 餘 1 的字串補不回來，會直接顯示錯誤。

檔案大小。整串是一次轉完的，幾 MB 的文字會讓分頁頓住，檔案等級的請改用上面的命令列。