Python 的內建 chr() 函式會將介於 0 到 127 之間的十進位 ASCII 值轉換成對應的字元，而 ord() 則對單一字元執行完全相反的操作。例如，chr(65) 會回傳字串 'A'，chr(97) 會回傳 'a'，因為拉丁字母的對應關係是由 IETF RFC 20 所固定,並可與 Unicode C0 控制字元與基本拉丁文對照表 相互核對。雖然這兩個函式接受 Python 能表示的任何整數,但標準的 7 位元 ASCII 僅定義了 128 個字碼點,涵蓋控制字元、標點符號、數字、大寫與小寫拉丁字母,以及 DEL。如果你的來源資料列出像 65、97、48 或 32 這樣的十進位數字,chr() 會分別回傳 'A'、'a'、'0' 以及一個空白;至於 128、200 或 256 等數值,雖然仍會產生一個字元,但它並非標準 ASCII,也無法在以 ASCII 為基礎的系統中乾淨地往返轉換。對於不想撰寫腳本來驗證轉換的讀者,瀏覽器式的 ASCII 轉換器 可接受文字或十進位數字,並以顯示錯誤(而非靜默重新解讀)的方式套用相同的 0-127 邊界。
Python 的 chr() 與 ord() 函式
chr() 與 ord() 在 0-127 範圍內的關係是精確互逆的:對於任何字碼點落在標準 ASCII 之內的單一字元 c,chr(ord(c)) == c 且 ord(chr(n)) == n。這兩個函式在文件中被描述為 8 位元 ASCII 字串的逆運算,該字串對應到七位元範圍加上 Python 為 Latin-1 補充集開頭所保留的 128 高位元位置。由於 Python 字串儲存的是 Unicode 字碼點,chr(200) 會回傳一個不屬於標準 ASCII 的可列印字元;當讀者預期 chr() 表現得像僅限 ASCII 的查表時,這是最常見的混淆來源。
對於批次轉換,串列綜合運算式或生成器運算式是標準慣用法。程式碼片段 [chr(n) for n in [65, 66, 67]] 會產生串列 ['A', 'B', 'C'],而 ''.join(chr(n) for n in [72, 101, 108, 108, 111]) 會產生字串 'Hello'。反向操作則使用 [ord(c) for c in 'ABC'],結果為 [65, 66, 67]。這兩種慣用法都仰賴 Python 能將整數傳入 chr(),並以 ord() 逐一走訪字串中的字元,因此它們在 ASCII、Latin-1 與完整 Unicode 文字上的運作方式完全相同。
0-127 範圍及其包含內容
標準的 7 位元 ASCII 正好定義了 128 個對應關係,編號從 0 到 127。代碼 0 到 31 以及代碼 127 是 C0 控制字元,包括 0 (NUL)、9 (TAB)、10 (LF)、13 (CR),以及 127 (DEL);這些字元通常不會顯示出可見字形。代碼 32 是空白字元。代碼 33-47、58-64、91-96 以及 123-126 涵蓋標點符號與少數符號,例如 !、?、@ 與 ~。代碼 48-57 是數字 0 到 9。代碼 65-90 是大寫拉丁字母 A-Z,代碼 97-122 則是小寫拉丁字母 a-z。
這個固定的對應關係,正是使用 chr() 處理 0-127 數值的 Python 腳本能夠跨作業系統、Python 版本與語言環境皆表現一致的原因。同樣的邊界也說明了為何一個承諾能轉換 ASCII 的工具,必須拒絕或在結果上明確標記任何高於 127 的內容。延伸 ASCII 一詞指的是一族彼此不相容的單字元組編碼,例如 Windows-1252 與 ISO-8859-1,當輸入本應為 7 位元 ASCII 時,任何靜默的回退機制都是不可接受的。關於權威的對應表,請參閱 IETF RFC 20 與 Unicode 基本拉丁文對照表。
使用 ASCII 轉換器將 ASCII 值轉換為字元
當轉換需要在 Python 腳本之外進行時——例如,從教科書、除錯紀錄或同事筆記中複製一份十進位代碼清單——使用瀏覽器式的工具就能避免撰寫或執行程式。ASCII 轉換器執行的 0-127 轉換與 chr() 和 ord() 相同,但會嚴格強制該邊界,並以位置回報無效輸入,而不會產生誤導性的 Unicode 字元。
- 選擇要編碼 ASCII 文字,或是解碼十進位 ASCII 代碼。
- 輸入介於 0 到 127 之間、以空白、逗號或換行分隔的文字或十進位數值。
- 點選「轉換 ASCII」,檢視不可見控制字元的影響,並視需要複製結果。
編碼模式會將輸入中的每個字元轉為以空白分隔的十進位整數,因此 Hi 會變成 72 105。解碼模式則會解析一份以空白、逗號或換行分隔的整數清單,並重建出精確的 ASCII 字串。由於接受的範圍正好是 0 到 127,任何超出該範圍的代幣都會連同其位置一起被拒絕,而且該工具不會將 128-255 的數值靜默地重新解讀為 Windows-1252 或 ISO-8859-1。
常見轉換的 Python 程式碼範例
最常見的工作是單一對單一的查表。給定一個整數,chr(65) 會回傳 'A'。給定一個整數串列,[chr(n) for n in [65, 97, 48, 32]] 會回傳 ['A', 'a', '0', ' ']。以空白、逗號或換行將結果串接起來,即可讓同一份串列回送給預期接收十進位代碼的解碼器。反向操作同樣直接:ord('A') 會回傳 65,而 [ord(c) for c in 'Python'] 會回傳 [80, 121, 116, 104, 111, 110]。
在驗證未知輸入時,明確的範圍檢查能讓腳本保持誠實。if not 0 <= n <= 127: raise ValueError(f'non-ASCII code: {n}') 這個模式能避免靜默產生 Latin-1 或其他延伸字元。這與 ASCII 轉換器所執行的嚴格驗證相互呼應:它會拒絕第一個超出 7 位元 ASCII 範圍的字元並回報其位置,並在解碼端拒絕正負號、分數、十六進位前置詞、空代幣,以及高於 127 的數值。
若想進一步了解反向處理的通用背景——將十進位代碼轉換為下游程式碼實際預期的字元流——十進位代碼轉文字教學 在非 Python 的情境中介紹了相同的邊界規則,並能與以 chr() 為基礎的腳本自然搭配。
處理控制字元與無效數值
代碼 0-31 以及 127 是控制字元,而非可列印字元。十進位 9 是定位點 (tab),10 是換行 (line feed),13 是歸位 (carriage return),0 是 NUL,127 是 DEL。當這些代碼被解碼成字串並貼到終端機、編輯器或聊天視窗中時,接收端的應用程式可能會以不顯示任何字形的方式呈現、將其視為格式控制,或觸發應用程式特有的行為(例如焦點切換或快捷鍵處理)。ASCII 轉換器會透過警告「控制碼在輸出文字區中可能為不可見」來凸顯此風險,並建議在需要可見性的情況下使用十進位輸出或支援位元組的編輯器。
在 Python 中,只要解碼後的字串含有控制字元,同樣的警告便適用。print(chr(9) + 'x') 會在 x 之前顯示一個定位點;print(repr(chr(0))) 會顯示 '\x00' 而非什麼都沒有。驗證解碼結果是否產生預期字碼點的一個安全模式,是使用 repr() 來列印結果,或在迴圈中以 ord() 逐一檢查每個代碼。這也是強制執行 0-127 邊界的正確位置,因為 chr(128) 會回傳一個在任何 ASCII 合約中都沒有立足之地的可列印 Unicode 字元。
Python chr() vs ASCII 轉換器 vs 其他工具
將十進位代碼轉換為字元的不同方法,在自動化、可見性與嚴格性之間各有取捨。下表比較了最常見的幾種做法,以便針對工作挑選合適的工具。
| 方法 | 輸入格式 | 支援的範圍 | 輸出可見性 | 最適合用於 |
|---|---|---|---|---|
| Python chr() / ord() | 整數或單一字元 | 嚴格 0-127 以處理 ASCII;接受任何 Unicode 字碼點 | 完整 Unicode 字形 | 腳本、自動化、批次轉換 |
| ASCII 轉換器 | 文字區中的文字或十進位數字 | 嚴格 0-127,並顯示錯誤 | 控制字元可能呈現為不可見 | 不撰寫程式碼的快速驗證 |
| ASCII 對照表 | 無 (靜態參考資料) | 顯示 0-127 | 靜態圖表 | 查詢單一字碼點 |
| 文字轉十六進位 / 二進位 | 文字 | UTF-8 位元組序列,而非 7 位元 ASCII | 十六進位或二進位字串 | 以其他數字基底編碼文字 |
對於高於 127 的數值,chr() 會回傳一個不屬於標準 ASCII 的 Unicode 字碼點,而 ASCII 轉換器則會直接拒絕該數值。同樣的邊界也適用於十六進位、二進位與 Base64 表示法:它們編碼的是位元組,而不是 ASCII 字碼點,因此當輸入確實超出 7 位元範圍時,必須使用一個明確標示其編碼方式的獨立工具。面對 Unicode 字碼點、UTF-8 位元組或特定語言環境的字元轉換時,正確的做法是選用一個明確標示所需編碼的轉換器,而不是將資料當作 ASCII 來處理。
如果你正在權衡各種選項,Python 中的凱薩密碼解密:從公式到工具 有詳細介紹。