Base64 編碼器

為什麼需要 Base64 編碼？

在網際網路的早期，電子郵件與 HTTP 協定主要是為了傳遞「純文字」而設計的。當我們想要傳送一張圖片、一個 PDF 檔或是任何非文字的「二進位資料 (Binary Data)」時，直接傳送往往會因為編碼解讀錯誤而導致檔案損毀。

Base64 編碼 就是為了解決這個問題而生的。它能將任何二進位檔案（無論是圖片、音訊還是亂碼），轉換為由 64 個安全 ASCII 字元組成的純文字字串。這樣一來，這些資料就可以安全地穿過只支援文字的系統（如 Email 內文、JSON API 或網址列），而不會發生錯誤。

核心原理：3 位元變 4 位元

Base64 的運作方式是將二進位數據每 6 個 bit 切成一組，然後對應到 64 個可列印字元表 (A-Z, a-z, 0-9, +, /)。

代價：體積變大 由於原本 8 bit 的資料被拆解重組，Base64 編碼後的字串長度，通常會比原始檔案大約 33%。這就是為什麼我們不建議將超高解析度的大圖轉成 Base64，因為會造成傳輸負擔。

常見的應用場景

1. 圖片轉 Data URI (前端優化)

前端工程師常將小圖示 (Icon) 轉成 Base64 字串，直接寫在 CSS 或 HTML 的 src 屬性中。

• 格式： data:image/png;base64,iVBOR...

• 好處： 瀏覽器不需要為了載入這張小圖多發送一次 HTTP 請求，能加快網頁載入速度。

2. API 檔案傳輸

JSON 格式不支援二進位數據。

• 如果您要在 JSON API 中傳送檔案（例如上傳大頭貼），必須先將圖片編碼成 Base64 字串，放入 JSON 欄位中 { "avatar": "base64string..." }，後端收到後再解碼還原。

3. Basic Authentication (身分驗證)

在設定 HTTP Basic Auth 時，瀏覽器會將 username:password 進行 Base64 編碼後，放在 Request Header 中傳送給伺服器驗證。

常見問題 (People Also Ask)

Q1：編碼後的字串安全嗎？

不安全，它沒有加密功能。

• 再次強調，Base64 只是「換個寫法」而已。

• 任何人拿到這串 Base64 代碼，都能使用 [Base64 解碼器] 瞬間還原出您的原始圖片或密碼。請勿用它來保護機密資料。

Q2：為什麼編碼結果跟別人不一樣？

可能是文字編碼 (Charset) 不同。

• 對於「中文」字串，使用 UTF-8 編碼與 Big5 編碼轉換出來的 Base64 結果會完全不同。

• 網頁標準通常一律使用 UTF-8。

Q3：URL Safe Base64 是什麼？

• 標準 Base64 包含 + 和 /，這兩個符號在網址 (URL) 中有特殊意義（例如 / 代表路徑）。

• 如果您要把 Base64 字串當作網址參數傳遞，建議勾選 URL Safe 模式，它會將 + 替換為 -，/ 替換為 _，以避免伺服器解析錯誤。

Q4：最大可以處理多大的檔案？

視瀏覽器效能而定。

• 本工具在您的瀏覽器端執行。

• 雖然 Base64 理論上沒有長度限制，但轉換過大的檔案（如幾百 MB 的影片）可能會導致瀏覽器當機。建議用於 10MB 以下的圖片或文件。