在 Windows 上把檔案轉換成 Base64，指的是透過瀏覽器的 File API 讀取本機檔案的確切位元組，並輸出一段符合 RFC 4648 標準、由 A–Z、a–z、0–9、加號、斜線與等號組成的正規字串，不含 data URL 前綴、不含 MIME 標頭，也不做換行包裝。在 Windows 電腦上，並沒有內建的右鍵選單、沒有「設定」面板，也沒有一行 PowerShell 指令可以直接拿任意二進位檔案，產出一段可以直接貼進 JSON、YAML、Postman 主體，或 API 欄位的正規、含補位的 Base64 字串。certutil -encode 雖然能印出 Base64，但輸出的是包了行的 MIME 風格內容；而 PowerShell 的 [Convert]::ToBase64String，只能處理你自己已經先載入好的位元組陣列。對於最大到 10 MB 的檔案，最簡單的 Windows 作法，就是打開一個瀏覽器版的檔案轉 Base64 轉換工具，選取檔案，然後複製完整輸出結果。
為什麼 Windows 沒有原生的檔案轉 Base64 指令
Windows 檔案總管可以顯示檔案內容摘要、用 Get-FileHash 對檔案做雜湊，也能把檔案打包成 ZIP 壓縮檔，但它從來沒有內建過能把任意二進位檔案轉成正規 Base64 字串的指令。最接近的幾個選項，各自都有不同的不足之處。
最經典的替代方案是 certutil -encode。它能讀取檔案並印出 Base64，但輸出內容會以 CRLF 換行，包成每行 76 個字元，並用類似 -----BEGIN CERTIFICATE----- 的標頭標記——這是 MIME 包裝格式，而不是大多數 API 與設定檔所預期的那種正規、含補位的字串。PowerShell 的 [Convert]::ToBase64String，只能處理你早已載入到記憶體中的位元組陣列，所以你得自己先寫好讀取、編碼與輸出的流程，這個函式才能產出有用的結果。Windows 11 新增了開發人員模式的檔案檢視器，但它顯示的是十六進位傾印，而不是 Base64。
對於只是單純想把一段 Base64 內容貼進 JSON 主體、YAML 錨點、環境變數，或程式碼片段的使用者來說，這個落差很重要。本機瀏覽器工具能完全繞過缺少的命令列指令：打開頁面、把檔案選擇器指向那個檔案，然後複製正規輸出結果。以下是這個轉換工具接受與拒絕內容的快速對照：
| Base64 變體 | 範例標頭或標記 | 轉換工具是否接受？ |
|---|---|---|
| 正規、含補位的 RFC 4648 §4 | 「Man」對應的 TWFu | 是——解碼器唯一接受的形式 |
| Base64url RFC 4648 §5 | 用 - 與 _ 取代 + 與 / | 否——請先明確轉換 |
| MIME 換行包裝 | 每行 76 個字元、以 CRLF 結尾 | 否——貼上前請先去除空白字元 |
| Data URL | data:image/png;base64,... | 否——只有在你清楚其結構時才移除前綴 |
| 省略補位 | 標準字母表，但沒有結尾的 = | 否——請補回所需的等號 |
用白話文說明 RFC 4648 正規 Base64
這個說法很精確。正規的 RFC 4648 Base64 使用 A–Z、a–z、0–9、+ 與 / 這套字母表，把每三個來源位元組分成一組，轉成四個輸出字元，並在最後一組只剩一或兩個位元組時，加上一或兩個 = 符號。它不包含換行、MIME 標頭、data: 前綴或檔名——那些屬於必須在解碼前先移除的獨立容器格式。
每三個位元組會對應到恰好四個可列印字元；補位則是為了處理不完整的最後一組。因此，如果一個檔案最後剩下一個位元組，就會產生一個最後兩個字元是 = 的四字元結尾組。如果一個檔案最後剩下兩個位元組，就會產生一個最後一個字元是 = 的結尾組。RFC 4648用七組測試向量鎖定了這些規則——空字串、f、fo、foo、foob、fooba 與 foobar——而這個轉換工具會針對這些向量，加上一段會用到 + 與 / 字元的位元組序列，驗證雙向轉換的正確性。
這個編碼器也會保留數值為零的未使用補位位元。這些位元中的任何偏差，在解碼時都會產生不同的位元組序列，所以這個轉換工具會拒絕非正規的寫法，而不是默默接受它們。
在 Windows 上把本機檔案轉換成 Base64
對於最大到 10 MB 的檔案，實務上的 Windows 作法完全可以靠瀏覽器完成。
- 在 Windows 機器上，用 Edge、Chrome、Firefox 或任何現代瀏覽器打開檔案轉 Base64 轉換工具。
- 確認頁面處於「File → Base64」模式（預設模式），然後按一下檔案選擇器。
- 選取一個最大 10 MB 的本機檔案；瀏覽器的 File API 會透過 arrayBuffer 讀取確切的位元組，且絕不會把它們上傳出去。
- 等待輸出區呈現出正規、含補位的字串。
- 確認選擇器旁顯示的檔名與大小，與你想要的檔案一致。
- 按一下複製，然後把完整文字貼到你的目標位置——一個 JSON 欄位、一個 Postman 主體、一個 YAML 區塊，或一段程式碼片段。
複製出來的輸出結果只包含 Base64 字元與補位符號，不含 data: URL 前綴、MIME 標頭、換行包裝，或檔名。只有在目標應用程式明確要求時，才加上這些容器內容。
在 Windows 上把 Base64 解碼回檔案
反方向的操作，遵循同樣的瀏覽器分頁流程。
- 把檔案轉 Base64 轉換工具切換到「Base64 → File」模式。
- 如果你手上的字串是包裝過的（Base64url、MIME 換行，或 data URL），請先依照它的規格把包裝去掉，讓轉換工具收到的是不含任何空白字元的純標準 Base64。
- 把正規、含補位的字串貼進輸入欄位。
- 設定與你實際預期格式相符的正確檔名與 MIME 類型——不要單靠 Base64 字元去猜，因為這個欄位不會檢查位元組內容。
- 按一下解碼；頁面會在目前分頁中建立一個暫時的 Blob URL。
- 按一下下載，把檔案存到一個你知道位置的資料夾。
這個 Blob URL 只存在於瀏覽器工作階段中。當你開始新的一次轉換，或關閉頁面時，這個 URL 就會被撤銷，這樣過時的下載內容就不會在記憶體中持續累積。
驗證結果並抓出錯誤
即使解碼器再嚴謹，你所復原出來的檔案，其可信度也取決於來源字串以及你套用的標籤。在 Windows 上，有幾個檢查點能抓出大多數的錯誤。
- 用能原生處理其宣告格式的應用程式——PDF 閱讀器、圖片檢視器、音訊播放器——打開下載下來的檔案，確認格式正確無誤。
- 在 PowerShell 中用 Get-FileHash <path> -Algorithm SHA256 計算雜湊值，並在有原始傳送者公布的雜湊值可比對時，拿來相互核對。
- 絕不要假設你輸入的副檔名或 MIME 欄位真的與位元組內容相符。下載按鈕只會用它們來產生下載建議名稱與 Blob 媒體類型；它們不會轉碼、掃描，或解讀內容。
- 如果這個轉換工具拒絕了你的輸入，最常見的元兇是多餘的空白字元、缺少的 = 補位符號，或使用了以 - 與 _ 取代 + 與 / 的 Base64url 字母表。
10 MB 的上限是有原因的：位元組陣列、Base64 字串，以及呈現出來的輸出結果，會同時全部存在於瀏覽器記憶體中。把一個 10 MB 的檔案編碼，會產生大約 13,333,336 個字元——取 10,000,000 位元組，除以三得到 3,333,333 個完整的組，乘以四得到 13,333,332 個字元，再為那個只剩一個位元組、需要補位的最後一組加上四個字元。對於更大的檔案，請改用命令列或應用程式的工作流程，因為這個工具不會默默截斷輸入，也不會針對格式不正確的輸入產生一個殘缺的下載連結。
超過 10 MB：指令碼與命令列工作流程
這個瀏覽器工具很適合用於 10 MB 上限以內的單次轉換，也適合任何你希望位元組資料留在本機 Windows 機器上的情境。超過這個限制之後，情況就不同了。
對於更大的檔案、批次工作，或已經存在於建置系統中的流程，請改用 PowerShell、Python 或 Node，並以串流方式分區塊處理 Base64，而不是把整份資料全部緩衝在記憶體中。編碼方式仍然是同一套正規的 RFC 4648 輸出——這個轉換工具只是把演算法放在瀏覽器分頁裡執行，而不是放在指令碼裡，所以你在本機編碼與解碼出來的位元組，應該與一個行為正確的指令碼所產出的結果逐位元組相符。
對於涉及隱私的檔案，邊界就是你自己的機器。瀏覽器透過 File API 讀取檔案內容，絕不會把內容、檔名，或 MIME 類型傳送到伺服器。但瀏覽器擴充功能、剪貼簿管理員、下載檔案處理程式，以及你把輸出結果貼進去的任何地方，仍然都在這個邊界之外，所以請避免在共用或不受信任的 Windows 裝置上使用這個轉換工具。
最後，請記住 Base64 能做什麼、不能做什麼。它是一種編碼——任何人都能還原——而不是加密、雜湊、簽章、壓縮、清理，或防毒掃描。一段 Base64 字串仍然可能夾帶惡意程式、私人資料，或可執行的位元組內容。請用對待來源檔案同等的謹慎程度來看待它，尤其是當你把它貼進工單、日誌、原始碼儲存庫，或分析儀表板時，因為那些地方能看到它的人，可能比原始二進位檔案還多。
延伸閱讀：Base64 轉檔案：把字串解碼成可下載的檔案。