標準的 7 位元 ASCII 為 128 個字元和控制代碼各指派一個從 0 到 127 的唯一整數，而 Java 透過其無符號 16 位元 char 型別以及經由轉型所產生的 int 值來表示這些相同的整數。若要在 Java 中使用 ASCII 碼，你需要具備三項要素：字元或控制代碼的精確數值、一種能在十進位、十六進位、八進位與二進位之間可靠查詢的方式，以及對 Java 基本型別如何呈現這些數字的了解。十進位對字符的映射是由 RFC 20 與 Unicode 基本拉丁文表格所固定，因此大寫 A 永遠是 65 (0x41)、小寫 a 永遠是 97 (0x61)、數字 0 永遠是 48 (0x30)。諸如 NUL、HT、LF 和 CR 等控制代碼使用 RFC 20 所定義的縮寫，因為它們並無可列印的字符。Java 程式碼很少直接硬編這些數值，但當需要進行通訊協定解析、檔案格式檢查、字元類別測試或記錄清理時，正確性至關重要，因為錯誤的位元組會在無聲無息中損毀資料。ASCII 表格為 Java 開發人員提供了一個快速且精確的查詢工具，涵蓋從 0 到 127 的每個數值，並以 Java 原始碼實際使用的四種表示法呈現。
每位 Java 開發人員都必須知道的 ASCII 碼基礎
美國資訊交換標準代碼（定義於 RFC 20 與 ISO/IEC 646）是一個 7 位元的代碼集，剛好包含 128 個位置，以十進位 0 到 127 編號。代碼表劃分為四個實際區域，在撰寫 Java 程式碼時十分重要：0 到 31 的控制代碼、32 的空白字元、33 到 126 的圖形字元，以及 127 的刪除字元。RFC 20 提供了控制區的縮寫和完整名稱，而 Unicode 基本拉丁文表格則提供了可列印的標點符號、數字和字母的名稱。ECMA-6 確認了 7 位元、128 個字元的範圍，這也是為何 127 的界線是刻意設計而非偶然產生的原因。
超過 127 的數值不屬於標準 ASCII。位元組值 128 到 255 所代表的字元，取決於檔案或通訊協定使用的是 ISO-8859-1、Windows 字碼頁，還是諸如 CP437 之類的 IBM PC 字碼頁。將它們視為「延伸 ASCII」會掩蓋這種模糊性。Java 的 char 型別可以容納這些較高的數值，因為它是一個由 UTF-16 支援的 16 位元無符號型別，但這些代碼本身已超出 ASCII 標準，須仰賴另一個獨立的編碼決策。對於涉及拉丁字母、標點符號和數字檢查的大多數 Java 工作而言，實際需要驗證的範圍就是 0 到 127。
Java 如何儲存 ASCII 數值：char、int 與轉型
Java 的 char 是一個無符號的 16 位元整數，用於儲存一個 UTF-16 碼元。當該碼元對應到一個 ASCII 字元時，其數值會與 ASCII 完全一致，因為 Unicode 為 ASCII 字元指派的碼位與其標準十進位數值相同。將 char 轉型為 int 不會進行正負號擴展，因此結果永遠是 0 到 65535 範圍內的一個非負整數。在 Java 中沒有負數的 ASCII 代碼，即便其他語言會將同一個位元組顯示為有符號值也是如此。
在 Java 中使用 ASCII 碼時，最常見的模式是轉型、比較和解析。轉型 (int) 'A' 會得到 65。比較 c >= '0' && c <= '9' 可在不配置字串的情況下檢查某個字元是否為 ASCII 數字。使用 Integer.parseInt(hex, 16) 或 Integer.parseInt(octal, 8) 進行解析，可將文字表示轉換為你在 ASCII 表格中所看到的同一個整數。這些模式取決於手邊是否備有正確的參考數值，而這正是結構化查詢勝過記憶或猜測之處。
Java 開發人員最常查閱的 ASCII 數值
下表列出 Java 程式碼最常觸及的 ASCII 位置。每個數值皆來自 RFC 20 或 Unicode 基本拉丁文表格——也就是建構 ASCII 表格時所使用的同一份資料來源。請記住規律而非每個單一數字：數字佔 48 到 57、大寫字母佔 65 到 90、小寫字母佔 97 到 122。
| Character | Decimal | Hex | Octal | Binary | Common Java use |
|---|---|---|---|---|---|
| NUL | 0 | 0x00 | 0o000 | 0b0000000 | C-string terminator, empty byte marker |
| HT (Tab) | 9 | 0x09 | 0o011 | 0b0001001 | Column-aligned log fields, CSV scrubbing |
| LF | 10 | 0x0A | 0o012 | 0b0001010 | Unix line terminator in BufferedReader |
| CR | 13 | 0x0D | 0o015 | 0b0001101 | Carriage return, part of CRLF on Windows |
| SP (Space) | 32 | 0x20 | 0o040 | 0b0100000 | Whitespace token boundary, String.trim() |
| '0' to '9' | 48 to 57 | 0x30 to 0x39 | 0o060 to 0o071 | 0b0110000 to 0b0111001 | ASCII digit parsing, base-10 validation |
| 'A' to 'Z' | 65 to 90 | 0x41 to 0x5A | 0o101 to 0o132 | 0b1000001 to 0b1011010 | Identifier start checks, case folding |
| 'a' to 'z' | 97 to 122 | 0x61 to 0x7A | 0o141 to 0o172 | 0b1100001 to 0b1111010 | Lowercase parsing, locale-independent comparisons |
| DEL | 127 | 0x7F | 0o177 | 0b1111111 | Backspace sentinel, terminal control sequences |
掌握這些範圍後，你就能撰寫比正規表示式更快、且比 Character.isLetter 呼叫更易於讀取的範圍檢查——特別是在你需要純粹的 ASCII 行為時。對於超越 ASCII、更廣泛的字元類別工作，以程式設計為導向的 ASCII 指南將帶你跨越多種語言探討相同的概念。
如何查詢 Java 用的 ASCII 碼
ASCII 表格是一個以瀏覽器為基礎的參考工具，內含全部 128 個標準代碼位置，每個位置皆以 Java 原始碼所使用的相同四種數值表示法顯示。當你需要一個經過驗證的數值以放入程式碼時，請依照下列步驟進行。
- 在瀏覽器中開啟 ASCII 表格。你將會看到完整的 128 列清單，每一列顯示一個字元或控制縮寫、描述性名稱、十進位、兩位數十六進位、三位數八進位、七位元二進位，以及一個類別。
- 決定你要查詢某個特定字元的數值，或是要掃描某個類別。若要尋找單一代碼，請使用搜尋框。若要掃描某一群組（例如所有數字或所有大寫字母），請將搜尋框留白，並從篩選器中挑選一個類別。
- 使用你已具備的形式在搜尋框中輸入。像是 65 的純數字會被視為精確的十進位數。十六進位需要 0x 前綴、八進位需要 0o、二進位需要 0b，因此 0x41、0o101 和 0b1000001 都會回傳大寫 A。你也可以輸入諸如 line feed 之類的名稱、像是 LF 的縮寫，或使用 char:value 語法輸入字面字元，例如 char:A 或 char:space。
- 並排閱讀字元欄與四個數值欄，以確認相符的列。十進位數值是來源整數；十六進位填補至兩位數，八進位填補至三位數，二進位填補至七位數，這與 Java 使用 Integer.toHexString、Integer.toOctalString 和 Integer.toBinaryString 所列印的固定寬度前綴相符。
- 在你需要的那一列上選擇複製。複製按鈕會以易於讀取的文字格式寫入一整列，內容包含顯示值、名稱、十進位、十六進位、八進位和二進位。將該行直接貼到程式碼註解、錯誤報告、通訊協定註記或教學簡報中。
搜尋詞彙與複製的列皆在瀏覽器內部處理，因此不會將任何碼點查詢傳送至遠端服務。如果剪貼簿權限遭到拒絕，頁面會回報該失敗，而非回報一個成功的複製結果；當你變更搜尋或類別時，先前的複製訊息將會被清除，以免陳舊的輸出洩漏到你的編輯器中。
在 Java 中使用 ASCII 碼：實用的模式
一旦你掌握了精確的數值，幾個模式就能涵蓋大部分實際的 Java 工作。第一種是簡單的轉型：int code = (int) 'A'; 會產生 65，接著你可以使用 String.format("0x%02X", code) 將其格式化為 0x41，與表格中的十六進位欄相符。第二種模式是針對 ASCII 數字和字母的範圍測試，當你特別需要 ASCII 行為時，可避免使用對地區設定敏感的方法：
boolean isAsciiDigit(char c) { return c >= '0' && c <= '9'; } boolean isAsciiUpper(char c) { return c >= 'A' && c <= 'Z'; } boolean isAsciiLower(char c) { return c >= 'a' && c <= 'z'; }第三種模式是反方向的轉換，當通訊協定給你一個整數，而你必須產生一個字元時就需要用到。因為 ASCII 與 Unicode 在 0 到 127 的範圍內是一致的，將該範圍內的一個 int 轉型為 char 就會產生對應的 ASCII 字符。對於沒有可列印字符的控制代碼，應使用 RFC 20 中的縮寫（例如 LF 或 CR）作為記錄時的正確標籤，而非嘗試列印該位元組。
第四種模式是處理行尾字元。Java 的 BufferedReader 在 Unix 風格的檔案上讀取 LF，在 Windows 風格的檔案上讀取 CRLF，而 Scanner 則將 CR、LF 和 CRLF 都視為行結束符號。了解 LF 是十進位 10、CR 是十進位 13 後，你就能撰寫明確的掃描器，以任一位元組進行斷詞——這在解析網路通訊協定或混用行尾字元具有意義的精簡二進位記錄時非常有用。RFC 20 的慣例在此適用，但 CR、LF 和 CRLF 是依賴情境的平台與通訊協定慣例，因此表格提供數字，而周圍的程式碼則決定其意義。
值得了解的搜尋技巧與邊角情況
ASCII 表格有幾項行為一旦內化後就能節省時間。類別篩選器可將表格縮限為控制字元、空白、標點符號、數字、大寫字母、小寫字母或刪除字元，且每個相符的列都會保持顯示而非被截斷，因此像「punctuation」這類廣泛的類別仍會顯示完整的標點符號範圍。十進位 32 明確顯示為 SP 並歸入 Space 類別，而十進位 127 則顯示為 DEL 並歸入其專屬的 Delete 類別，因為 RFC 20 指出 DEL 在嚴格意義上並非控制字元。這些區分讓表格能誠實地呈現哪些是可列印字元、哪些是控制字元，以及哪些是歷史悠久的刪除標記。
當你將某列貼到註解中時，請優先選擇四種數值表示法並列，而非僅使用十進位。程式碼審查者能比單純的數字 74 更快察覺 0x4A 中的筆誤，而一份同時列出十進位、十六進位、八進位和二進位的錯誤報告，無論閱讀者如何重新排版，都能保持完整。如果在你正在解碼的檔案中出現了高於 127 的位元組，表格中將找不到它，因為該範圍已超出標準 ASCII；請先辨識實際的編碼，因為僅憑數字並無法告訴你原本要表示的是哪個字符。ECMA-6 記載了產生此邊界的 7 位元範圍，而一份相關標準參考的副本可以放在書籤中與該工具並列，以備不時之需。