一個本機的 ASCII 藝術產生器可以把不超過 15 MB 的 JPG、PNG 或 WebP 檔案，在不離開瀏覽器分頁的情況下，轉換成由等寬字元組成的網格。整個轉換流程遵循一條固定的管線:來源圖片會先被解碼並縮小到每個輸出格子對應一個像素，每個取樣像素會對應到 WCAG 2.2 所定義的相對亮度值，然後該亮度會從你選定的密度字元序列中挑選一個字元。最終產物是純文字 — 沒有圖片、沒有內嵌的 base64 — 你可以把它貼到程式碼區塊、聊天回覆或長篇留言中，而不用拖著一張圖片到處跑，不過最終呈現效果仍取決於目的地的字型、行高與可用寬度。本機管線也代表如果遠端伺服器忙碌，這裡完全不用排隊。ASCII 文字能在拒絕圖片附件的地方存活，例如純文字的 README 檔、終端機截圖、原始碼註解、IRC 風格的紀錄檔，以及會剝掉二進位上傳的論壇文章。權衡之處在於 ASCII 是一種詮釋，而不是無損的影像格式 — 細微的紋理、真實的色彩以及圖片中的小型可辨識字型都無法在轉換後存活。請把輸出結果視為原圖的一張風格化、可辨識的素描，而不是一份拷貝。
這個工具實際上對你的圖片做了什麼
這個 文字轉 ASCII 藝術產生器會把圖片取樣到一個極小的網格，然後用單一字元取代每個取樣像素，藉此把圖片轉換成文字。取樣後的影像會先繪製到一個保留原始長寬比的小畫布上，因此橫向的照片會變成橫向的文字區塊，而直立的肖像會變成直立的文字區塊。由於等寬字元的高度大於寬度，工具在計算列數之前會先做高度修正;少了這個步驟，正方形圖片在轉換後會看起來被垂直拉長。每個輸出格子都精確對應到一個合成的 sRGB 像素，這就是為什麼結果形狀與原圖相同，即使它本身不含任何實際的圖片資料;瀏覽器透過標準的 canvas getImageData 介面讀取這些像素。
取樣完成後，每個像素會先從 sRGB 色版值轉換成線性值，再代入 WCAG 2.2 所記載的相對亮度公式。這個亮度 — 介於 0 和 1 之間的單一數值 — 會從你選定的密度序列中挑選一個字元。視覺上較「重」的字符(例如 @、# 與 M)代表較暗的區域，而空白與小型標點符號則代表較亮的區域。這就是為什麼肖像照會在臉部周圍形成一團可辨識的密集字符，背景區域的列則較為稀疏。整條管線都在當前分頁中執行，因此轉換一結束就能立刻看到中間預覽。
工具接受的輸入格式與把關的限制
工具只接受三種影像格式:JPEG、PNG 與 WebP。在檔案被解碼之前，瀏覽器會先擋掉其他所有格式，以免不支援的副檔名引發一場白忙的載入。第一道硬限制是檔案大小:任何超過 15 MB 的圖片會在最前端、連尺寸都還沒讀取之前就被擋下。這條規則存在，是因為在單一瀏覽器分頁中解碼非常大的檔案，可能會在記憶體受限的裝置上失敗，尤其是在背景同時開啟多個分頁的手機上。
檔案通過這道關卡後，瀏覽器會讀取解碼後的尺寸，並檢查第二道大約 40 megapixel 的上限。這道上限無法在解碼前強制執行，因為壓縮影像的檔案大小無法可靠地預測其解碼後的尺寸 — 一個檔案很小但解析度極高的 PNG，位元組數可能微不足道，像素數卻非常龐大。40 megapixel 的上限會限制後續的畫布處理。如果在選定寬度下產生的輸出會超過 800 列或 100,000 個字元，工具會拒絕繪製，並建議縮小寬度或裁切來源。這些保護措施存在，是因為超過這些門檻的結果會變得難以檢視、複製或貼到任何實際的版面配置中。
| 限制 | 數值 | 檢查時機 |
|---|---|---|
| 接受的檔案類型 | JPEG、PNG、WebP | 解碼之前 |
| 最大檔案大小 | 15 MB | 解碼之前 |
| 最大解碼像素數 | 最多約 40 megapixels | 瀏覽器讀取尺寸之後 |
| 最大輸出列數 | 800 | 取樣網格計算完成後 |
| 最大輸出字元數 | 100,000 | 取樣網格計算完成後 |
寬度、密度與反向:改變成品樣貌的三個控制項
在你按下「產生」之前，有三個控制項決定轉換的樣貌。輸出寬度就是結果中的字元欄數。較大的值能保留更多來源的細小特徵 — 臉部細節、標誌上的文字、細線 — 但同時也會產生更長的行與更大的總文字區塊。較小的值會縮短每一行，產生更精簡的素描，方便貼進窄版版面，例如側邊欄、個人簡介，或是上限 80 欄的終端機視窗。沒有單一最佳寬度;正確的數字取決於目的地，以及來源圖片實際承載了多少細節。
密度組用來控制轉換器可選擇的色階數量。Standard 是平衡的預設值，適用於大多數主題。Detailed 為每個亮度區間提供更多符號，當主題偏單調、在 Standard 下會看起來像一面相同字符的牆時特別有用。Simple 使用的符號較少，通常看起來更粗獷，能拯救在較高密度下變成視覺雜訊的繁忙高對比來源。反向切換會翻轉亮度方向，讓來源的亮部變成最「重」的字符，暗部變成空白。當目的地以深色背景呈現淺色文字(例如深色程式碼區塊、深色主題的聊天視窗，或是使用標準白底黑字的終端機)時，請啟用此選項。
| 密度組 | 行為 | 最適合 |
|---|---|---|
| Standard | 平衡的預設序列 | 一般主題、照片、混合對比 |
| Simple | 符號較少，結果更粗獷 | 需要清理的雜訊或高對比來源 |
| Detailed | 每個亮度區間有更多符號 | 需要額外明暗層次的單調主題 |
如何從本機圖片產生 ASCII 藝術
請依照以下簡短流程，從任何支援的圖片產出可貼上的 ASCII 區塊。
- 從裝置中選擇一個 JPG、PNG 或 WebP 檔案，等待轉換器顯示其像素尺寸。
- 設定以欄數表示的輸出寬度、選擇密度組，若目的地使用深色背景的淺色文字，請切換反向選項。
- 按一下「產生」並檢視等寬預覽;每個字元都應佔據一個可預期的視覺格子。
- 將文字複製到剪貼簿，或下載為以來源圖片命名的 UTF-8 純文字 TXT 檔。
第一步是選擇檔案 — 檔案選擇器只接受上述三種格式，其他格式會被拒絕。一旦載入有效的檔案，尺寸就會顯示出來，因為瀏覽器已經在本機完成解碼。第二步是選擇細節與長度之間的權衡:較寬的輸出能保留更多細小特徵，較窄的輸出則讓結果保持精簡，足以貼進窄小的程式碼區塊。第三步是實際的轉換，也是你能判斷設定是否合適的階段 — 預覽以等寬字型呈現，因此每個字元佔據的格子是可預期的。第四步是輸出:「複製」會把精確的文字放進系統剪貼簿，而「下載 TXT」會產生一份純 UTF-8 檔，可以在任何文字編輯器中開啟，或導入另一支本機腳本。
在「複製」與「下載 TXT」之間抉擇
「複製」與「下載 TXT」會產生相同的字元列，但適合不同的工作流程。「複製」會把精確的文字放進系統剪貼簿，準備貼到聊天回覆、程式碼區塊，或任何接受貼上操作的文字欄位。「下載 TXT」則會寫出一份以來源圖片命名的 UTF-8 純文字檔;檔案中只包含產生的列，不含任何標頭或中繼資料，因此可以在任何文字編輯器中開啟、與先前的版本做差異比較，或導入另一支本機腳本。如果你打算把結果貼到好幾個地方，「複製」比較快。如果你打算把結果跟原始圖片放在一起保存，或是以檔案形式分享，「下載 TXT」是更乾淨的選擇。兩條路徑都在本機執行，因此文字中途不會經過任何伺服器。
在複製或下載之前先閱讀等寬預覽
在把結果視為定稿之前，請務必先閱讀預覽。ASCII 是來源的失真詮釋，並非像素級的拷貝，因此同樣的寬度與密度，在不同圖片上可能產生截然不同的結果。一個不錯的起點是大約 80 欄，搭配 Standard 密度組。先產生一次，然後觀察兩件事:主要主體的可辨識輪廓，以及整體的色調平衡。如果重要輪廓模糊進背景，請增加寬度或切換到 Detailed。如果預覽感覺雜亂、太多小符號在爭奪空間，請切換到 Simple，或是把寬度縮減 10 到 20 欄。
在反覆調整時請保留原始圖片 — 你可能需要回去對照，以確認轉換器抹平的某個特徵。工具也會拒絕超出 800 列或 100,000 字元門檻的輸出，因此若轉換器要求你縮小寬度或裁切來源，這是正確的回應，而不是繞過限制的應急手段。一旦預覽在選定寬度下看起來正確，就複製或下載;此時輸出已經固定，除非你變更設定，否則無需重新產生。
Where ASCII text pastes cleanly — and where it breaks
Where you paste the result matters as much as the settings you used to create it. A monospace destination preserves alignment, while a proportional font will silently stretch the columns and ruin the shape. Some platforms collapse repeated spaces unless the text is wrapped in a preformatted block, so a background that looks solid in the preview can develop holes when pasted into a chat window that strips whitespace. Code blocks, Markdown fences, README files, terminal paste buffers, and any container explicitly set to a monospace font are reliable targets. Plain chat messages, rich-text editors with autoformat, and word processors with smart-quote or autocorrect features are common failure cases — paste into those only after previewing.
To check whether a destination will preserve your result, paste the same block into both a code block and a plain message in your usual chat tool; if the two look different, the destination is changing the rendering rather than the converter producing a flawed output. To learn more about the pixel-to-character mechanics behind the preview, the Image to ASCII Explained: How Pixels Become Text guide walks through the same sampling and luminance stages this tool uses.
For a deeper look, see How to Use Canva to Combine Images: A Local Shortcut.