在 Java 中，ASCII 值只是一個介於 0 到 127 之間的 int，將它強制轉型為 char 時，使用 (char) code 會回傳對應的 ASCII 字元——例如，(char) 65 會產生 A，(char) 97 會產生 a，而 (char) 48 會產生 0。Java 將每個字元表示為取自 Unicode 基本多語言平面的 16 位元 char，但標準的 7 位元 ASCII 在該範圍內佔用了 0 到 127 的碼點，因此從 int 強制轉型為 char 在整個 ASCII 表中都是明確定義的。當你撰寫 (char) 65 時，JVM 會根據與字元常值相同的單引號字元表讀取該整數，並產生字母 A；當你撰寫 (char) 97 時，你會得到 a；當你撰寫 (char) 32 時，你會得到一個空格。這個對應關係是固定的，並且與 IETF RFC 20 所發佈的內容完全相同，且經過 Unicode C0 控制字元與基本拉丁文對照表 的交叉驗證，這正是為什麼這個往返轉換在不同的 JVM 版本和作業系統中是可靠而非近似的原因。開發者在 Java 中進行這種轉換時，通常會遇到以下三種具體任務之一：將單一已知碼（例如 65）轉換為其對應字元、將像 {72, 101, 108, 108, 111} 這樣的碼陣列解碼為單字 Hello，或是建立一個快速測試固件，將字母表中的每個字母對應到其十進位值。
Java 將 ASCII 值儲存為介於 0 到 127 之間的整數
標準 ASCII 是一種 7 位元編碼，因此它正好定義了 128 個碼點，編號從 0 到 127。Java 的 char 型別寬度為 16 位元，因此可以直接表示每個標準 ASCII 值，但同一個 char 也可以容納 128 到 65535 的碼點，這些碼點根本沒有任何 ASCII 意義。這個區別很重要：在 Java 中將 int 強制轉型為 char 始終是合法的，但將 int 強制轉型為一個 ASCII 字元，只有當值停留在 0–127 的範圍內時才有意義。將 Java 中的 ASCII 處理視為 char 算術的一個受限子集——使用相同的強制轉型運算子，但輸入合約更為嚴格。
這 128 個 ASCII 碼點分為兩個實用的群組。0 到 31 以及 127 是控制字元，用於驅動終端機、印表機和協定，而非呈現可見的字形。32 到 126 是可列印的，涵蓋空格、標點符號、數字，以及大小寫的拉丁字母。負責解碼 ASCII 值的 Java 程式碼應該知道每個值屬於哪個群組，才能正確解讀結果，特別是因為當輸出被記錄時，Tab、換行字元和 NUL 位元組很容易被忽略。
最簡單的強制轉型：在 Java 中用一行將 int 轉為 char
從 ASCII 值到其對應字元的最短路徑是基本型別的強制轉型。Java 使用單一括號運算式來加寬和收窄數值型別，而由於 ASCII 範圍 0–127 適合放入 16 位元 char 的無符號範圍內，因此結果是明確定義的：
int code = 65; char letter = (char) code; 會產生 A。
char lower = (char) 97; 會得到 a。
char digit = (char) 48; 會得到 0。
char space = (char) 32; 會得到一個空格字元。
如果程式的其他部分期望的是 String 而非基本型別 char，標準函式庫提供了 Character.toString(int) 正好適用於這種情況。它接受一個碼點，並回傳一個單一字元的 String，這對於串接、記錄和建構訊息來說非常方便：
String letter = Character.toString(65); 會產生 "A"。
String lower = Character.toString(97); 會產生 "a"。
當值落在標準 ASCII 範圍內時，兩種形式行為完全相同，但一旦值超出 0–127，它們就會有所不同。Java 的 char 可以愉快地將 0x00E9 (é) 或 0x4E2D (中) 強制轉型為 char，因為該型別寬度為 16 位元，但這些值根本不是 ASCII 字元——它們是 Unicode 碼點。因此，假設使用「ASCII」對應關係的程式碼，必須在將強制轉型輸出視為 ASCII 位元組之前，防範 char 範圍的上半部。
從 ASCII 值陣列建構完整字串
大多數實際的 Java 任務涉及的碼不只一個。從十進位 ASCII 值清單解碼完整訊息意味著要遍歷陣列並對每個元素進行強制轉型，並將結果累積在 StringBuilder 中以提高效率。一個典型的實作從上到下讀起來像這樣：
將來源清單宣告為 int[] codes = { 72, 101, 108, 108, 111, 32, 87, 111, 114, 108, 100 };
使用迴圈建構輸出：StringBuilder sb = new StringBuilder(codes.length); for (int code : codes) { sb.append((char) code); } String message = sb.toString();
變數 message 現在保存著字串 Hello World。
有兩個值得了解的實用改進。首先，當輸入以分隔字串的形式到達時，例如 "72,101,108,108,111"，請使用 String.split("\\s*,\\s*") 將其分割，並在強制轉型之前使用 Integer.parseInt(token) 解析每個 token——這能讓強制轉型迴圈免於解析雜訊。其次，當這些值稍後必須以位元組形式傳輸時，請使用保留原始範圍的字元集對產生的 String 進行編碼，例如 message.getBytes(StandardCharsets.US_ASCII)。US_ASCII 字元集以與 ASCII Converter 相同的方式強制執行 0–127 的邊界，因此任何超出範圍的程式碼都會立即失敗，而不會默默地變成問號。
對於偏好 Java streams 的讀者來說，迴圈可以折疊成一個運算式：
String message = Arrays.stream(codes).mapToObj(c -> Character.toString((char) c)).collect(Collectors.joining());
兩種形式都會產生相同的字元；stream 版本在每個元素上稍微慢一些，但在程式碼審查中，當輸入已經是陣列時，它讀起來更為自然。
使用 ASCII Converter 驗證 Java 的 ASCII 輸出
瀏覽器端的 ASCII 工具是確認 Java 強制轉型確實產生了預期字元的最快方法，特別是當訊息包含像 Tab 或換行字元這類隱形控制碼時。請依照以下步驟透過 ASCII Converter 往返轉換一個序列：
- 使用工具頂部的模式選擇器，選擇要編碼 ASCII 文字或解碼十進位 ASCII 碼。
- 若要驗證 Java 輸出，請切換到解碼十進位 ASCII 碼，並貼上以空格、逗號或換行分隔的整數清單——例如 72 101 108 108 111。
- 選擇 Convert ASCII，並在輸出區域中檢視解碼後的字元。該工具會在目前的瀏覽器分頁中持續處理，因此不會上傳任何內容。
- 如果輸入包含控制字元，請記住十進位 9 是 Tab、10 是換行字元 (LF)、13 是歸位字元 (CR)、0 是 NUL，而 127 是 DEL——它們可能會呈現為空白字元或根本不顯示任何字形。
- 複製已驗證的文字，或複製十進位輸出並將其回傳到你的 Java 程式中，以保持數值為唯一的真實來源。
當 Java 程式需要將其數值輸出列印出來以進行偵錯時，同樣的流程也可以反向操作：在 ASCII Converter 中編碼來源字串，然後將產生的十進位碼貼到 Java 測試中作為 int[]，並使用上述強制轉型邏輯斷言往返轉換的結果。將 Java 強制轉型模式與瀏覽器工具搭配使用，可以捕捉到 print 偵錯所遺漏的隱形字元陷阱。
每個 Java 開發人員都必須遵守的 ASCII 邊界
Java 不會阻止你將 (char) 200 或 (char) -1 進行強制轉型，但這些值超出了 ASCII 合約。標準的 7 位元 ASCII 表在十進位 127 結束，其中碼 127 保留給 DEL。128 到 255 之間的碼沒有單一共用的意義——Windows-1252 和 ISO-8859-1 對同一個位元組的解釋不同——因此將它們視為「延伸 ASCII」會悄悄地損壞文字。ASCII Converter 在兩個方向上都強制執行此邊界：編碼會拒絕第一個超出 0–127 的字元並報告其位置，而解碼則會拒絕帶符號的值、小數、十六進位前綴、空 token，以及任何大於 127 的數字。
有少數邊界碼值得牢記，因為它們最常絆倒 Java 開發人員。下表列出了強制轉型程式最有可能遇到的值，以及產生每個值的 Java 運算式和對結果呈現方式的簡短說明：
| 十進位 | 字元 | Java 運算式 | 備註 |
|---|---|---|---|
| 0 | NUL | (char) 0 | 控制碼；不呈現任何內容。 |
| 9 | TAB | (char) 9 | 在大多數編輯器中插入 Tab。 |
| 10 | LF | (char) 10 | 換行字元；在 Windows 上與 13 搭配。 |
| 13 | CR | (char) 13 | 歸位字元；在 Unix 上與 10 搭配。 |
| 32 | 空格 | (char) 32 | 第一個可列印的 ASCII 碼。 |
| 48 | '0' | (char) 48 | 第一個十進位數字。 |
| 65 | 'A' | (char) 65 | 第一個大寫字母。 |
| 97 | 'a' | (char) 97 | 第一個小寫字母。 |
| 126 | '~' | (char) 126 | DEL 之前最後一個可列印的 ASCII 碼。 |
| 127 | DEL | (char) 127 | 最後一個標準 ASCII 碼；不呈現任何內容。 |
這些邊界由 IETF RFC 20 ASCII 格式文件和 Unicode C0 控制字元與基本拉丁文對照表所固定，因此在不同的 JVM 版本、作業系統或語言環境中都不會改變。
Java 在處理 ASCII 值時轉型錯誤的常見位置
在處理 ASCII 值的 Java 程式碼中，有三種錯誤反覆出現。第一種是混用帶符號與不帶符號的解讀方式。Java 的 int 是帶符號的，因此 (char) 200 儲存的是位元樣式 0x00C8，也就是 Unicode 碼點 È——而不是任何 8 位元字碼頁中的位元組 0xC8。將同一個值轉型回 int 會得到 200，看起來正確，但把產生的 String 當作 Windows-1252 的位元組解讀，會得到不同的字元。修正方式是當目標確實是 ASCII 時，把值保持在 0 到 127 之間。
第二個陷阱是把 char 當作數值型別進行算術運算。對 char 加 1 會將它提升為 int，結果是下一個碼點，而不一定保證是 ASCII 中存在的下一個字母。for (char c = 'A'; c <= 'Z'; c++) 這種寫法能運作，只是因為 'A' 到 'Z' 在 ASCII 中是連續的；同樣的技巧用在帶腔調字母或非拉丁文字上就會失敗，因為 Unicode 在各區段之間會出現空隙。當迭代範圍必須保持在 ASCII 之內時，使用明確上限為 127 的 int 迴圈，會比依賴 char 算術更安全。
第三個陷阱是隱形的控制字元。解碼包含 {9, 65, 66} 的清單會產生 TAB A B，而前端的 tab 字元在輸出記錄到主控台或貼到文字欄位時很容易被忽略。負責解碼 ASCII 值的 Java 程式碼應該明確處理十進位 0、9、10、13 與 127——可以選擇移除、跳脫，或是用分隔符把輸出包起來，避免在缺少字形的情況下看起來像是字元不見了。decimal-values walkthrough 深入說明了對應的編碼端，而 ASCII Converter 在驗證貼上的輸出時於本機套用同一條規則。當 Java 程式需要分享包含這些代碼的序列時，輸出整數清單而非渲染後的字串，可以讓每個位元組從頭到尾都保持可觀察。
如果你正在評估各種選項，Base64 Decode API 替代方案：在本機執行解碼器 對此有詳細說明。