選擇語言

Base64 編碼工具:將文字轉為 Base64 字串(支援 URL 安全格式)

即時將文字轉換為 Base64,可選 URL 安全字母表與是否省略填充符號,結果一鍵複製或下載。

Mehmet Demiray 發佈日期 更新日期
分享
在 URL 中使用 - 和 _,並省略 = 填充
每 76 個字元插入一個換行符號

什麼是 Base64 編碼?

Base64 編碼是一種將二進位資料轉換為純文字格式的標準方法,主要用於在僅支援文字的環境中安全傳輸或儲存二進位內容。其名稱源自使用 64 個可列印 ASCII 字元組成的字母表:A–Z、a–z、0–9,再加上「+」和「/」兩個符號(共 62 個),最後以「=」作為填充字元補足長度。這種編碼方式並非加密,僅是資料表示形式的轉換。例如,當你在網頁中嵌入圖片時,常見的 data URI 就會使用 Base64 編碼將圖片轉為文字字串。由於所有現代瀏覽器與伺服器都支援此標準(依據 RFC 4648 規範),它已成為開發者處理二進位資料的通用工具。值得注意的是,Base64 編碼後的資料體積會增加約 33.3%,因為每 3 個位元組的原始資料會被擴展為 4 個字元。若你經常需要在 API 請求中傳遞二進位資料,或處理電子郵件附件,理解 Base64 的基本原理將大有幫助。想還原原始內容?可搭配 Base64 解碼工具 使用。

Base64 編碼的運作原理

Base64 編碼的核心機制在於將每 3 個位元組(共 24 位元)的二進位資料,重新分組為 4 個 6 位元的區塊,每個區塊對應到預定義的 64 字元字母表中的一個字元。由於 6 位元最多可表示 64 種狀態(26=642^6 = 64),正好匹配字母表大小。若原始資料長度不是 3 的倍數,系統會在末尾補零,並以「=」符號標示填充位置——這就是為何你常見到編碼結果以一個或兩個等號結尾。舉例來說,文字「你好」在 UTF-8 編碼下佔用 6 個位元組,經 Base64 轉換後會產生 8 個字元,無需填充;但若輸入「測」(UTF-8 為 3 位元組),則輸出為 4 字元,同樣無填充;而單一字元「A」(1 位元組)則會被補至 4 字元,並以兩個「=」結尾。這個過程完全在瀏覽器內完成,不會將你的資料傳送至任何伺服器。透過 檔案轉 Base64 工具,你也能對整個檔案執行相同邏輯。

標準 Base64 與 URL 安全變體的差異

標準 Base64 使用「+」與「/」作為字母表中的第 62 和 63 個字元,但在 URL 或檔案名稱中,這兩個符號具有特殊意義:「+」在 URL 中代表空格,「/」則是路徑分隔符。若直接將標準 Base64 字串放入網址,可能導致解析錯誤或安全風險。為解決此問題,RFC 4648 定義了「URL 安全」的 Base64 變體,將「+」替換為連字號「-」,「/」替換為底線「_」,同時保留「=」作為填充(儘管部分實作會省略)。例如,標準編碼「a+b/c==」在 URL 安全模式下會變成「a-b_c==」。當你將 Base64 字串用於 JWT(JSON Web Token)、API 查詢參數,或儲存在 Cookie 中時,強烈建議啟用 URL 安全選項。Callculation 的 Base64 編碼工具讓你一鍵切換此設定,確保輸出符合實際應用場景。若需進一步處理網址,也可參考 URL 編碼工具

Base64 編碼的常見應用場景

Base64 編碼廣泛應用於多種技術情境。首先,在網頁開發中,data URI 方案允許將小型圖片、圖示或字型直接嵌入 HTML 或 CSS,避免額外 HTTP 請求,提升載入效率。其次,HTTP 基本身份驗證(Basic Auth)會將用戶名與密碼合併後進行 Base64 編碼,再置於 Authorization 標頭中傳輸(注意:這並非加密,僅防範非刻意窺探)。第三,在電子郵件系統中,MIME 標準使用 Base64 來編碼附件,確保二進位檔案能通過純文字郵件協定正確傳遞。此外,當 JSON API 需要內嵌二進位資料(如縮圖或簽名檔)時,Base64 是最直觀的選擇。在台灣的金融科技或電子發票整合專案中,開發者也常利用此技術處理憑證或 QR Code 資料。由於 Callculation 的 Base64 編碼工具完全在瀏覽器端運作,你的敏感資料不會離開本地裝置,適合處理機密性較高的內容。若需從 Base64 還原檔案,可使用 Base64 轉檔案工具

關於 Base64 編碼的常見疑問

許多使用者誤以為 Base64 是一種加密技術,事實上它僅是編碼(encoding),不提供任何安全性——任何人都能輕易解碼還原原始內容。若需保密,應搭配 AES 或 RSA 等真正加密演算法。第二,Unicode 文字(如中文、日文)如何正確編碼?Base64 本身只處理位元組,因此工具會先將輸入文字以 UTF-8 編碼轉為位元組序列,再進行 Base64 轉換,這是國際標準做法,確保跨平台相容性。第三,何時該使用 URL 安全變體?只要編碼結果會出現在 URL、檔案名、HTML 屬性或 Cookie 中,就應啟用此選項,避免特殊符號引發解析問題。最後,為何輸出結尾有「=」?這是填充機制:當原始資料長度除以 3 餘 1 時,補兩個「=」;餘 2 時,補一個「=」;整除則無填充。這些細節雖小,卻影響系統穩定性。若你經常處理編碼任務,不妨收藏本工具,並搭配 Base64 解碼功能 交替使用,提升開發效率。

最常被問到的問題

Base64 編碼是加密嗎?

不是。Base64 只是一種將二進位資料轉換為文字格式的編碼方式,目的是方便在文字系統(如電子郵件或 JSON)中傳輸資料,並非用來保護內容安全。任何人都能輕易解碼還原原始資料,若需保密應使用真正的加密方法。

為什麼我輸入中文或其他 Unicode 文字也能正確編碼?

本工具會先將您輸入的文字以 UTF-8 編碼轉為位元組序列,再進行 Base64 編碼。這符合 RFC 4648 標準,確保所有 Unicode 字元(包括繁體中文、日文、表情符號等)都能正確處理,且全程在瀏覽器內完成,不會上傳到伺服器。

什麼情況下該使用「URL-safe」版本的 Base64?

當您要將 Base64 字串放入網址、查詢參數或檔案名稱時,應啟用 URL-safe 選項。標準 Base64 使用的「+」和「/」在 URL 中有特殊意義,可能導致解析錯誤;URL-safe 版本會改用「-」和「_」,避免此問題。例如用於 JWT token 或 API 查詢參數時就非常適合。

為什麼編碼結果末尾會出現一個或兩個「=」?

這是填充(padding)符號。Base64 以每 3 個位元組為一組轉成 4 個字元,若原始資料長度不是 3 的倍數,就會在末尾補「=」使輸出長度為 4 的倍數。一個「=」表示缺 1 個位元組,兩個則表示缺 2 個。某些應用(如 JWT)會省略填充,您可勾選「省略填充」選項來配合需求。

編碼後的字串一定比原文長嗎?

是的。Base64 編碼會使資料膨脹約 33.3%(精確來說是每 3 位元組變成 4 字元,即增長因子為 4/3)。這是將二進位資料轉為純文字所付出的代價,但換來的是在文字協定中安全傳輸的能力。

如何將 Base64 字串還原回原文?

您可以使用我們的 Base64 解碼工具,貼上編碼後的字串即可還原原始文字。若當初使用了 URL-safe 或省略填充選項,解碼時也需對應調整設定,才能正確還原。

這個工具會把我的資料傳到伺服器嗎?

完全不會。Base64 編碼過程全部在您的瀏覽器中執行,資料從未離開您的裝置。這保障了隱私與安全性,特別適合處理敏感資訊或內部測試資料。