把 SVG 程式碼轉成圖片的意思，是把 SVG 標記文字本身渲染成一張靜態 PNG —— 而不是去解析或點陣化標記所描述的圖形。輸出是一張乾淨、像螢幕擷圖般的程式碼圖片，保留換行、等寬文字，並提供淺色或深色背景。這讓它適合用於說明文件、教學文檔、設計審稿、錯誤回報，以及社群貼文，讓人一眼就能看到原始碼，卻又不會讓人想要直接複製貼上。若要在當前的分頁中本機完成，請把完整的 SVG 標記貼到 Code to Image Generator，選擇佈景主題、字型大小與留白，然後下載產生的 PNG 檔案。由於不會進行任何解析、執行、評估或上傳，標記中的角括號、看起來像指令碼的字串以及 & 符號都會保持為一般的字形。輸入內容全程都是惰性文字；PNG 內只含有渲染出來的像素。純粹在本機處理也代表之後把圖片放進 wiki、簡報或聊天視窗檢視時，不會意外觸發內嵌的事件處理器。
「SVG code to image」實際上的意思
「SVG code to image」這個說法本身有多重含義。它可以指兩件截然不同的事，搞混了就會選錯工具。
- 渲染 SVG 指的是解析標記、繪製實際的圖形（圓形、路徑、圖表），然後匯出點陣圖檔。這需要 SVG 引擎，例如瀏覽器 DOM、Inkscape，或是伺服器端的渲染器如 resvg 或 librsvg。
- 擷取 SVG 標記 則是把標記當作文字，包進一個程式碼風格的框框中，產生一張看起來像編輯器擷圖的 PNG。PNG 是程式碼的圖片，不是程式碼所繪出內容的圖片。
Code to Image Generator 做的就是第二種。它把 SVG 原始碼當成惰性文字接收，使用固定的等寬字型與單一前景色，把每一行保留的內容畫到一個離螢幕 Canvas 上，再把該 Canvas 編碼為 PNG。整個流程中沒有 SVG 解析器、沒有路徑細分、也沒有語法高亮器，所以結果刻意保持與語言無關：每一個字元 —— 起始標籤、屬性、命名空間宣告、實體 —— 都會以相同顏色的字形呈現。
為什麼要把 SVG 標記擷取成 PNG
擷取原始碼而非渲染圖形，在幾個常見情境下才是正確的選擇：
- 教學與授課。 讀者可以清楚看到精確的屬性名稱、命名空間前綴以及空白字元，而渲染出來的縮圖會把這些細節藏起來。
- 程式碼審查與錯誤回報。 縮排的形狀、換行以及多餘字元往往就是 bug 所在；一張漂亮的圖示反而會把證據抹掉。
- 不該被執行的說明文件。 在 wiki、PDF、簡報中嵌入靜態圖片是安全的，因為這些場景可能會封鎖、加以沙盒化或直接剝除活生生的 SVG。
- 在意標記內容的社群貼文。 在會自動移除或清理 <svg> 標籤的平台上貼原始標記時，把它變成可讀的圖片就能保留內容。
上述這些使用情境都不會因為真正的點陣化器而受惠，其中幾個甚至會被它嚴重損害 —— 一個漂亮的渲染圖示會把你原本想展示的 bug 藏起來。
事前準備：挑選符合限制的程式碼片段
在打開工具之前，先掃一下 SVG 的大小。工具會強制套用硬性上限，若超過上限會直接拒絕，而不是默默截斷：
| 限制 | 上限 |
|---|---|
| 輸入總大小 | 50,000 UTF-16 字碼單位 |
| 邏輯行數總計 | 200 |
| 單一最長行 | 2,000 字碼單位 |
| Canvas 邊長 | 每邊 8,192 像素 |
| Canvas 面積 | 32,000,000 像素 |
| 最終 PNG 大小 | 20 MiB |
如果 SVG 太大，請先切成多段、移除註解，或在貼上之前先把重複的屬性群組摺疊起來。禁止的控制字元與未配對的 Unicode 代理項會直接以明確的錯誤訊息拒絕，而不是被替換或丟棄。LF、CRLF 與 CR 都會被識別為換行符，因此從 Windows、macOS 或 Linux 編輯器複製貼上都能保持原樣。
在你的瀏覽器中把 SVG 程式碼做成圖片
- 在瀏覽器中打開 Code to Image Generator。不會有任何資料離開這個分頁。
- 貼上完整的 SVG 標記 —— 包括開頭的 <svg>、所有子元素、結尾標籤，以及任何置於前端的 XML 開頭宣告。空行與結尾的換行都會保留為圖片中的列。
- 選擇淺色或深色佈景主題，選擇 12 到 32 像素之間的字型大小，以及 16 到 96 像素之間的留白。
- 點擊 generate（產生）。瀏覽器會以本機等寬字型堆疊量測每一行保留的內容，建立一個自然輸出尺寸的 Canvas，塗上不透明的背景，以頂端基線將每一行靠左對齊繪製，最後把點陣圖編碼為 PNG。
- 閱讀結果摘要：實際的寬度與高度（像素）、保留的行數，以及最終 PNG 大小（位元組）。
- 點擊 download 來儲存 code-image.png。下載下來的是自然尺寸的離螢幕 Canvas，而不是螢幕上的預覽，所以檔案絕對不會為了配合頁面而被默默縮小。
如果來源、佈景主題、字型大小或留白有變動，先前的結果與其本機 ObjectURL 會自動撤銷，並進入新的忙碌狀態。這樣反覆調整時不會在不同編輯之間遺留記憶體。
Canvas 尺寸、字型與留白的計算方式
了解尺寸怎麼算出來，有助於挑選同時符合程式碼片段與目標圖片的設定。瀏覽器首先以選定的等寬字型與字型大小量測每一行保留的內容。最大且有限的量測寬度就是內容寬度；該值會向上取整，並在左右兩側加上選定的像素留白。高度則採用等於字型大小 1.5 倍上限的行高，乘以保留的行數，再加上上下兩側的留白。Canvas 調整大小後，會重新取得繪圖環境，並在繪製任何文字之前明確重新套用字型、基線、對齊、前景色與背景。
以字型大小 16、留白 32、SVG 共 8 行保留內容、最長一行量測為 290 像素寬的範例：
- 行高：ceil(16 × 1.5) = 24 px
- 寬度：290 + 32 + 32 = 354 px
- 高度：24 × 8 + 32 + 32 = 256 px
- Canvas 面積：354 × 256 = 90,624 px（遠低於 32,000,000）
兩邊都遠低於 8,192 像素的上限，所以這個輸入可以順利產生。若把字型大小加倍為 32 而文字不變，寬度與高度大約都會加倍，因為字型寬度變成兩倍、行高也變成兩倍 —— 這是在為 retina 螢幕或長片段縮圖挑尺寸時相當實用的經驗法則。
PNG 內含什麼 —— 以及不含什麼
匯出的 PNG 只儲存渲染後的像素。原始來源文字並未嵌入、選用的字型也沒有一起打包，語法標記也未特別標示。這個區別有以下實際影響：
| 儲存在 PNG 中 | 未儲存在 PNG 中 |
|---|---|
| 背景顏色像素 | 可編輯的來源文字 |
| 前景字形點陣化結果 | 依語言區分的 token 上色 |
| 留白與行列配置 | 字型檔案或字型中繼資料 |
| 空白行的列距 | 執行結果或執行階段輸出 |
由於工具只使用一種前景色與單一字型堆疊，只要牽涉到可編輯性、精確字元還原、螢幕閱讀器的無障礙需求，或是典藏等級的還原度，就請另外保留原始 SVG 來源。PNG 是用來精簡地視覺分享，不是用來取代來源檔案。
把標記轉成擷取圖時的常見陷阱
第一次嘗試這個工作流程時，常會出現幾個反覆犯的錯誤：
- 期待語法高亮。 不會有高亮 —— 每個字形都共用同一個前景色。若有顏色標記的需求，請先在真正的編輯器中渲染 SVG。
- 貼上時夾帶智慧引號。 如果編輯器把直引號換成了彎引號，Canvas 也會照樣畫出來。圖片看起來沒問題，但來源已經不再是檔案的 1:1 複本。
- 以為不同機器會產生像素級一致的輸出。 字型回退、字型提示與反鋸齒效果會因為作業系統而不同。不同平台的兩個開發者，在相同字型大小下會看到略有差異的字形邊緣。
- 把秘密資訊嵌進去。 標記中的 API 金鑰、內部網址與個人資料會變成像素。在把 PNG 分享到公開管道前，請先清掉這些內容。
若需要針對 SVG 本身做格式特定的檢查、命名空間清理或最小化，還是由專門的格式化工具來做會比截圖更合適。
也能用同樣方式擷取的其他程式碼
只要是想以靜態圖片分享的任何程式碼文字，都適用同一套工作流程。JSON 片段可以清楚顯示引號、括號與逗號；CSS 規則集會保留縮排；Markdown 原始碼以純等寬文字保持可讀。只要輸入低於上限且不含禁止的控制字元，結果都一樣：一張有界、本機繪製、依你選擇的佈景主題與留白產生的 PNG。如果想針對結構化文字做機器可讀的格式化，JSON Formatter 與 XML Formatter 會保留結構，而不是把結構凍結成像素。
關於用來排版每一行的底層繪圖基本操作，WHATWG canvas 規範定義了 fillText 如何繪製字形，以及 measureText 如何回報用來決定 Canvas 尺寸的寬度。兩者都在當前分頁內執行，所以最後下載的 PNG 是用本機腳本同樣可以呼叫的那些方法所組成。
延伸閱讀：HTTP Status Codes Bulk Lookup: Filter the Full Registry。