將檔案轉換為 Base64 格式，意思是讀取檔案的精確位元組，並將其改寫成一串取自 RFC 4648 標準帶填補字元的可列印 ASCII 字元，包含 A–Z、a–z、0–9、加號和斜線。每三個輸入位元組會變成四個輸出字元;當檔案的位元組數不是 3 的倍數時，會以一個或兩個等號填補最後一組，讓輸出長度永遠是 4 的倍數。檔案轉 Base64 轉換器會在您目前的瀏器分頁內於本地執行此轉換:選擇一個不超過 10 MB 的檔案，覽器的 File API 會將其讀取為 ArrayBuffer，工具接著輸出完整的標準帶填補字串，不包含 data URL 前綴、MIME 標頭，也不進行換行。複製的輸出內容僅包含 Base64 字元與必要的等號，可直接貼到任何接受標準帶填補 Base64 的位置。編碼器會逐位元組完整保留來源檔案中的每一個位元組，包括零位元組與超出可列印 ASCII 範圍的值，而不會檢查檔案格式、正規化行尾、轉碼影像，或解讀中繼資料。
「Base64 格式」實際上規定了什麼
大多數 API、設定檔、JSON 承載和 HTTP 標頭所引用的標準「Base64」，指的是 RFC 4648 中帶填補的標準字母表:26 個大寫字母、26 個小寫字母、0 到 9 的數字、加號字元，以及正斜線，並以一個或兩個尾端的等號將輸出補足為 4 的倍數。RFC 4648 在第 4 節定義了這個字母表，並提供七個測試向量——空輸入加上字串「f」、「fo」、「foo」、「foob」、「fooba」和「foobar」——任何符合規範的編碼器與解碼器都必須能處理這些向量。該規格也禁止非標準的拼寫方式:編碼器不得以其他字元替代加號或斜線，解碼器則必須拒絕與標準輸出不一致的輸入。當讀者詢問如何將檔案轉換為 Base64 格式時，他們幾乎總是指這個精確的、帶填補的標準形式，因為這正是幾乎所有程式語言、Web API 與設定檔解析器預期接受的格式。
一個簡單的對照可以清楚說明填補規則。三個 ASCII 位元組「foo」(0x66 0x6F 0x6F)編碼為 Zm9v，因為輸入已經是 3 位元組的倍數，所以不需要填補。雙位元組字串「fo」(0x66 0x6F)編碼為 Zm8=，使用一個等號;單位元組字串「f」(0x66)則編碼為 Zg==，使用兩個等號。工具的編碼器對檔案中的每一組位元組都套用同樣的三對四對應規則，接著視需要以零、一個或兩個等號填補最後一組。
為什麼要將檔案轉換為 Base64 格式
將檔案轉換為 Base64 格式，可以讓二進位位元組透過僅接受文字的通道傳輸。JSON、XML、YAML、原始碼以及大多數設定檔都無法容納原始的 NUL 位元組或任意的位元組序列，但它們可以容納一長串安全的 ASCII。電子郵件附件也基於相同理由使用 Base64 內容傳輸編碼。CSS 與 HTML 可以將影像和字型以 Base64 作為承載內容嵌入 data URI。當無法使用 multipart 上傳時，REST API 常會在 JSON 請求主體中要求提供檔案的 Base64;而 JWT 則將其標頭與承載內容以 Base64url 形式傳遞。
當您在原始碼中嵌入二進位資料、貼到設定值中，或透過 JSON 承載傳送時，接收端必須取回完全相同的位元組。Base64 確實能勝任這項工作——它會逐位元組完整保留資料——但它並不會讓位元組變得私密、加上簽章、進行壓縮或掃描內容。任何收到該字串的人，都能一步將其解碼回原始檔案。對於本身已包含敏感內容的檔案，請以與來源檔案相同的敏感程度來對待 Base64 結果，並思考接收端是否真的需要透過文字通道傳遞這些位元組。
如果您也需要一份強調隱私界線的獨立操作指南，可以參考 無需上傳即可將任何檔案轉換為 Base64，其中提供了對應的不上傳工作流程。
使用本地工具將檔案轉換為 Base64 格式
在桌面瀏器上將檔案轉換為 Base64 格式最直接的方式，就是使用檔案轉 Base64 轉換器。處理過程完全在目前分頁內進行，工具絕不會上傳您的檔案。請依照下列步驟操作:
- 在新分頁中開啟檔案轉 Base64 轉換器，並確認網頁使用的是 HTTPS，以便能使用 W3C File API 與 Blob 下載功能。
- 點擊檔案選擇器，挑選任何不超過 10 MB 的本機檔案。網頁會將該檔案的位元組讀取為 ArrayBuffer;檔案名稱、類型與內容都會保留在瀏覽器中。
- 確認網頁上顯示的檔案名稱與大小，確保您在編碼之前挑選到正確的檔案。
- 點擊編碼動作，等待工具執行完畢。輸出的結果會是一個不帶 data URL 前綴、不含 MIME 標頭、也不換行的單一標準帶填補 Base64 字串。
- 複製完整的輸出內容，包括結尾的所有等號。只複製部分字串是導致下游解碼失敗的常見原因。
- 將字串逐字貼到目標位置——例如 JSON 欄位、設定值或原始碼字面值——只有當目標明確定義該容器時，才加上 data URL 前綴或 MIME 標頭。
將 Base64 解碼回可下載的檔案
同一個工具也能反向執行轉換。貼上不含空白的標準 Base64，設定一個與您實際預期的檔案格式相符的檔名與 MIME 類型，然後解碼。網頁會先驗證字母表、等號以及未使用的填補位元，才會產生一個暫時的 Blob URL 供下載。檔名控制建議的下載名稱，MIME 欄位控制 Blob 的媒體類型，但這兩個欄位都不會檢查位元組——您可以將 PNG 標記為 application/json，工具仍會愉快地將 PNG 位元組寫入 JSON 檔案。請使用與您確知正在解碼的檔案格式相符的副檔名與 MIME 值，並透過以適當的應用程式開啟結果，或對位元組進行雜湊運算並與預期摘要比對來加以驗證。
由於解碼器會將解碼後的位元組重新編碼，並與輸入進行比對，因此非標準的拼寫方式(例如以句點代替加號)會被拒絕，而不是被默默接受。包含空白、缺少填補字元，或填補位元不為零的輸入，絕對不會產生部分下載連結。這種嚴格的行為至關重要，因為鬆的瀏器解碼器可能會隱藏格式錯誤的輸入，而這類輸入稍後會在伺服器端解析器中失敗。當新的轉換取代它，或元件關閉時，暫時的 Blob URL 會被撤銷，以避免在正常使用過程中累積過時的記憶體下載。
Base64 格式變體及其差異
並非所有「Base64」字串都能互換。RFC 4648 標準形式使用加號與斜線，並需要等號填補。Base64url 則將這兩個字元分別換成連字號與底線，並省略填補，因此其結果可直接放入 URL 或檔名中，無需進行百分比編碼。MIME 包裝的 Base64 會每 76 個字元插入一個 CRLF，以便用於電子郵件傳輸。Data URL 則以 data:image/png;base64，這類前綴包裹 Base64，後面接承載內容。每一種變體各自適用於不同的通道，把錯誤的變體貼到錯誤的目的地，是解碼失敗最常見的原因。
| 變體 | 字母表 | 填補 | 換行 | 典型用途 |
|---|---|---|---|---|
| 標準形式 (RFC 4648) | A–Z a–z 0–9 + / | 必要 (= 或 ==) | 無 | JSON、XML、原始碼、REST API |
| Base64url | A–Z a–z 0–9 - _ | 省略 | 無 | URL 路徑、查詢值、JWT |
| MIME 包裝 | A–Z a–z 0–9 + / | 必要 | 每 76 字元一個 CRLF | 電子郵件附件 (RFC 2045) |
| Data URL | A–Z a–z 0–9 + / | 必要 | 無 | data: 前綴 + MIME + 承載內容 |
由於檔案轉 Base64 轉換器僅輸出帶填補的標準形式，您必須先明確轉換 Base64url、MIME 包裝以及 data URL 形式的輸入，才能進行解碼。如果您的承載內容以 data:image/png;base64 開頭，請在貼上前先移除該標頭以及任何結尾的空白。純文字「f」在標準形式中會變成 Zg==，但在 Base64url 中則是 Zg,JWT 解碼器會拒絕帶填補的版本。
導致嚴格 Base64 解碼失敗的陷阱
即使是微小的格式錯誤，也會導致嚴格的解碼器拒絕輸入。最常見的陷阱包括:
- 從聊天程式、工單系統或經格式化的 JSON 美化器中複製時夾帶了空白或換行。
- 等號被編輯器或長度有限的輸入欄位截斷。
- Data URL 前綴未被移除，因為發送方假設解碼器會自行處理。
- MIME 換行的 CRLF 被解碼器視為無效字元。
- 加號被 URL 表單或傳輸層悄悄轉換成空格。
- 使用不同字元表示加號或斜線字碼點的非標準拼寫方式。
- 填補長度與剩餘位元組數不符，導致留下非零的未使用填補位元。
一旦發生上述任何錯誤，嚴格的解碼器會拒絕產生下載連結，而不是默默產生損毀的位元組。修正方式是先辨識您實際持有的變體，若為 data URL 則移除容器，接著正規化行尾、還原填補長度，然後重新提交。那些用來防範這些陷阱的檢查，同樣能防止標準編碼器意外輸出非標準的結果。
在信任輸出之前進行驗證
由於 Base64 是可逆的，唯一能確認轉換是否完整保留檔案的方式，就是將字串解碼並與原始檔案進行比對。以原生支援該格式的應用程式開啟解碼後的檔案——例如以影像檢視器開啟 PNG、以閱讀器開啟 PDF、以媒體播放器開啟 MP3——以確認位元組完好無損。若需要更強的保證，可以分別對來源檔案與解碼後的結果進行 SHA-256 雜湊運算並比對摘要;僅僅一個位元組的差異，就會讓輸出中的每一個位元都改變。
請確認 Base64 長度符合預期的膨脹比例:N 位元組的檔案大約會產生 4 × ceil(N / 3) 個輸出字元，也就是說編碼會讓大小增加大約三分之一。明顯較短的輸出通常代表輸入被截斷，明顯較長的輸出則通常代表您不小心貼上了 data URL 或其他容器。將檔案編碼為 Base64 格式並無法保護檔案安全。該字串完全可逆，任何能讀取的人都能還原其底層內容。當目標是機密性時，它無法取代加密;當目標是防竄改時，它也無法取代雜湊。請以與來源檔案相同的敏感程度對待 Base64 字串，並避免將其貼到他人可以閱讀的記錄檔、工單或分析工具中。