SVG 轉 Base64 轉換器在線上使用是否安全，取決於該工具是否將來源文件保留在當前的瀏覽器分頁內、是否在套用 Base64 之前將 Unicode 編碼為 UTF-8，以及是否絕不渲染、執行或悄悄改寫 SVG。安全性並非這種格式的內建特性：Base64 是一種由 RFC 4648 定義的二進位到文字表示法，編碼只改變位元組在傳輸線上的書寫方式。腳本、事件處理常式、外部內容、外部參考以及其他主動行為皆能在來回轉換中完整留存，這表示對於任何線上工具，應該問的問題並非「Base64 是否能淨化 SVG」，而是「這個特定實作是否上傳、渲染或修改了來源，以及它是否能逐位元組保留非 ASCII 文字」。
不安全轉換器的風險可分為三個類別。第一個是傳輸：伺服器端工具會將 SVG 作為請求的一部分接收，因此文件會離開瀏覽器並存留在他人的基礎設施、記錄、快取或備份中。第二個是解譯：許多線上 SVG 工具同時也是預覽工具，而 SVG 可能包含 <script> 標籤、onload 處理常式、會擷取資源的 CSS 動畫，以及指向外部樣式表的連結；任何在轉換完成前就執行這些功能的預覽，都會讓該頁面成為您無意執行之程式碼的宿主。第三個是資料完整性：以 Latin-1 處理 JavaScript 字串的轉換器，一旦對非 ASCII 字串呼叫瀏覽器的經典 btoa()，就會悄悄損壞重音字元、CJK 文字、表情符號和從右到左標記，產生解碼後與原始文件不符的資料 URL。
對 SVG 轉 Base64 轉換器而言，「安全」實際上代表什麼
對於這類工具而言，安全性是一小組可驗證的行為，而非行銷話術。一個安全的 SVG 轉 Base64 轉換器應該：
- 完全在瀏覽器分頁中處理文件，使 SVG 與產生的資料 URL 從不離開使用者的機器。
- 在轉換過程中拒絕預覽或渲染 SVG，因為渲染是腳本與事件處理常式得以執行的途徑。
- 在 Base64 編碼之前將 Unicode 文字編碼為 UTF-8 位元組，使非 ASCII 字元能精確地來回轉換。
- 在解碼時嚴格驗證 UTF-8，使格式錯誤的來源位元組序列產生錯誤，而非被悄悄改寫的文件。
- 兩側都接受範圍狹窄、有完整定義的輸入：編碼時是完整的 <svg> 文件，解碼時則是精確的 data:image/svg+xml;base64，資料 URL。
這些特性沒有一項是由「Base64」這個詞所隱含的。一個會上傳 SVG、預覽 SVG，或為 Unicode 使用 Latin-1 後備方案的工具，即使產生看起來像資料 URL 的字串，仍以不同方式構成不安全。
為何 Base64 編碼並非淨化
Base64 是一種編碼，而非過濾器。來源文件的每個位元組——包括 <script> 標籤、onclick 屬性、對外部資源的參考，以及 <foreignObject> 內容——都會在來回轉換中存活，並在資料 URL 解碼時重新出現。一旦資料 URL 被放入 <iframe>、<object>、以 SVG 為來源 <img> 的元素、CSS 的 background-image 宣告，或直接插入 DOM，決定哪些程式碼會執行的就是消費端的內容安全政策與嵌入情境，而非編碼本身。
這很重要，因為多數「SVG 轉 Base64」的搜尋結果在描述輸出時，都假設嵌入是無風險的。資料 URL 只是書寫同樣位元組的另一種方式。如果來源 SVG 以檔案形式提供時具有危險性，那麼以資料 URL 內嵌時同樣具有危險性，目的地需要與對待任何不受信任的 SVG 相同的防護：維護良好的淨化流程，以及為該情境設計的嵌入政策。僅靠編碼本身並無法提供任何保護。
UTF-8 處理是具體的安全與正確性問題
瀏覽器端轉換器中最常見的隱性失敗，是將 JavaScript 字串視為 Latin-1。經典的瀏覽器輔助函式 btoa() 處理的是碼元而非位元組，遇到任何高於 U+00FF 的碼點時會擲回例外。直接把 JavaScript 字串傳入 btoa() 的轉換器，可能在第一個重音字元上就發生錯誤，或更糟的是在編碼前先對字元進行百分比編碼或替換，產生解碼後為亂碼的資料 URL。安全的實作會先使用 TextEncoder 將 Unicode 字串轉為 UTF-8 位元組序列，再對這些位元組套用 Base64。在編碼端，依據 WHATWG Encoding Standard，位元組序列的定義是明確無歧義的，該標準明確規定了將 Unicode 碼點對應到位元組的一、二、三與四位元組模式。在解碼端，嚴格的 UTF-8 驗證會拒絕格式錯誤的位元組序列，而非以替換字元取代，這使得來回轉換保持確定性，避免在輸入本身已損壞時仍回傳一個看似成功的文件。
如何在瀏覽器中安全地將 SVG 轉為 Base64
以下步驟會逐步走過一個能保持文件私密並保留 Unicode 的瀏覽器本地工具所採用的完整工作流程。
- 直接在您的瀏覽器分頁中開啟 SVG 轉 Base64 轉換器。轉換過程中不會上傳任何檔案，也不會渲染預覽。
- 選擇 Encode，然後貼上完整的 SVG 文件。輸入內容必須包含一個 <svg> 根元素，並在可選的位元組順序標記與空白修剪後，有對應的結尾 </svg>。
- 執行轉換並檢視完整的文字結果。輸出是依來源 UTF-8 位元組序列所產生的 data:image/svg+xml;base64,... URL。
- 複製完整的資料 URL，並在完全可信的目的地（而非通用的預覽工具）中進行測試。目的地的內容安全政策、URL 長度上限，以及 SVG 專屬的大小預算，都是測試的一部分。
- 若要解碼，請切換到 Decode，並貼上符合格式的 data:image/svg+xml;base64，資料 URL。這個狹窄的前綴可避免意外解碼不相關的 Base64 內容。
- 對重要的文件（特別是包含 CJK 文字、表情符號或重音的內容）進行來回轉換，並在採用前比對還原後的 Unicode 文字與來源。
限制、邊緣情況，以及資料 URL 並非合適選擇的時機
即使是全本地、嚴格驗證的轉換器，仍有其限制。500,000 字元的來源上限會限制記憶體與主執行緒的工作量，但產生的資料 URL 仍可能超過瀏覽器、資料庫、HTTP 標頭、QR 碼或建置工具的限制。Base64 通常會使位元組數膨脹約三分之一，再加上資料 URL 的前綴，因此以檔案形式舒適的 SVG，可能膨脹成不便於內嵌的內容。RFC 4648 直接描述了這種膨脹：四個 Base64 字元代表三個來源位元組，因此編碼後的輸出大約比輸入大 33%。
兩個實務上的邊緣情況值得注意。首先，輸入檢查尋找的是結構上的 <svg> 邊界；它並非完整的 XML 或 SVG 驗證器。被語法接受的文件，仍可能是無效的 SVG、在不同瀏覽器中呈現不同結果，或參考了目的地無法取得的資源。請在真正的消費端驗證該文件。其次，解碼器僅接受精確的 data:image/svg+xml;base64，前綴。它不會猜測純 Base64、URL 編碼後的 SVG、替代的媒體類型參數，或經空白正規化的內容。這種狹窄的合約是一項特性而非限制：它能防止意外解碼不相關的資料，並使來回轉換行為可被檢驗。
常見線上轉換器行為的安全比較
下表整理了讀者應該對任何線上 SVG 轉 Base64 工具所抱有的安全特性，以及缺少各項特性時會出現的失敗模式。
| 特性 | 安全行為 | 缺少時的失敗模式 |
|---|---|---|
| 處理位置 | 瀏覽器分頁內，不發出網路請求 | 來源 SVG 會被上傳並存留於伺服器記錄或快取中 |
| 轉換期間的渲染 | 絕不渲染或執行 | 腳本、事件處理常式與外部參考會在預覽中執行 |
| Unicode 處理 | 透過 TextEncoder 進行 UTF-8 編碼，並採用嚴格的解碼驗證 | 重音、CJK 或表情符號文字會被悄悄損壞 |
| 輸入合約 | 編碼時為完整的 svg 根元素；解碼時為精確的資料 URL 前綴 | 不相關的 Base64 或媒體類型會被誤判為 SVG |
| 隱性淨化 | 無 —— 透過 Base64，輸出位元組等於輸入位元組 | 使用者誤以為輸出安全，而略過對目的地 CSP 的檢查 |
何時改用獨立快取的 SVG 檔案
SVG 在以獨立資源提供時，通常能透過 HTTP 內容編碼獲得良好的壓縮效果；而獨立檔案還能擁有獨立的快取、更友善的除錯體驗，以及一個能受內容安全政策約束的明確 URL。將一長串 Base64 字串內嵌於文件中，則可能放大周圍的 HTML 或 CSS、無法獨立快取，並使圖稿更難進行 diff 與檢視。正確的比較應基於最終交付結果的大小與行為，而非猜測哪種技術更快。對於體積較大、跨頁面重複使用，或經常修訂的圖稿，獨立快取的 SVG 檔案通常是更安全且更易於維護的選擇。對於可受益於內嵌的小型一次性圖示，只要來源為您擁有或信任的內容，並採用具嚴格 UTF-8 處理且經過測試的目的地，瀏覽器本地的轉換是合理的權衡。
若想更深入了解編碼工作流程本身——包括 UTF-8 步驟如何與屬性及命名空間互動——指南 將 SVG 編碼為 Base64：UTF-8 資料 URL 工作流程 以更程序性的細節涵蓋了同一轉換過程。