UTF-8 与 ASCII 的区别：字符编码的包容与克制
ASCII 是 1963 年定稿的 7 位字符编码，只收录 128 个英文字符；UTF-8 则是覆盖全部 Unicode 的变长编码。两者的关键纽带在于：UTF-8 对前 128 个码点的处理与 ASCII 完全一致，这让几十年的旧文本在新体系里无缝存活。
| 对比维度 | UTF-8 | ASCII |
|---|---|---|
| 字符覆盖范围 | 全部 Unicode：中文、日文、阿拉伯文、emoji、数学符号一网打尽（超 14 万字符） | 仅 128 个：英文大小写字母、数字、常见标点与控制符 |
| 编码长度 | 变长 1–4 字节：英文字符 1 字节、常用汉字 3 字节、emoji 通常 4 字节 | 固定 1 字节（7 位有效位），长度可预测 |
| 相互关系 | 是 ASCII 的超集：合法 ASCII 文件就是合法 UTF-8 文件，字节完全相同 | 是子集：遇到任何非英文字符直接无能为力 |
| 多语言支持 | 同一份文档可混排中英日韩与符号，是国际化产品的唯一现实选择 | 零支持：中文用户名、西语重音字母（á é ñ）都会丢失或报错 |
| 纯英文场景体积 | 与 ASCII 完全相同——每个字符恰好 1 字节，无额外开销 | 基准线：每字符 1 字节 |
| 协议与系统现状 | 互联网事实标准：WHATWG 规定浏览器必须默认 UTF-8，JSON、现代 Linux 与 Git 均以它为准 | 作为「安全子集」活在协议关键字里：HTTP 方法名、早期域名规范与 SMTP 命令仍要求 ASCII |
| 适用场景 | 一切面向用户的文本存储与传输：网页、API、数据库、源代码文件 | 受限环境下的协议字段、机器标识符与需要严格单字节的底层解析 |
何时选 UTF-8？
除非有硬性约束证明不行，一律用 UTF-8。它是唯一能同时容纳多语言内容、又对旧 ASCII 数据完全兼容的选择，也是 JSON、HTML5 与主流操作系统的默认假设。
何时选 ASCII？
当你明确知道数据只会是英文且下游解析器按单字节切分——某些老式协议头、串口通信、定长记录文件——ASCII 或等价的单字节约束仍有价值，能杜绝多字节截断类 bug。
相关在线工具
在线UTF-8转码工具
在线 UTF-8 与中文互转工具，将中文及非 ASCII 字符转为 Unicode 转义序列（Emoji 自动拆分代理对），也可将转义序列一键还原为原文，适用于代码调试与配置文件处理，全部本地完成。
在线HTML实体编码/解码工具
在线 HTML 实体编码与解码工具，将 & < > " ' 及中文等非 ASCII 字符转为命名实体或 &#xxxx; 数字实体，解码支持 40+ 常见命名实体与十进制/十六进制数字实体，防止 XSS 与标签冲突，全部本地处理。
在线文本与十六进制互转工具
在线文本与十六进制互转工具，基于 UTF-8 编码将任意文本（含中文、emoji）转为十六进制字节序列，字节值两位补零、空格分隔，支持双向转换与容错解析，全部本地处理。
常见问题
UTF-8 文件需要加 BOM 吗？
一般不需要，BOM 反而会让某些 Linux 工具和 PHP 老版本误判。唯一常见例外是给 Windows Excel 用的 CSV——加 BOM 能避免中文乱码。
为什么老系统里 ASCII 和 UTF-8 会混着用？
因为两者在英文部分字节级相同，系统不报错就能跑，直到某天用户输入了一个带重音的名字才暴露问题。这也是国际化测试要用非英文数据的原因。
一个汉字在 UTF-8 里占几个字节？
常用汉字（基本区 U+4E00–U+9FFF）占 3 字节；生僻扩展区汉字可能占 4 字节。这也解释了为什么按「字符数」计费的系统和按「字节数」计费的系统结果不同。
延伸说明
排查乱码问题的第一步永远是确认「字节流是什么编码、被当成什么编码解读」。典型事故链是：文件实际是 UTF-8，却被按 Latin-1 打开，于是每个汉字变成两三个奇怪符号。反过来，把 UTF-8 当 ASCII 处理则更危险——按字节数截断字符串会把一个汉字拦腰斩断。站内提供 UTF-8 编解码与文本转十六进制工具，可以逐字节查看真实存储内容，配合本地处理快速定位编码错配的环节。