一款將文字轉換為 ASCII 藝術的產生器，能將圖片轉成一整塊可複製的字元，每個取樣像素對應一個等寬字形，並把視覺上較密的符號分配給暗部區域，把空白或淡色標點分配給亮部區域。整個轉換程序都在當前瀏覽器分頁中本地執行：來源圖片會被解碼、繪製到一塊符合所選輸出寬度的小型取樣畫布上，然後以像素形式讀取，全程絕不會上傳到任何遠端服務。這款 文字轉 ASCII 藝術產生器 支援 JPG、PNG 與 WebP 格式的輸入檔案，單檔上限 15 MB；它內建了高度校正機制，使正方形圖片在等寬字型下不會被垂直拉長，並提供三組密度集（標準、詳細、簡單）以及一個可選的反向模式，方便在深色背景上顯示淡色字形。每個輸出格來自單一像素：透明像素會先合成在白色之上，避免深色 alpha 值透出底色；接著對 sRGB 通道進行線性化處理，並依據 WCAG 2.2 所定義的 0.2126、0.7152、0.0722 這三個係數計算相對亮度，再從所選密度序列中挑出對應的字元。這讓輸出結果可預期：100 欄的輸出每一列對應一行計算後的列，並以換行字元連接，可以直接複製到剪貼簿，或儲存為以原圖命名的 UTF-8 純文字檔。
本地版的文字轉 ASCII 藝術產生器究竟做了什麼
這套工具是「圖片轉文字」轉換器，而非字型產生器：它並不像 FIGlet 風格的產生器那樣把一串輸入文字重繪成橫幅藝術，而是把圖片視為一張亮度值網格，並為每個取樣像素挑選最能代表其明暗程度的字元。由於輸出是純文字，你可以把它貼到程式碼註解、GitHub README、終端機風格的社群貼文，或任何會以等寬字型呈現、而無法直接嵌入原始圖片的地方。
由於整個管線都透過標準瀏覽器 API（例如 CanvasRenderingContext2D.getImageData 和 createImageBitmap）在瀏覽器中執行，因此不需註冊帳號、沒有遠端排隊、也不會在伺服器端留下來源檔案的副本。這使得這款產生器在處理一般私人草稿時格外實用——你不必把 JPG、PNG 或 WebP 交給來路不明的雲端服務。支援的檔案類型為 JPEG、PNG 與 WebP，並會在解碼前強制執行 15 MB 的上限，避免瀏覽器為過大的來源檔配置記憶體。
如何逐步將圖片轉成 ASCII 藝術
- 選擇一張 JPG、PNG 或 WebP 圖片，並等待檔名旁顯示出來源尺寸。工具會在任何取樣作業開始前先讀取寬度與高度。
- 設定以字元數表示的輸出寬度。80 欄是個合理的起點，可容納多數程式碼區塊與社群個人簡介欄；想看到更多細節就調高，需要更短的行寬就調低。
- 挑選一組密度集（標準、詳細或簡單），並決定是否啟用反向的明暗對應。當輸出目的地採用深色背景、需要以淡色字形顯示時，反向模式就是正確選擇。
- 產生 ASCII 藝術後，檢視等寬字型的預覽結果。如果主體難以辨識，請嘗試不同的寬度或密度集，而不是直接接受第一次的結果。
- 將文字複製到剪貼簿，或下載為以來源圖片命名的 UTF-8 純文字 TXT 檔，方便日後以任何文字編輯器重新開啟。
如果所選寬度會讓圖片產生超過 800 列或 100,000 字元，工具會要求你縮小寬度或裁切來源，而不是實際產生一塊難以使用的文字區塊。及早攔截這種情況，正是為什麼高度校正步驟很重要：等寬字元通常比寬度來得高，若不做校正，正方形來源在像素被替換成字元後，視覺上會明顯被拉長。
挑選適合目的地的字元寬度
輸出寬度控制的是字元欄數，而非來源像素數，這是一個實用的區別。較大的寬度會以更細的網格取樣圖片，保留邊緣與小型特徵，但也會產生更長的行與更多的文字總量；較小的寬度取樣更為激進，會捨棄細微的明暗差異，輸出更精簡的結果，方便貼到較窄的版面，例如社群個人簡介欄、Discord 訊息或單行終端機橫幅。
對大多數主題來說，建議的工作流程是：先用標準密度集並將寬度設在接近 80 欄，產生一次後檢視可辨識的特徵。如果人臉、標誌或輪廓看起來過於雜亂，先調高寬度再考慮更換密度集；如果主體已可辨識，但行長超過目的地能容納的範圍，則先降低寬度，只有在結果仍然模糊不清時才更換密度集。由於轉換是「一像素對一格」，來源長寬比與最終行長之間的對應關係由所選寬度與高度校正固定，因此你可以在產生之前大致預測文字的寬度與高度。
選擇密度集與目的地設定
每組密度集都是一組不同的有序字元序列，工具會依據取樣像素的亮度逐一比對。視覺上較密的字元佔據較多墨色，用來代表較暗的區域；空白、小點與小型標點則代表較亮的區域。這三組集是為不同的取捨設計，而非針對不同主題：
| 密度集 | 明暗階數 | 最適用於 |
|---|---|---|
| 標準 | 平衡的中段序列 | 一般主題，以及任何圖片的初次嘗試 |
| 詳細 | 亮度範圍涵蓋更多字元 | 人像、漸層，以及邊緣柔和的圖片 |
| 簡單 | 符號較少、形狀更粗 | 標誌、輪廓，以及小寬度下雜訊會主導結果的情境 |
反向切換會顛倒對應方向，使暗像素變成空白、亮像素變成粗重字形。這在目的地會保留空白並採用深色背景時特別實用，例如深色主題網站上的程式碼區塊或終端機截圖。若目的地會壓縮空白，反向模式就會在錯誤的位置產生缺口，因此建議在實際背景上預覽貼上後的結果再採用。不同的目的地也會有不同的實用寬度與密度範圍：
| 目的地 | 寬度建議 | 密度建議 | 反向模式 |
|---|---|---|---|
| 程式碼註解或原始檔 | 配合周圍縮排，通常為 60 到 80 欄 | 標準或詳細 | 除非檔案使用深色背景，否則關閉 |
| GitHub README 或 wiki | 滿版區塊使用 80 到 100 欄 | 人像用詳細，標誌用簡單 | 淺色主題關閉，深色主題開啟 |
| 社群個人簡介或短訊息 | 30 到 50 欄 | 簡單，以利小尺寸下的清晰度 | 僅在平台保留空白並以深色渲染時開啟 |
| 終端機截圖或橫幅 | 配合終端機寬度 | 簡單，以呈現粗獷輪廓 | 終端機使用深色背景時開啟 |
準備來源圖片以獲得更乾淨的輸出
這款轉換器對來源的亮度範圍相當敏感。對比強烈、輪廓清晰的圖片轉換效果比平淡或低對比的圖片更乾淨，因為其亮度值會分佈到密度序列中更寬的範圍。產生之前可先做幾項準備工作：
- 裁切到主體範圍，讓取樣畫布把較少的格子花在空白的背景上。
- 當原圖看起來偏淡偏灰時，先在影像編輯軟體中提高對比，再進行轉換。
- 對於非常大的來源圖，預先縮放成可管理的解析度，讓受限裝置上的解碼作業更快完成。
- 轉換帶透明區域的 PNG 時，心中先設定一個已知的背景色，因為透明像素預設會合成在白色之上。
記憶體是另一項實際的限制。工具會在解碼前強制執行 15 MB 上限，並在畫布處理前套用另一條獨立的 4,000 萬像素限制。高度壓縮的圖片在解碼後仍可能撞到裝置本身的記憶體上限，因此在手機或舊型筆電上，可以關閉其他吃重的分頁或改用較小的來源，這是合理的權宜之計。
ASCII 轉換無法保留的部分
ASCII 轉換是一種詮釋，而非無損的影像格式。細緻的紋理、精確的顏色、可閱讀的小字、透明效果與照片級細節，都無法像原始檔案那樣完整保留下來。即便使用詳細密度集，一張人臉最終也只會變成粗略的明暗格排列，而非一張肖像。任何仰賴目的地字型的部分也都會跟著偏移：比例字型會破壞對齊，而某些平台會壓縮連續空白，除非文字放在預先格式化區塊或程式碼圍欄之中。
因此建議的工作流程是：保留原始圖片、測試幾種輸出寬度，並在實際目的地預覽貼上後的結果，再依此判斷外觀是否可採用。這款產生器提供的是快速、私密的第一版草稿；這份草稿是否讀得出主體，取決於你在寬度與密度控制項上的選擇，以及文字最終落腳的位置。
若你正在權衡各種選擇，文字轉 ASCII 藝術產生器（TAAG）：在本地轉換圖片 一文對此有更詳細的說明。
若你正在權衡各種選擇，Base64 轉圖片完整說明：從文字到實際檔案 一文對此有更詳細的說明。