Base64 是什麼
電腦裡的資料本質上是一串位元組（byte），但很多地方只能安全放「文字」，例如電子郵件內文、JSON、HTML 屬性、網址。Base64 的做法，是把每 3 個位元組（24 位元）切成 4 組、每組 6 位元，每組對應 64 個可顯示字元之一（A–Z、a–z、0–9、+、/），不足 3 個位元組的結尾用 = 補齊。於是任何資料都能變成純文字，再原封不動還原。這是「編碼」不是「加密」，沒有密碼，任何人都能解。
中文與 emoji 為什麼常常編錯
很多人直接用 JavaScript 的 btoa 編碼，遇到中文就報錯，因為 btoa 只認 Latin-1 字元。正確做法是先把文字用 UTF-8 轉成位元組，再對位元組做 Base64。本工具就是這樣做，所以「你好」會得到 5L2g5aW9，emoji 也能完整來回。解碼時同樣先還原位元組，再用嚴格的 UTF-8 解讀；如果不是合法的 UTF-8，會明確告訴你，而不是吐出一堆亂碼。
怎麼用
- 文字：在「文字 Base64」貼上內容，按「編碼」或「解碼」。要放在網址或 JWT 裡，編碼格式選 Base64URL。
- 檔案：在「檔案 Base64」選一個 10 MB 以內的檔案，得到 Data URL 與純 Base64；反過來貼上 Base64，按「還原並下載檔案」就能取回原檔。
- 網址：在「網址編碼」輸入文字，選 encodeURIComponent 或 encodeURI 再按編碼；貼上 %E4%BD%A0 這類文字按解碼，就能看到原文。
encodeURIComponent 與 encodeURI 的差異
兩個都是 JavaScript 內建的網址編碼函式，把不能直接出現在網址裡的字元換成 % 加上兩位十六進位（以 UTF-8 位元組為單位）。差別在「哪些字元不編碼」：
| encodeURIComponent | encodeURI | |
|---|---|---|
| 不編碼的字元 | 英數字與 - _ . ! ~ * ' ( ) | 上述字元，再加上 ; , / ? : @ & = + $ # |
| 適用情境 | 查詢字串裡的單一值、路徑中的一段 | 已經組好的完整網址 |
| 範例輸入 | https://a.com/搜尋?q=你好&x=1 | |
| 範例輸出 | https%3A%2F%2Fa.com%2F%E6%90%9C%E5%B0%8B%3Fq%3D%E4%BD%A0%E5%A5%BD%26x%3D1 | https://a.com/%E6%90%9C%E5%B0%8B?q=%E4%BD%A0%E5%A5%BD&x=1 |
簡單的記法：只編「值」用 Component，編「整條網址」用 URI。另外，兩者都把空白編成 %20，而不是表單常見的 +；如果你解碼的是表單送出的資料，請勾選「把 + 當成空白」。
Base64 常見的使用場合
- 網頁小圖示：把很小的圖片轉成 Data URL 直接寫在 CSS 或 HTML 裡，省一次請求。圖片大的話不建議，會讓頁面變肥。
- 電子郵件附件：郵件協定本來只能傳文字，所以附件是用 Base64 編進信件裡（MIME，每 76 字元換行）。
- JWT 與 API：JSON Web Token 的三段都是 Base64URL；有些 API 要求把檔案內容用 Base64 放進 JSON。
- 設定檔與環境變數：多行金鑰、憑證常被編成一行 Base64 方便放進設定。
- 除錯：看到一長串英數字結尾有 =，先試試貼進來解碼，常常就是一段 JSON 或文字。
常見問題
Base64 是加密嗎？可以拿來保護密碼或機密資料嗎？
不是加密，不能用來保護資料。Base64 只是把二進位資料換成 64 種可顯示字元的「編碼」，任何人看到都能立刻還原，不需要任何金鑰。常見的用途是把圖片、檔案或特殊字元塞進只能放文字的地方，例如 JSON、HTML、電子郵件或網址。如果要保護資料，請用真正的加密（例如 AES），不要依賴 Base64。
為什麼 Base64 編碼後的檔案會變大？
Base64 用 4 個字元表示原本的 3 個位元組，所以編碼後的長度大約是原本的 4/3，也就是多出約 33%。如果還有每 76 字元換行（MIME 格式），再多一點點。把圖片轉成 Base64 放進網頁雖然少一次網路請求，但檔案變大、也不能被瀏覽器單獨快取，一般只適合很小的圖示。
標準 Base64 和 Base64URL 有什麼差別？
標準 Base64 用 + 和 / 這兩個字元，結尾用 = 補齊長度。但 + / = 在網址裡都有特殊意義，所以 RFC 4648 另外定義了 Base64URL：把 + 換成 -，/ 換成 _，通常也省略結尾的 =。JWT（JSON Web Token）、網址參數、檔案名稱常用這種寫法。本工具編碼時可選標準、Base64URL（不補 =）或 Base64URL（補 =）；解碼時會自動辨識是哪一種，換行與空白也會自動忽略，缺少結尾的 = 也能讀；但 = 出現在中間或超過兩個，會報錯。
解碼後出現亂碼或「不是有效的 UTF-8」，怎麼辦？
有三種常見原因。第一，原始資料根本不是文字，而是圖片、PDF 或壓縮檔，這種請改用「檔案」分頁的「Base64 還原成檔案」來下載。第二，原本的文字不是 UTF-8 編碼（例如舊系統用 Big5 或 GBK），工具只支援 UTF-8，會直接提示無法解讀而不是顯示亂碼。第三，Base64 在複製時被截斷或多了字元，請檢查開頭結尾，以及有沒有被換行或空格切開。
encodeURIComponent 和 encodeURI 要選哪一個？
看你編的是「一個參數值」還是「一整條網址」。encodeURIComponent 會連 ? & = / # : 這些有特殊意義的符號一起編碼，適合用在查詢字串裡的單一值，例如搜尋關鍵字，才不會把值裡面的 & 當成參數分隔。encodeURI 則保留這些符號，只編碼空白、中文等不能直接出現的字元，適合整條網址已經組好、只想處理裡面的中文與空白。把整條網址丟給 encodeURIComponent，會變成 https%3A%2F%2F… 而無法點開，這是最常見的錯誤。
我貼上的文字和檔案會被上傳嗎？
不會。文字、檔案的編碼與解碼全部在你的瀏覽器裡完成，沒有任何內容送到伺服器，也不會被記錄。選擇的檔案只被瀏覽器讀進記憶體處理，關閉頁面後就消失了。
規格與來源
- Base64 與 Base64URL：IETF RFC 4648《The Base16, Base32, and Base64 Data Encodings》（rfc-editor.org/rfc/rfc4648）。
- MIME 每行 76 字元的換行：IETF RFC 2045 第 6.8 節。
- 網址百分比編碼（percent-encoding）與保留字元：IETF RFC 3986《Uniform Resource Identifier (URI): Generic Syntax》。
- encodeURI／encodeURIComponent／decodeURI／decodeURIComponent 的行為：ECMAScript 語言規格（ECMA-262）。
- Data URL：IETF RFC 2397《The "data" URL scheme》。
- 文字轉位元組使用 UTF-8（TextEncoder／TextDecoder，WHATWG Encoding Standard）。