Base64 會把 Mac 上的任何檔案轉成單一可列印的 RFC 4648 字元字串，每三個輸入位元組正好對應四個輸出字元，結尾的等號會補滿最後一組，而瀏覽器版的檔案轉 Base64 轉換器完全在 Safari 或 Chrome 內執行這個轉換，不會把檔案傳送到任何地方。

這在 macOS 上很重要，因為大多數工作流程會接觸到的其他介面——剪貼簿、記錄檔、工單附件、原始碼儲存庫，以及 HTTP 標頭——都能讀取或儲存純文字，但無法直接承載任意二進位內容。將位元組包裝成 Base64 是把 PNG、PDF、字型或小型私密金鑰推送通過只能理解文字的管線的標準做法。關鍵在於精確無誤:每個位元組都必須在來回轉換後完整保留，包括零值、換行字元，以及在文字編輯器中看起來像亂碼的位元組序列。這正是正統的 RFC 4648 Base64 所強制執行的要求，也是大多數 API 與通訊協定能毫無異議接受的唯一形式。

檔案轉 Base64 轉換器工具透過 W3C File API 從本機檔案讀取精確的位元組，使用標準字母集進行編碼並加上必要的等號填補，產生的文字區塊不含任何其他內容:沒有 data URL 前綴、沒有 MIME 標頭、沒有換行、沒有檔名中繼資料。反向操作方面，同一個頁面接受正統的 Base64，讓使用者選擇檔名與 MIME 類型，然後在目前的分頁中產生一個暫時的 Blob 下載。由於所有位元組都留在載入的頁面內，因此不涉及上傳步驟，任何第三方服務都無法看到內容。接下來的指南會逐步說明編碼實際做了什麼、為何本機瀏覽器工具能與 macOS 內建的終端機方式抗衡、在 Mac 上轉換檔案的具體步驟，以及防止在還原成檔案過程中發生靜默錯誤的嚴格規則。

convert file to base64 in mac
在 Mac 上將檔案轉成 Base64 而不上傳

編碼如何將位元組對應到字元

RFC 4648 將 Base64 定義為 64 個可列印字元的標準字母集再加上一個填補字元。從輸入中取出三個位元組會得到 24 個位元，這 24 個位元可以整齊地分成四組各 6 個位元。每組 6 位元會從字母集中索引出一個字元，所以三個輸入位元組必定產生四個輸出字元。當最後一組輸入只含一個或兩個位元組時，只有有意義的位元會進入最後一個字元，其餘位置則由等號填補。空輸入會產生空輸出;一個位元組會產生兩個字元加兩個等號;兩個位元組會產生三個字元加一個等號。編碼器會保留每個位元組，包括零值以及不是有效文字的位元組，並不會對換行字元做標準化處理、轉換影像資料的編碼，或移除中繼資料。

正統的測試向量「fo」以一個不含十進位數字的計算說明這些規則。這些位元組是 0x66 (01100110) 與 0x6F (01101111)。串接起來會形成 0110011001101111，這是一個 16 位元的字串，必須在尾端補上兩個零位元，才能湊成 6 的倍數:011001100110111100。切分成 6 位元一組後得到 011001 (25)、100110 (38) 與 111100 (60)。標準字母集中索引 25 是 Z，索引 38 是 m，索引 60 是 8。由於原始輸入是兩個位元組，需要一個等號來完成最後一組，所以結果是四個字元的字串「Zm8=」。對照 RFC 4648 公布的測試向量可驗證此計算無誤，同樣的程序可應用於任何大小的檔案而不需改變規則。

瀏覽器與 macOS 終端機的比較

macOS 多年來一直內建 /usr/bin/base64，其 BSD 版本可直接從殼層進行編碼與解碼。Safari 或 Chrome 中的瀏覽器分頁則是另一個介面，兩者之間的權衡取捨值得在選擇工作流程前先說清楚。

面向 macOS 終端機 (base64) Mac 上的瀏覽器工具
位元組的處理位置 本機殼層程序;結果會落入你掌控的檔案或管線中 目前的 Safari 或 Chrome 分頁;不會發出任何網路請求
輸出格式 標準 RFC 4648，預設無換行;-b 76 會加上換行;-i 可讀取檔案參數 正統的 RFC 4648，含必要的填補，無 data URL、無換行、無 MIME 標頭
大小上限 受限於可用磁碟空間與殼層記憶體;沒有固定的上限 來源檔案與解碼後檔案均為 10 MB;較大的輸入會在一開始就被拒絕
解碼的嚴格度 對空白字元較寬鬆，某些 BSD 版本可能接受缺少填補的輸入 嚴格:會拒絕空白字元、缺少的填補、非零的未使用填補位元，以及任何非正統的字母集
檔案格式檢查 無;編碼器會完整保留磁碟上原始的位元組 無;編碼器會完整保留從選定檔案讀取的原始位元組
反向操作 將 Base64 重新管線傳送給 base64 -d(較舊的 macOS)或 base64 -D(較新版本)再寫入檔案 貼上正統的 Base64、設定檔名與 MIME 類型，然後下載一個暫時的 Blob URL
剪貼簿整合 pbpaste 與 pbcopy 可在殼層與其他應用程式之間移動文字 頁面上的複製按鈕會將編碼後的字串寫入 macOS 剪貼簿
是否需要網路 否 否，頁面載入完成後即不需要

終端機路線非常適合指令稿批次作業與串流處理非常大的檔案。瀏覽器路線則較適合臨時性的轉換，目標是產生一段乾淨的正統字串，以便貼到聊天對話、API 測試工具、Postman 請求或說明文件頁面中，而且 10 MB 的上限足以涵蓋實際要處理的檔案大小。

使用 Safari 或 Chrome 在 Mac 上將檔案轉成 Base64

編碼方向會從本機檔案讀取精確的位元組，並產生一個正統的 Base64 字串。W3C File API 透過 arrayBuffer 將檔案公開給頁面，因此即使包含零值、嵌入的空位元組或非文字位元組，頁面也能在不重寫的情況下處理。在 macOS 上的具體步驟如下:

  1. 在 Safari 或 Chrome 中開啟檔案轉 Base64 轉換器頁面;確認頁面已完全載入，讓 JavaScript 在本機分頁中執行。
  2. 將模式維持在「檔案轉 Base64」，然後從 Finder 中的任何位置選擇來源檔案，包括 iCloud 雲碟、外接 SSD、USB 隨身碟或下載項目資料夾中的項目。
  3. 將頁面上顯示的檔名與位元組大小與磁碟上的實際檔案進行核對，因為選到什麼就會完整讀取什麼。
  4. 觸發轉換，並等待編碼後的文字欄位填入完整的輸出，包括大小不是 3 的倍數之檔案在結尾的等號填補。
  5. 從頁面複製該字串，然後貼到目標目的地，例如 JSON 承載、curl 指令、Markdown 片段或程式碼審查中。
  6. 請記住，Base64 只做編碼，並不會掃描、加密、雜湊、簽署或清理內容，因此應以與來源檔案相同的敏感度來對待產生的字串。

複製出來的輸出只包含 Base64 字元與填補。它不含 data URL 前綴、MIME 標頭、換行或檔名。只有在目標應用程式明確需要這些容器時才加上，因為大多數嚴格的解碼器會把這些外層包裝視為格式錯誤的輸入而拒絕。

將 Base64 解碼回檔案

反向操作接受一個正統的 Base64 字串，並將其轉回可下載的位元組。解碼器以相反方向強制執行相同的字母集規則，並在產生暫存檔之前重新編碼結果，以拒絕其他非正統的拼法。在 macOS 上解碼的步驟如下:

  • 將 Base64 字串貼到輸入區，不要包含任何周圍的空白、換行或 data URL 前綴。
  • 設定想要的檔名(只會影響建議的下載名稱)與 MIME 類型(只會影響 Blob 的媒體類型);位元組本身維持原樣。
  • 執行解碼;成功時，頁面會在目前瀏覽器工作階段中產生一個暫時的下載連結，當新的轉換取代它時便會撤銷。
  • 透過瀏覽器一般的下載流程儲存檔案，通常是 Safari 的下載面板或 Chrome 視窗底部的下載列。
  • 使用擁有該格式的應用程式開啟產生的檔案，以確認內容看起來正確，而不是單獨依賴檔名或 MIME 值來判斷。

若需要對解碼方向有更深入的說明，實用編碼指南涵蓋了相同的流程並補充了更多邊界情況。

反向操作的嚴格性規則

解碼器在設計上就是嚴格的。輸入必須使用含有加號與斜線的標準字母集、包含必要的等號填補、不含任何空白字元，且未使用的填補位元必須為零。任何偏差都會產生錯誤而非部分檔案，這在輸出必須與原始位元組完全一致時是正確的行為。共有四類常見的承載內容在貼上前必須先轉換:

  • Data URL，例如 data:image/png;base64,...，需要去除前綴與任何結尾的空白;只有正統的 Base64 部分會留下。
  • Base64url 會將加號與斜線替換成減號與底線，並通常省略填補;在貼上前請轉換回標準字母集並補上等號。
  • 以 MIME 包裹的 Base64 會每隔 76 個字元插入換行;在貼上前請移除字串中所有的 CRLF 或 LF。
  • 省略填補的形式會省略結尾的等號;請將其補回，讓最後一組剛好是四個字元寬。

兩個方向都會以 RFC 4648 的 empty、f、fo、foo、foob、fooba 與 foobar 測試向量進行驗證，另外還包括一組會用到加號與斜線字元的位元組序列，以及含有空白、缺少填補與非零填補位元的負面測試案例。如 RFC 4648 規範所述，這些向量釐清了正確的行為，並讓工具能在格式錯誤時拒絕輸入，而非產生出部分解碼的檔案。

Validating the Output and Recognising Hidden Traps

The 10 MB ceiling is a hard boundary, not a soft warning, and exists because the byte array, the Base64 string, and the rendered output can coexist in browser memory. Encoding increases text size by roughly one third, so a 7.5 MB file produces a string around 10 MB, which is the working ceiling for casual encoding inside a tab. Very large files belong in streaming command-line or application workflows rather than the browser. The temporary Blob URL is revoked automatically when a new conversion replaces it or when the page closes, which keeps obsolete in-memory downloads from piling up during normal use.

The filename and MIME type fields on the decode direction do not inspect the bytes. A misleading extension or MIME value can confuse whichever application opens the file next, so use values appropriate for the known format rather than guessing from Base64 alone. For integrity checks, compute a cryptographic hash such as SHA-256 against the source file and again against the downloaded result, and confirm the two digests match before assuming fidelity. Treating the encoded string with the same care as the source file matters because Base64 is reversible, can expose recognizable content in logs, tickets, source code, and analytics, and offers no protection against anyone who decodes it.

For a deeper look, see Gzcompress Online on Mac: Run It in Safari or Chrome.