ASCII 表，免费
128 个 ASCII 字符的完整参考，包含十进制、十六进制、八进制和二进制编码。
显示 128 个字符
关于 ASCII
ASCII（American Standard Code for Information Interchange，美国信息交换标准代码）是一种 7 位字符编码标准，定义了 128 个字符。它于 1963 年首次发布，是大多数现代字符编码（包括 UTF-8）的基础。
字符区间
- 0–31 · 控制字符（不可打印）
- 32 · 空格
- 33–47 · 标点与符号
- 48–57 · 数字 0–9
- 65–90 · 大写字母 A–Z
- 97–122 · 小写字母 a–z
- 127 · DEL（删除）
ASCII 与 Unicode 有什么区别？
ASCII 在 7 位中定义 128 个字符。Unicode 是一个超集，覆盖来自所有书写系统的 149,000 多个字符。Unicode 的前 128 个代码点与 ASCII 相同。
如何在编程中使用这些编码？
JavaScript 中：String.fromCharCode(65) → 「A」。Python 中：chr(65)。C 中：(char)65。十六进制值可用于转义序列：\x41 = 「A」。
使用方法
- 浏览完整表格：所有128个ASCII字符按码位顺序（0至127）排列在网格中。每个单元格显示可见字符（或控制字符的缩写）、十进制编码，以及对应的十六进制/八进制/二进制等价形式。
- 按类别筛选：使用下拉菜单缩小范围，可筛选控制字符（0-31）、可打印字符（32-126）、字母、数字或符号。当你只关注某个特定区块（如标点符号）时非常实用。
- 搜索：搜索框支持按字符名称（「LF」）、缩写或数值（十进制或十六进制）匹配。输入
0x41、65或A均可跳转到同一个单元格。 - 点击单元格可将任意表示形式复制到剪贴板。当你需要ANSI转义的
\x1B、Unix换行符的0x0A，或空格的十进制32时非常方便。
ASCII简史
ASCII（美国信息交换标准代码）由IBM工程师Bob Bemer于1961年5月向美国标准协会X3.2子委员会提出，目标是取代当时在用的十几种互不兼容的字符编码。第一个发布版本是ASA X3.4-1963；小写字母直到1967年修订版才加入。此后该标准以ANSI X3.4-1986的名称多次重新确认，并通过其国际孪生版本ISO/IEC 646（以及欧洲的ECMA-6）奠定了所有现代字符编码的基础。
在网络应用中，ASCII由RFC 20「网络交换ASCII格式」加以编纂，该RFC于1969年10月16日发布，由时在加州大学洛杉矶分校的Vint Cerf撰写。RFC的建议（「将7位ASCII嵌入8位字节中，其高位始终为0」）至今仍是所有现代编程语言和协议处理纯文本的方式。美国联邦政府通过1968年总统Lyndon B. Johnson的行政命令，要求所有联邦计算机自1969年7月1日起支持ASCII，从而确保了整个行业的广泛采用。
为什么是七位？
X3.2委员会面临两个都不理想的选择。6位编码（ITA2等旧式电报字母表所使用的）不可靠：在噪声线路上发生单比特翻转，如果恰好落在移位位上，就会导致此后所有字符都被错误解码。8位编码在内存昂贵、调制解调器缓慢的年代显得浪费。最终的折中方案是7位 = 128个码位，将第8位留给奇偶校验。将奇偶校验位设置为使每个字节具有偶数（或奇数）个1的个数，能够捕获100%的单比特传输错误，这正是20世纪60年代声学耦合器和串行电缆所产生的问题。
随着误码率下降和调制解调器速度的提升，第8位被重新利用。各种国家「扩展ASCII」代码页（Latin-1、Windows-1252、Mac Roman、KOI8-R…）使用128-255的编码存放重音字母和制表符绘图字符，但这些映射相互不兼容，最终被Unicode和UTF-8所取代。
布局：128个码位
7位 = 27 = 128个不同的编码，分为33个控制字符（0-31加上127处的DEL）和95个可打印字符（32-126）：
| 范围 | 十六进制 | 内容 |
|---|---|---|
| 0-31 | 00-1F | 控制字符（NUL、BEL、BS、HT、LF、CR、ESC、FS-US…） |
| 32 | 20 | SPACE，可打印但不可见 |
| 33-47 | 21-2F | 标点符号：! " # $ % & ' ( ) * + , - . / |
| 48-57 | 30-39 | 数字 0-9 |
| 58-64 | 3A-40 | 更多标点符号：: ; < = > ? @ |
| 65-90 | 41-5A | 大写字母 A-Z |
| 91-96 | 5B-60 | 括号与重音符：[ \ ] ^ _ ` |
| 97-122 | 61-7A | 小写字母 a-z |
| 123-126 | 7B-7E | 花括号与波浪号：{ | } ~ |
| 127 | 7F | DEL，穿孔纸带上的「擦除」键（二进制 1111111） |
仍然重要的控制字符
33个控制字符中大多数起源于电传打字机和纸带命令，如今已成历史文物。少数至今仍是日常计算中的支柱：
- NUL（0x00）：终止C语言及所有C派生语言中的字符串。将嵌入的null字符粘贴进文件路径是导致旧代码崩溃的经典方法。
- BEL（0x07，
\a）：终端响铃。仍可由printf '\a'触发。 - BS（0x08，
\b）：退格符。进度条库用它来覆盖上一行。 - HT（0x09，
\t）：水平制表符。定义了TSV文件中的制表字符，以及Python解释器那场旷日持久的缩进之争。 - LF（0x0A，
\n）：换行符。Unix的换行方式。 - CR（0x0D，
\r）：回车符。Windows换行符的前半部分；在进度条中单独使用时表示「回到行首」。 - ESC（0x1B，
\e/\x1B）：转义字符。Bemer的原创发明，现在是所有ANSI终端转义序列（颜色、光标移动、清屏）的前缀。 - FS / GS / RS / US（0x1C-0x1F）：文件/组/记录/单元分隔符。最初为20世纪60年代面向记录的磁带存储而设计，此后基本被遗忘，直到RFC 7464 「JSON文本序列」将RS重新引入，作为流式JSON记录（
application/json-seq）的前缀分隔符。GS至今仍出现在某些零售条形码协议中。 - DEL（0x7F）：「擦除键」。Teletype Model 33的RUB OUT键发送码127，因为其二进制形式为
1111111，即所有七位全部置为1。操作员要在纸带上删除字符时，需将纸带倒回并按下RUB OUT键，将现有的所有孔全部打穿。接收端本应忽略任何所有位全为1的字节。
换行符之争
三个平台选择了三种不同的约定，软件为此付出了持续的代价。其机械起源是打字机和电传打字机，需要两个独立动作：回车将打印头移回第1列，换行将纸张向前推进一行。不同系统对是否将其编码为一个字节或两个字节做出了不同决定：
| 操作系统 | 换行符 | 字节 | 转义序列 |
|---|---|---|---|
| Unix / Linux / 现代 macOS | LF | 0x0A | \n |
| 经典 Mac OS（OS X 之前） | CR | 0x0D | \r |
| Windows / DOS | CRLF | 0x0D 0x0A | \r\n |
互联网协议大多要求使用CRLF：HTTP、SMTP、FTP、MIME以及标准互联网消息格式均如此规定。RFC 5322明确指出：「CR和LF只能作为CRLF一起出现；它们不得在消息正文中单独出现。」然而在源代码中，惯例因团队而异，这就是git附带core.autocrlf的原因：在Windows上设为true时，git在工作树中以CRLF检出文件，但在仓库中以LF存储，从而使相同的源文件在每个平台上生成相同的blob哈希。项目级的替代方案是.gitattributes条目中的* text=auto。
ANSI终端颜色转义序列
转义字符（ESC，0x1B）是为终端输出着色的ANSI转义序列的前缀。标准为ECMA-48（1976年），后被镜像为ANSI X3.64并并入ISO/IEC 6429。语法为ESC [加参数加末尾字母；ESC [部分称为控制序列引导符（CSI），根据编程语言的不同写作\e[、\x1b[或\033[。常用SGR（选择图形渲染）代码：
0：重置/正常 ·1：粗体 ·4：下划线 ·7：反转视频30-37：前景色（黑、红、绿、黄、蓝、洋红、青、白）40-47：背景色（顺序相同）90-97/100-107：亮色前景/背景
因此printf '\033[1;31mERROR\033[0m'会以加粗红色打印「ERROR」并随后重置。所有现代终端模拟器（以及2019年以来的Windows Terminal）均支持这些序列。
ASCII与Unicode及UTF-8
ASCII定义了128个码位；Unicode 16.0（2024年发布）涵盖逾154,000个。关键的桥梁是UTF-8，网络上的主流文本编码（2026年约98%的网站采用）：UTF-8的设计使任何7位ASCII字节（0x00-0x7F）与原来编码的字符相同，高位为零。实际影响是：每个有效的ASCII文件同时也是有效的UTF-8文件，字节完全相同。127以上的码位编码为多字节序列（2至4字节），每个字节的高位均为1，从而保证旧版ASCII解析器永远不会将其误认为ASCII字符。
ASCII在常用编程语言中的应用
| 语言 | 代码→字符 | 字符→代码 |
|---|---|---|
| JavaScript | String.fromCharCode(65) | 'A'.charCodeAt(0) |
| Python | chr(65) | ord('A') |
| C / C++ | (char)65 | (int)'A' |
| Java | (char) 65 | (int) 'A' |
| Rust | char::from(65) | 'A' as u32 |
| Go | string(rune(65)) | int('A') |
| Bash / sh | printf '\x41' | printf '%d' "'A" |
| HTML | A 或 A | - |
| URL编码 | %41 = 「A」，%20 = 空格 | - |
大小写位技巧
ASCII布局有一个简洁的特性：一个大写字母与其对应小写字母恰好相差一个比特位。A是65 = 0100 0001；a是97 = 0110 0001。仅第5位不同。这使得不区分大小写的比较成为单次位运算：x | 0x20强制转为小写，x & 0xDF强制转为大写，两者均比查找表更快。这是1967年修订版中的一项刻意设计，也是该布局在某些地方看起来「随机」的原因之一：它编码的是对硬件友好的属性，而非仅仅是字母顺序。
常见陷阱
- 将数字0与NUL控制字符混淆。NUL的编码为0；字符「0」的编码为48。两者在任何编程语言中都不可互换。
- 假设一个字节等于一个字符。仅对ASCII文本成立。UTF-8文本的字符是变长的，非拉丁文字的字节长度与字符数可能相差悬殊。
- 在同一文件中混用行尾字符。在同一文件中混用CR/LF/CRLF会使许多解析器出错，并根据操作系统的不同产生幽灵空行或缺失换行。
- C语言字符串终止的差一错误。忘记字符串末尾需要额外一个字节存放NUL是最初的缓冲区溢出漏洞来源。
- 「扩展ASCII」假设可跨平台移植。128-255的编码在Latin-1、Windows-1252、KOI8-R、Mac Roman等编码下含义各不相同。UTF-8是唯一安全的现代选择。
- 在不可信输入中嵌入ESC。如果将用户提供的数据未经过滤直接输出到终端，攻击者可以注入ANSI转义序列来改变颜色、移动光标或清屏，有时可借此隐藏恶意内容。
常见问题
为什么DEL的编码是127而不是0？
因为127的二进制是1111111：所有七位全部置1。要在穿孔纸带上删除一个字符，操作员需将纸带倒回并按下RUB OUT键，将现有的所有孔全部打穿。接收端本应忽略任何所有位全为1的字节，从而使「已删除」的字符在后续读取中消失。这一约定继承自更早的电传打字机编码。
什么是「扩展ASCII」？它是否安全可用？
标准ASCII涵盖码位0-127（7位）。「扩展ASCII」泛指以8位编码填充码位128-255中附加字符的各种编码，包括Latin-1、Windows-1252、KOI8-R、Mac Roman等。问题在于：这些附加字符在不同编码中含义各不相同。从技术上讲，这个名称是误称（那些代码页并非ASCII标准的扩展），且跨系统使用并不安全。UTF-8是现代、可移植的替代方案，并向后兼容原始的0-127范围。
为什么空格（32）被认为是「可打印」字符，而它什么都不显示？
因为它在打印行上占据水平空间，推进打印头的方式与字母完全相同。控制字符则不同，它们改变设备状态而不产生可见输出（BEL发出响铃，BS使打印头后退，LF推进纸张）。这种分类基于字符在打印机上的行为，而非是否有字形。
CR和LF与我键盘上的回车键相同吗？
大体上是的，但键盘产生的字节取决于操作系统。在Windows上按下回车键通常产生CRLF（0x0D 0x0A）；在Linux和现代macOS上只产生LF（0x0A）；在OS X之前的经典Mac OS上只产生CR（0x0D）。许多编辑器会根据文件现有的行尾格式或配置的项目约定在保存时对此进行规范化。
文件/组/记录/单元分隔符为什么会在这里？
它们最初是为20世纪60年代面向记录的磁带存储设计的，层级关系为文件 > 组 > 记录 > 单元。这些字符大多已被弃用，但在两个意想不到的地方重新出现：RFC 7464「JSON文本序列」（媒体类型application/json-seq）使用RS（0x1E）作为前缀来分隔流式JSON记录；GS1应用标识符在零售条形码协议中使用GS（0x1D）作为分隔符。
ASCII在2026年还有意义吗？
非常有。每一个「基于文本」的现代协议（HTTP头部、JSON、YAML、源代码、命令行参数、环境变量、DNS主机名）都在ASCII范围内运作。UTF-8是任意文本的主流编码，但UTF-8的前128个字节值与ASCII完全相同，字节完全一致。了解这张表对于从URL编码到终端颜色，再到调试文本编码错误等一切工作来说都是必要的。