標準的 7 位元 ASCII 正好定義 128 個字元值，從十進位 0 到 127，因此用於大量文字的真正 ASCII 碼轉換器，必須在輸入的每個字元或符記上強制執行這個嚴格的上限。ASCII 轉換器是一個在本機瀏覽器中執行的工具，可將最多 100,000 個 UTF-16 程式碼單元的純文字編碼為以空格分隔的十進位整數，或將最多 50,000 個十進位符記解碼回 ASCII 字元，同時拒絕任何超出 7 位元範圍的內容。由於整個處理過程都在你目前的分頁中執行，較長的貼上內容不會因為伺服器上傳限制、中介字元替換或隱藏的字元編碼轉換而被截斷。每個程式碼指派都遵循 IETF RFC 20，並與 Unicode C0 Controls and Basic Latin 字表交叉比對，絕不退回使用像 Windows-1252 或 ISO-8859-1 這類延伸碼頁。嚴格的 0 到 127 契約代表每個字元剛好對應一個整數，沒有 UTF-8 序列中該取哪個位元組的問題，也沒有該如何表示非 ASCII 字形的歧義。
「大量文字」這個詞在這裡很重要，因為大多數線上轉換器會把輸入上限設在幾千個字元，然後默默丟棄剩下的部分，或者假設使用 UTF-8，把 ASCII 視為特例，並把 128 到 255 的位元組直接改寫成多位元組序列。使用嚴格的 7 位元工具時，上限是真實且可預測的，只要是 127 之後的字元，就會在該確切位置產生明確的錯誤，而不是產出損壞的結果。這種「第一個超出範圍就立即報錯」的行為，正是讓大量轉換在文件紀錄、記錄檔與必須精確往返的原始碼傾印中值得信賴的原因，也是文章如何將 ASCII 轉換為整數:精確的十進位值背後的設計理念。
你實際會遇到的容量界線
這個轉換器公開兩個不同的上限，各自有不同的理由。在編碼端，輸入是以 UTF-16 程式碼單元計算，也就是說你輸入或貼上的每個字元——無論是普通字母、數字、標點、定位字元還是換行——都算一個單元。上限是 100,000 個程式碼單元，因此大約 100,000 個可見字元的文件正好落在界線上，而 100,001 個字元的文件則會產生清楚的拒絕訊息，而不是截斷後的輸出。在解碼端，輸入是以十進位符記計算，以空格、逗號或換行分隔，上限是 50,000 個符記，因為每個符記最多三個字元再加上分隔字元，所以解析器會為較長的輸入形式預留等比例的緩衝空間。
這些上限的設定，是讓一份典型的 100,000 字元 ASCII 文件——大約短篇小說一章的長度——在現代瀏覽器上於一秒內完成轉換，而且產生的十進位資料流在一般文字區域中仍保持可讀。如果你的文件更長，正確的做法是把它切成符合上限的區塊，而不是去尋找會默默接受所有內容的工具;這個嚴格上限正是保護你不發生靜默資料遺失的特點。對於 127 以上的 Unicode 碼位、多位元組 UTF-8 序列，或完整的碼頁檔案，請使用會明確標示目標編碼的工具，例如用於位元組串流的 UTF-8 編碼器 / 解碼器，或用於明確碼位的 Unicode 編碼器 / 解碼器。
將大量文字區塊編碼為十進位碼
- 開啟 ASCII 轉換器，選擇把文字轉成數字的方向(文字轉碼)。
- 把你的長篇文件貼到輸入區域。文字區域最多接受 100,000 個 UTF-16 程式碼單元，只要在上限以內，一般段落文字、記錄傾印和原始碼檔案都能容納。
- 點選 Convert ASCII。工具會由左至右掃描輸入，一旦遇到值超過 127 的程式碼單元，就會立即停止，並回報第一個違規字元的精確位置。
- 檢視輸出，輸出是一行以空格分隔的十進位整數，每個整數是輸入中依序出現之字元的 RFC 20 值。
- 如果含有任何隱藏的控制碼(十進位 0、9、10、13、27 或 127)，它們仍會以十進位數字輸出，但在輸出區域中不會顯示為可見字元。在需要驗證實際編碼內容時，請直接以十進位輸出本身作為便於稽核的產出物。
- 使用複製控制項複製結果，貼到試算表、記錄檔或可感知位元組的編輯器中，並把原始文字另外保存，以便日後重新編碼並與保存的十進位資料流進行差異比對。
將冗長的十進位序列解碼回文字
- 將轉換器切換到「碼轉文字」模式。
- 貼上範圍在 0 到 127 的十進位整數序列。解析器接受空格、逗號、定位字元和換行作為分隔符號，從試算表匯出的一整欄數字，和一行以空格分隔的數字會以相同方式解碼。
- 點選 Convert ASCII。解析器會對輸入進行符記化，要求每個符記都是不含正負號的一到三位數十進位整數，並拒絕正負號、分數、像 0x41 這類十六進位前綴、分隔符號之間的空符記，以及任何超過 127 的值。
- 在輸出區域讀取重建後的文字。由於轉換器會精確保留每個程式碼單元，包含控制碼在內，輸出內容按位元組計算的長度會等於你所提供的符記數量。
- 如果輸出看起來有部分缺失，請回頭捲動檢視輸入清單——0 到 31 以及 127 都屬於控制碼，不會產生可見字形，這是正確的行為，並非錯誤。
- 當你需要對一份長文件進行往返處理時，請將先前保存的十進位資料流解碼，並把新輸出與原始文字進行比對;若有任何字元不同，差異會以具體的程式碼單元不一致形式顯現出來，方便你進一步追查。
保護大量貼上的驗證規則
嚴格的雙向轉換，正是真正的 ASCII 工具與一般字元碼查詢的差別所在。編碼時會掃描輸入，並拒絕第一個值落在 0 到 127 之外的 UTF-16 程式碼單元，接著回報其 1 起始位置，讓你能在文字編輯器中跳到該處。解碼時則逐符記掃描輸入，並拒絕五種特定形式:帶正負號的整數(因為 7 位元 ASCII 中不會出現負值或明確帶正號的符記)、分數、十六進位前綴、分隔符號之間的空符記，以及任何超過 127 的值。這個工具不會默默重新詮釋 128 到 255 的值，因為「延伸 ASCII」這個詞實際上指的是一族彼此互不相容的碼頁(例如 Windows-1252 與 ISO-8859-1)，猜錯任何一個都會讓輸出損壞。
| 輸入形式 | 解碼器是否接受 | 原因 |
|---|---|---|
| 72 101 108 108 111 | 是 | 五個不帶正負號的一到三位數符記，皆在 0–127 範圍內 |
| 72,101,108,108,111 | 是 | 逗號是符記之間合法的分隔符號 |
| 72 101 108 108 111 111 108 101 72 | 是 | 換行是符記之間合法的分隔符號 |
| +72 101 | 否 | 帶正負號的整數不是合法的 ASCII 符記 |
| 72 101 200 | 否 | 值 200 超出 7 位元範圍 |
| 72 0x41 108 | 否 | 十六進位前綴不是合法的 ASCII 符記 |
| 72 101 (雙空格) | 否 | 分隔符號之間的空符記會被拒絕 |
| 72.5 101 | 否 | 分數不是合法的 ASCII 符記 |
大量輸出中的控制字元
十進位範圍 0 到 127 分成兩個呈現行為截然不同的區段。32 到 126 是可列印字元，必定會顯示字形;而 0 到 31 以及 127 則是 C0 控制碼與 DEL。轉換器會忠實輸出這些值，但大多數字型沒有對應字形，因此它們在輸出文字區域中看似隱形，即使底層字串中實際存在位元組。一旦你把輸出複製到終端機、試算表或聊天程式時，這點就變得重要，因為一個跑出來的歸位或換行符可能會以從十進位輸入中難以察覺的方式重新排版文字。
| 十進位 | 字元 | 名稱 | 輸出中是否可見 |
|---|---|---|---|
| 0 | NUL | 空字元 | 否 |
| 9 | TAB | 水平定位 | 呈現為空白 |
| 10 | LF | 換行 | 建立新的一行 |
| 13 | CR | 歸位 | 通常不可見 |
| 32 | (空格) | 空格 | 是 |
| 48 | 0 | 數字零 | 是 |
| 65 | A | 大寫 A | 是 |
| 97 | a | 小寫 a | 是 |
| 127 | DEL | 刪除 | 否 |
八個固定的參考點將轉換器的對照表錨定在 ASCII 字表的下界 (NUL)、TAB、LF、Space、數字零、大寫 A、小寫 a，以及上界 (DEL)，這保證了 ASCII 字表中每個區段都有一個代表字元，在工具每次執行時都會被獨立驗證。權威的指派記錄於 IETF RFC 20。
When you need a different encoder instead
Strict 7-bit ASCII is the right scope when you are working with legacy log files, ANSI C source code, dump utilities, and protocol payloads that genuinely were authored as ASCII. It is the wrong scope when your input contains accented letters, emoji, CJK characters, curly quotes, or any byte whose numeric value is 128 or higher, because those values simply do not exist in the 7-bit standard and the converter will report a rejection rather than guess.
For different scopes, reach for the tool that names its target encoding: Text to HEX for UTF-8 hex bytes, Binary To Text for visible 8-bit binary, Hex to Text Converter to decode UTF-8 hex bytes back to Unicode text, the Unicode Encoder / Decoder for explicit U+ code points, and the UTF-8 Converter with the source encoding named for files that originated as Windows-1252 or ISO-8859-1. Each of those tools calls out its scope in its name, which is the simplest way to avoid the silent-replacement trap that a generic "ASCII" tool can fall into.
For very long documents that exceed the 100,000-code-unit ceiling, the practical workflow is to split the source on a hard boundary — chapter, function, log block — encode each chunk, save the resulting decimal streams in version control, and reassemble by decoding each stream in order. Because the converter rejects anything outside 0 through 127, the chance of an undetected corruption across a chunk boundary is exactly zero, which is what makes large-text ASCII conversion a reliable primitive for documentation and testing pipelines.
If you're weighing options, Base58 Decode Large Text: Browser Limits and Hex Output covers this in detail.