Base64 編碼與解碼工具

Base64 的用途

Base64 用 64 個能安全通過任何文字管道的字元，重新表示任意位元組。它每次取三個位元組，把這 24 位元分成四組各 6 位元，再把每組對應到 A-Z、a-z、0-9 與兩個符號中的一個字元。每輸入三個位元組就輸出四個字元，所以在不計換行的情況下，結果大約比原始資料大 33%。

它的目的是傳輸，而不是保密。Base64 是為了會破壞原始位元組的管道而設計的：會截掉最高位元的郵件系統、把某些控制字元當作指令的協定、必須是純文字的格式。它不是加密，也不是壓縮，任何人只要願意解碼，都能輕易讀出編碼的內容。把 Base64 字串當作受到保護的東西，是一種誤解，而這個解碼器正好能輕鬆示範這一點。

填充與兩種字母表

當輸入無法被三個位元組整除時，輸出會補上一或兩個 = 字元，讓長度成為 4 的倍數。有些產生器會省略填充；由於正確的數量可以從長度推算出來，本解碼器會自動補回，而不是拒絕輸入。

標準字母表最後兩個字元是 + 和 /，兩者在網址中都有特殊意義，跳脫後會變成 %2B 和 %2F，放在查詢字串或檔名裡既難看又容易出錯。因此 RFC 4648 第 5 節定義了改用 - 和 _ 的網址安全版本，而且因為 = 同樣需要跳脫，通常會省略填充。JWT 的每個區段用的都是這個版本。本工具編碼時兩者皆可選；解碼時會自動偵測你貼上的是哪種字母表，不需要另外指定。

Unicode 與 btoa 的陷阱

瀏覽器內建 btoa 函式已經幾十年了，但它的行為和多數人以為的不同。它以 Latin-1 為基礎：輸入中每個字元的碼位都必須小於 256，否則就會丟出 InvalidCharacterError。只要傳入一個中文字、一個俄文名字或一個表情符號，它就會直接失敗。

人們最先找到的解法通常是在編碼前先 escape 字串，但這會把 ASCII 以外的字元轉成不同的位元組序列，到了另一端解碼出來就是亂碼。正確做法，也就是本工具採用的做法，是先用 TextEncoder 把文字轉成 UTF-8 位元組，再對這些位元組編碼。所以任何文字系統在這個工具中來回轉換都不會改變。

解碼則反過來進行，而且不會亂猜。如果解碼後的位元組不是有效的 UTF-8，工具會告訴你這是二進位資料，而不是顯示一串替換字元。這通常代表內容是圖片、壓縮檔、protobuf 訊息或密文，正確的做法是把位元組存成檔案，而不是當成文字閱讀。

不該使用的時機

Base64 不適合用來保存機密，因為它什麼都不保護。它也不適合作為嵌入大型資源的預設做法：把圖片做成 data URI 會讓大小增加三分之一，無法與承載它的文件分開快取，而且解析時會阻塞頁面。

它真正派上用場的是那些小而棘手的情況：PEM 格式的憑證、簽章、JSON 內容中的二進位欄位、簡短的內嵌圖示、權杖的區段。

三個位元組進去，四個字元出來

只要親手算過一次，就會對這個編碼方式更有把握。以三個 ASCII 字母 Man 為例：位元組值分別是 77、97、110，二進位是 01001101、01100001、01101110。把這 24 位元排成一列，然後切成四組各 6 位元，而不是三組各 8 位元：010011、010110、000101、101110。把每組當成數字讀，得到 19、22、5、46，再到 A-Z、a-z、0-9、+、/ 這個字母表中查找，索引 0 是 A，索引 26 是 a。結果就是 TWFu。

Base64 的每一項特性都能從這段算術推出來。每個字元 6 位元，所以字母表剛好有 64 個項目；每三個位元組對應四個字元，所以輸出大了三分之一；而填充之所以存在，是因為最後一組可能不足：剩下一個位元組會產生兩個字元加上 ==，剩下兩個位元組會產生三個字元加上 =。

解碼就是把同樣的運算反過來做，所以任何長度不是 4 的倍數的 Base64 字串，不是已被填充、就是被截斷，或是由刻意省略填充的編碼器所產生。

你會在哪些真實系統中遇到它

PEM 檔案（憑證、CSR、私密金鑰）就是 Base64，加上開頭與結尾行，並每 64 個字元換行一次。這個行長度是 MIME 的慣例，而非 Base64 的要求，解碼器應該忽略這些換行。

HTTP 基本認證會把 username:password 以 Base64 編碼後放進 Authorization 標頭，這正是為什麼在未加密的 HTTP 上使用基本認證，等同於以明文傳送密碼。電子郵件附件自 1992 年 MIME 定義以來就使用 Base64，理由和當初一樣：那個年代的郵件伺服器無法可靠地傳遞任意位元組。

data URI 把整個檔案嵌入文件中：data:image/png;base64, 後面接著內容。JSON API 只要有欄位需要攜帶位元組，就會使用 Base64，因為 JSON 沒有二進位型別。JWT 的各個區段使用不含填充的網址安全版本，而 Docker 設定、Kubernetes secret 與許多 CI 系統則以 Base64 編碼儲存憑證，那是一種儲存方式，而不是保護。

大小、記憶體與大型檔案

33% 的膨脹是最顯眼的成本，通常也是最小的成本。Base64 文字比原始位元組更難壓縮，因為編碼破壞了壓縮程式原本可以利用的位元組層級規律，所以經 gzip 壓縮的 Base64 內容，通常比壓縮過的原始資料更大。

在瀏覽器中，記憶體才是更嚴苛的限制。編碼一個檔案意味著同時持有原始位元組與產生的字串，而字串又大了三分之一，所以一個 100 MB 的檔案在送出前可能需要數百 MB 的記憶體。串流 API（把檔案分塊讀取並逐塊編碼）可以避免這點，前提是每一塊都是 3 個位元組的倍數，讓填充只出現在最後。

對於大型資料，更好的答案通常是根本不要編碼：用 multipart form data 或原始請求主體傳送檔案，把 Base64 留給那些必須穿過文字格式的、小而棘手的值。

相關的字母表，以及它們存在的理由

Base32 使用 32 個字元，輸出比輸入大 60%。聽起來划不來，直到你需要讓人唸出來或手動輸入為止。它不分大小寫，避開容易混淆的字元，也正是 TOTP 密鑰與 Tor 洋蔥網址所使用的編碼。

Base58 去掉了 0、O、I、l 與兩個符號，讓字串可以靠肉眼抄寫而不致混淆；最知名的用途是比特幣位址。Base85（Ascii85）把四個位元組塞進五個字元，密度高於 Base64，代價是使用了許多格式必須跳脫的標點符號，這也是它主要殘存於 PDF 與 PostScript 中的原因。

這裡的模式是一致的：以上每一種都在密度與通道限制之間做取捨。Base64 之所以居於現在的位置，是因為它的密度足以值得這番工夫，而且在最廣泛的文字通道中都是安全的。

拿到一段內容時該怎麼查

面對任何看不懂的字串，第一個有用的問題是：它到底是不是 Base64。有三個可靠的跡象：長度是 4 的倍數，或結尾有一到兩個等號；字元僅限於英文字母、數字與兩個符號；以及解碼後得到的是可讀文字或可辨識的檔案標頭，而不是雜訊。

這些檔案標頭值得記得它們編碼後的樣子，因為那能讓你在存檔前就知道內容是什麼。解碼後以 89 50 4E 47 開頭的是 PNG；FF D8 FF 是 JPEG；50 4B 03 04 是 zip，其中也包含所有 Office 文件；25 50 44 46 是 PDF。在 Base64 形式中，以 iVBORw0KGgo 開頭的是 PNG，以 /9j/ 開頭的是 JPEG，這兩者在 API 內容與 data URI 中經常出現。

如果解碼後既不是文字也不是已知標頭，通常有三種解釋：這是網址安全版的 Base64 卻用標準字母表解碼、它被編碼了兩次，或者它根本不是 Base64，而是十六進位或 base32。三者都能在一秒內分辨：網址安全字串含有減號或底線；重複編碼的內容解碼後仍像 Base64；十六進位只用十六個字元。