把圖片轉成 ASCII 藝術文字的運作原理
把圖片轉成 ASCII 藝術文字，意思是把圖片裡每一個取樣的像素，用一個視覺重量接近該像素亮度的可列印字元來取代，因此 50% 灰階的方塊會變成一個重量中等的字元，而黑色方塊則會變成一個 @。圖片中的暗部會轉成視覺上較重的符號，例如 @、# 或 8;中間調會變成較細的記號，例如 +、= 或 -;而亮部則會塌縮成空格、句點或冒號。因為每個字元在等寬字型格線中佔據一個固定格子，組合出來的文字會保留原始圖片的輪廓與明暗，卻不需要嵌入任何實際的圖片資料。結果就是一塊純文字區塊，可以放進程式碼註解、聊天視窗、README 檔案，或終端機風格的設計中。轉換是一種詮釋，而非無失真複製，所以原始影像中的細緻照片細節、精確色彩，以及小到可閱讀的文字都不會保留下來。能保留下來的，是一個由標準 Unicode 字元構成、可辨識的視覺輪廓，這也正是這種格式在完全無法顯示圖片的地方依然可以運作的原因。
整個流程固定且簡單，可以在紙上跟著走。一旦選定了 JPG、PNG 或 WebP 檔案，瀏覽器會讀取它的尺寸，並在取樣畫布上繪製一個縮小版本，然後為輸出中每一個字元格抽出一個像素。讀取像素與解碼影像的步驟，使用的是標準瀏覽器 API，在以下 MDN 參考文件中都有說明:CanvasRenderingContext2D.getImageData 以及 createImageBitmap。每個像素都會先在白色背景上進行合成，避免透明區域產生誤導性的黑色格子;接著在測量亮度之前，先把 sRGB 通道轉換成線性光強度。相對亮度會依據 WCAG 2.2 的係數，從線性化後的通道計算出來:紅色 0.2126、綠色 0.7152、藍色 0.0722。這個落在 0 到 1 之間的單一亮度值，會在所選字元序列中挑出一個位置:低亮度對應視覺重量最重的字形，高亮度則對應最輕的字形。反向模式只是把這個順序顛倒過來，讓輸出在深色背景上呈現為淺色文字。
如果想看單一像素的計算過程，可以拿一個 sRGB 三元組為 (128, 128, 128) 的中灰色像素來示範。8 位元值會先變成 128 ÷ 255 ≈ 0.5020 的標準化 sRGB。因為 0.5020 高於 WCAG 的閾值 0.03928，線性化時會使用 ((0.5020 + 0.055) ÷ 1.055) 的 2.4 次方，計算結果約為 0.2163。套用三個係數後可得 0.2126 × 0.2163 + 0.7152 × 0.2163 + 0.0722 × 0.2163 = 0.2163，因為三個係數加起來等於 1，所以中性灰會映射到它自己的線性化值。對照所選的字元序列，這個亮度大約落在最重端的四分之一處，這代表 50% 灰階的方塊會變成一個重量中等的字元，而不是最密實的 @;更深的方塊會往更重的字形靠近，而更亮的方塊則會塌縮為空格。
有兩項硬性上限決定了這個工具能產生與不能產生的結果。檔案類型檢查只接受 JPEG、PNG 與 WebP，且 15 MB 的上限會在影像解碼之前強制檢查。另一個 40 百萬像素的上限會在瀏覽器讀取完尺寸後檢查，用來限制後續的畫布處理步驟。如果要求的寬度會產生超過 800 列，或總字元數超過 100,000 個，工具會要求縮小寬度或裁切來源影像，而不是嘗試產生一個不切實際的文字區塊。這些規則加在一起，能讓輸出在真實的目標環境中保持可貼上、可捲動、可閱讀。
在瀏覽器中把圖片轉成 ASCII 藝術文字
以下工作流程會使用 Text to ASCII Art Generator 產生一塊可直接貼上的 ASCII 藝術文字，整個轉換過程都在當前分頁中執行，因此原始圖片不會離開本機裝置。
- 開啟工具並選擇來源檔案。點擊檔案選擇器，選取一個 15 MB 以下的 JPG、PNG 或 WebP 檔案，並等待影像的原始尺寸顯示出來，再調整其他任何設定。
- 以字元欄數設定輸出寬度。寬度控制項設定的是完成文字的字元寬度，而不是來源影像的像素寬度。數字越大，保留的細節越多，產生的行也越長;數字越小，則會產生更緊密的區塊。
- 選擇密度組合。Standard 提供平衡的色調範圍;Detailed 提供更細的明暗階梯;Simple 則會用較少的符號產生更粗獷的結果。該選哪一個，取決於目的地能呈現多少對比。
- 決定是否反轉明暗方向。在淺色頁面上要顯示深色文字時，請關閉 Reverse;當 ASCII 文字會放在深色背景上，希望淺色字元代表亮部時，則請開啟 Reverse。
- 產生 ASCII 藝術並檢查預覽。結果會以等寬字型預覽呈現，讓每個字元都佔據一個可預期的格子。請檢查是否具備可辨識的特徵、乾淨的邊緣，以及沒有被拉伸。
- 複製或下載文字。使用 Copy 把完整的區塊放進剪貼簿，或使用 Download TXT 儲存一個以來源影像命名的 UTF-8 純文字檔。
選擇寬度、密度組合與明暗方向
這三個控制項負責了轉換中所有可見的工作，因此值得謹慎選擇，而不是只採用預設值。寬度是完成文字的欄數，是影響可讀性最大的單一槓桿。作為起點，接近 80 字元的輸出寬度符合一般終端機的行寬，通常能在細節與可貼上性之間取得平衡。提高寬度可以捕捉到更多來源的細部特徵，但也會讓行變長;降低寬度則會以細節換取更緊湊的區塊，適合塞進狹窄的程式碼視窗、側邊欄與聊天視窗中。
密度組合會改變轉換器可以選用的符號數量。Standard 是為一般日常影像設計的平衡序列;Detailed 把工作分散到更多符號上，讓細微的漸層更平順;Simple 則把清單縮減成少數幾個重量感重的字形，讓結果讀起來更像粗獷、更具圖像感的區塊。
| 密度組合 | 符號數量 | 最適合用途 |
|---|---|---|
| Standard | 平衡的中等數量 | 一般用途的肖像、標誌、剪影，以及大部分自然照片 |
| Detailed | 許多階梯 | 具有柔和漸層、煙霧、雲朵或細膩明暗的影像 |
| Simple | 少數符號 | 高對比的形狀、大型標誌，以及圖像式排版 |
Reverse 切換鈕會交換所選序列中哪一端代表亮像素。關閉 Reverse 時，深色來源像素會變成視覺重量重的字元，亮像素則塌縮為空格。開啟 Reverse 時，亮色來源像素會變成重量重的字元，深色像素則變成空格，這正是當目的地背景是深色、且平台會在等寬區塊中保留開頭與結尾空格時，你想要的結果。
貼上 ASCII 文字時可預期的狀況
ASCII 藝術文字只有在三個目的地特性齊備時才能維持形狀:等寬字型、預先格式化或程式碼區塊容器，以及不會塌縮的行高。比例字型會把字元橫向擠壓，破壞視覺輪廓，所以應永遠明確指定 Courier、Consolas、Menlo 或其他等寬字型。許多聊天客戶端會折疊重複的空格，除非內容被包在程式碼區塊中;把剪貼簿中的純文字貼進一般段落，通常會變成單一被折疊的行，讓影像消失。程式碼區塊、三個反引號，以及 HTML 的 <pre> 標籤都能保留縮排與開頭空格，這也是為什麼在依賴最終外觀之前，應該永遠先把貼上的版本在實際的目標容器中預覽一次。
即使字型與容器都正確，高度修正也只能做到這種程度。等寬字元的高度通常約為寬度的兩倍，而產生器會補償這種不對稱，讓正方形來源在文字格線中不會被拉伸。如果目的地套用了額外寬的行高，或非標準的長寬比，結果仍然可能看起來比預期還高，唯一的解決方式就是降低輸出寬度，或換用不同的目的地字型。重新編碼、抗鋸齒與色彩捨入根本不在這條流程之中，所以使用者手上唯一可調整的畫質旋鈕，就是輸出寬度、密度組合與 Reverse 切換鈕。
常見的用途與創意應用
ASCII 藝術文字會出現在那些會剝除圖片、拒絕二進位上傳，或偏好復古風格的地方。源碼註解通常會接受等寬藝術區塊，用於橫幅、專案吉祥物或可閱讀的檔案標頭，許多開源專案的 README 也都因為這個原因而充滿 ASCII 標誌。不會渲染內嵌圖片的聊天平台、Issue 追蹤系統與論壇文章，只要平台保留程式碼區塊選項，就能忠實顯示 ASCII 藝術。以文字為主的服務中的個人檔案欄位、狀態列與簽名檔，也是放置短小、可辨識 ASCII 肖像的另一個自然舞台。
| 目的地 | 為何適合 ASCII 文字 | 注意事項 |
|---|---|---|
| 源碼註解與 README 檔案 | 永遠以等寬字型呈現，且永遠不會被剝除 | 過長的區塊會把實際內容推到檔案很下面 |
| 聊天或論壇的程式碼區塊 | 保留空格與精確的換行 | 部分客戶端會限制每則訊息的最大列數或字元數 |
| Issue 追蹤票與變更紀錄 | 在不附加圖片的情況下加入視覺標記 | Markdown 渲染器可能會折疊空白的結尾列 |
| 終端機風格設計與獨立刊物 | 在 ASCII 美學中看起來理所當然 | 請謹慎挑選密度組合，讓主題在目標尺寸下仍能辨識 |
如果需要支援更多檔案類型的相關工作流程，請參閱關於在本機把 PNG、JPEG、GIF 與 WebP 圖片轉成 ASCII的指南。
延伸閱讀:不需上傳，直接把圖片轉成文字 ASCII 藝術。