字符编码：让计算机认识人类的文字

你见过“锟斤拷”吗？这些“乱码是怎么来的呢？本文将为你解答”

Myqfeng · 计算机基础篇 · 2026/08/13

阅读 -- 次

计算机基础字符编码

引言：互联网的老梗——“锟斤拷”

经常写代码的人都见过这样的诡异乱码：

锟斤拷锟斤拷锟斤拷

这三个字在中文互联网上流传了几十年，它的成因正是字符编码不匹配：某段被丢弃的文字在 UTF-8 下会变成替代字符”�“（U+FFFD，二进制 EF BF BD），而这些字节被用 GBK 编码的软件重新解读，就拼成了”锟斤拷”。

一句话：同一串 0 和 1，用不同的”字典”去解读，就得到不同的文字。 这个”字典”，就是字符编码。

本文将带你熟悉以下内容：

  • 字符在计算机里到底是什么
  • ASCII：128 个字符的美国元老
  • 各国乱码的”巴别塔”与 Unicode 的救赎
  • UTF-8 变长编码的智慧
  • C 语言中 char 的本质是整数——以及它带来的所有魔法与陷阱

一、计算机里的文字：一场巨大的约定

计算机只认0和1。那么屏幕上的”中”、“A” 这些人类的文字，本质是什么？

答案：它们从来不是”文字”，只是一串按约定解释的数字。

而这一串约定，就是字符编码，字符编码就相当于计算机的”字典”，而编码的值就像是“字典”里的拼音，计算机通过编码的值，查找“字典”就可以得到对应的字符。

65 在 ASCII 编码里是 'A'，在 GBK 编码里可能是别的字，在没有字典的机器里只是一个 0x41 的字节。字符与数字之间的映射关系，就是字符编码（character encoding）。它是一场覆盖全球的”约定”，而历史告诉我们：约定一旦分裂，就是灾难。

二、ASCII：128 个字符的美国元老

1960 年代，美国标准化协会制定了 ASCII（American Standard Code for Information Interchange），用 7 个 bit 编码 128 个字符：

范围含义
0 ~ 31控制字符：换行 LF(10)、回车 CR(13)、制表符 TAB(9) 等
32空格
33 ~ 126可见字符：数字、大小写字母、标点
127DEL（删除）

作为程序员，只需要背下三句话：

'0' 是 48（0x30），'A' 是 65（0x41），'a' 是 97（0x61）。

三个锚点能推导出整个字母表：'Z' 是 65 + 25 = 90，'b' 是 97 + 1 = 98。还有一个惊人的巧合：大写字母与小写字母恰好相差 32（0x20），而 0x20 正是”空格”的编码——所以：

char c = 'A';
printf("%c\n", c | 0x20); // 'a'：按位或 0x20 就是转小写
printf("%c\n", c ^ 0x20); // 'a'：异或 0x20 就是大小写互转

在 C 语言中，一般用一个字节表示一个字符。而标准 ASCII 只用了 7 位，第 8 位空着。

三、扩展 ASCII

一个字节 8 位最多 256 个编码。ASCII 占了 0127，剩下 128255 归谁？

  • 西欧人拿去放 ë、ü 等重音字母，搞出了 Latin-1、CP1252；
  • 日本人需要假名，搞出 Shift-JIS；
  • 韩国人搞出 EUC-KR；
  • 中国人呢？汉字有六万多个，一个字节根本不够——1980 年国家标准 GB2312 决定用两个字节编码一个汉字（1981 年发布），1995 年扩展为 GBK。繁体中文世界则用 Big5。

同一串字节，在不同国家的”字典”里是不同字符——这就是乱码的根源。你写 email 给日本朋友，他看到的可能是满屏乱码；网页编码声明错了，整个页面变成”锟斤拷”。没有全球统一字典的 90 年代，是编码史上最混乱的年代。

四、Unicode：一张收录全世界的表

1991 年，Unicode 联盟带来了一场思路革命：把”这个字符是谁”和”这个字符怎么存”彻底分开。

  • 先给全世界每个字符发一个唯一的身份证号，叫码点（code point），写作 U+XXXX：U+0041 是 ‘A’，U+4E2D 是”中”，U+1F600 是 😀；
  • 目前收录 15 万+ 个字符，上限 U+10FFFF；
  • 码点就是字符的身份，与存储方式无关。

码点分区：日常文字都在基本平面 BMP（U+0000~U+FFFF），表情符号等小众角色在补充平面。但注意：码点不等于字节。 “怎么把码点写进字节”是下一个问题——这正是 UTF-8 登场的时刻。

TIP

Unicode 一般来说是一种编码规则而非具体编码存储方式，其具体实现有多种，比如 UTF-8、UTF-16、UTF-32 等。

五、UTF-8：变长编码的智慧

UTF-8 的设计目标非常苛刻：

  1. 必须与 ASCII 完全兼容——1 字节 0~127 的编码原封不动；
  2. 用 1~4 个字节表示任意码点；
  3. 自同步：随便从字节流中间切开，也能立刻判断哪里是字符开头。

5.1 编码规则

Unicode 范围字节数编码模式
U+0000 ~ U+007F10xxxxxxx
U+0080 ~ U+07FF2110xxxxx 10xxxxxx
U+0800 ~ U+FFFF31110xxxx 10xxxxxx 10xxxxxx
U+10000 ~ U+10FFFF411110xxx 10xxxxxx 10xxxxxx 10xxxxxx

规律一目了然：首字节开头的 0/110/1110/11110 标明了”这个字符共几个字节”，所有续字节都以 10 开头。 正是这个设计，让 UTF-8 可以从任意位置重新开始同步——这就是”自同步”的含义。

5.2 手工演算：把”中”装进 3 个字节

“中”的码点是 U+4E2D，二进制是 0100 1110 0010 1101（16 位），落在 3 字节区间。把它塞进 1110xxxx 10xxxxxx 10xxxxxx 的三个 xxxx 洞：

0100 1110 0010 1101          ← 待编码位
1110xxxx 10xxxxxx 10xxxxxx   ← 3 字节模板
11100100 10111000 10101101   ← 填好
  E4       B8       AD

所以”中”在 UTF-8 下就是 E4 B8 AD。你可以用任何 hexdump 工具验证：中文的 UTF-8 编码总是 3 字节（E4 B8 AD、E6 96 87），而 ASCII 字符永远是 1 字节。

5.3 为什么 UTF-8 赢了

  • ASCII 兼容：纯英文文档在 UTF-8 下与 ASCII 完全一样，旧系统无缝升级；
  • 字节流安全：多字节序列不包含 \0（0x00），不会干扰 C 字符串；
  • 无 BOM 依赖：不需要在文件头声明字节序（对比下文 UTF-16）；
  • 排序稳定：按字节排序 = 按码点排序，索引方便。

如今，Linux、macOS、现代 Web、JSON 全部默认 UTF-8。代价只有一个：中文比 GBK 多占 1 个字节（3 字节 vs 2 字节）——在今天的磁盘和带宽面前，这个代价小到可以忽略。

5.4 其他 Unicode 实现

UTF-16：BMP 内字符 2 字节，补充平面字符用 4 字节代理对。😀（U+1F600）不在 BMP，被拆成高代理 D83D + 低代理 DE00。UTF-16 是 Windows 系统的默认内存编码（Windows API 的 wchar_t），但它在文件层面需要声明字节序——这就是 BOM 的由来。

BOM（Byte Order Mark）：BOM 的本质是 Unicode 字符 U+FEFF（零宽不换行空格），它被放在文件开头充当”字节序探测器”。读取文件时，如果前两个字节是 FE FF，说明字节序与文件一致，是大端；如果读到 FF FE，说明字节序反了，是小端，后续所有字节都要两两翻转。如果读到 EF BB BF，这是 U+FEFF 的 UTF-8 编码，表示这是 UTF-8 文件——虽然 UTF-8 按字节编码本身没有字节序问题，但 BOM 在这里充当”UTF-8 签名”。这就是为什么你偶尔会在 Windows 记事本保存的 UTF-8 文件里，第一行看到多出一个”冏”样的字符——那是 BOM 被其他软件当成内容读了。

UTF-32：每个字符固定 4 字节，简单粗暴但浪费 3 倍空间，现实中几乎不用。

微软的技术债
  1. UTF-8编写的程序在微软控制台打印中文反而乱码
  • 由于早年还没有 Unicode 这样一统全球的编码方式，微软的早期系统采用按地区设置决定编码的方式（例如中国地区使用 GB2312/GBK）。在设计 Windows NT 内核时，Unicode 的标准尚早，微软选择了 UTF-16LE 作为其内部原生编码。后果是：控制台默认代码页是 CP936（GBK），当你的 C 程序以 UTF-8 输出中文时，控制台拿 GBK 去解析 UTF-8 的字节流，自然牛头不对马嘴。虽然最新的 Windows 10+ 允许你修改默认编码，但这也会导致老程序的不兼容。因此：Windows 不兼容 UTF-8 的技术债就延续到了今天。
  1. BOM or BOOM!
  • BOM（Byte Order Mark，字节序标记）是Unicode文本文件开头的一串特殊字节序列，本质上是U+FEFF字符。它最初是为解决UTF-16和UTF-32这类多字节编码的字节序问题而设计的——当文件在不同硬件平台（大端/小端）之间传输时，BOM能明确告知解析器字节的排列顺序，避免数据被错误解读。然而，微软将这个标记延伸到了UTF-8场景中：为了让Windows生态下的记事本等工具能快速区分UTF-8文件和传统ANSI/GBK编码文件，系统默认在保存UTF-8文件时自动添加EF BB BF这3个字节作为“签名”。但问题在于，UTF-8以单字节为编码单元，本身不存在字节序歧义，BOM对它而言完全是多余的。当这类带BOM的文件进入Linux、macOS等跨平台环境时，脚本解释器（如Shell、Python、PHP）会将BOM当作普通字符解析，轻则导致Shell脚本首行#!声明失效，重则让PHP提前输出空白字符，直接破坏HTTP头或Session逻辑。这就是为什么跨平台开发的铁律之一是：‌务必使用UTF-8无BOM格式‌。

六、C 语言中 char 的本质是整数

6.1 ‘A’ 就是 65

C 语言的”字符类型”实际上就是一个字节的整数类型。char 在标准里白纸黑字是一个最小类型的整数，字符常量 'A' 的类型其实是 int，值就是 65：

char c = 'A';
printf("%d %c\n", c, c);  // 输出：65 A
printf("%c\n", c + 1);    // 输出：B（A + 1 = 65 + 1 = 66）

一切字符魔法都来自这个事实。经典用法：

char digit = '7';
int n = digit - '0';      // 字符转数字：'7' - '0' = 55 - 48 = 7

char ch = 'a';
ch -= 'a' - 'A';          // 转大写：'a' - 32 = 'A'
if (ch >= 'a' && ch <= 'z') { /* 判断是小写字母 */ }

为什么能相减？ 因为 ASCII 把数字和字母排成了连续区间：‘0''9’ 连续，‘A''Z’ 连续，‘a’~‘z’ 连续。C 标准只保证数字连续（‘0’+1 == ‘1’），字母连续性靠 ASCII 的约定——在实际世界里这约定从未失效。

6.2 signed char / unsigned char：被忽视的坑

char 有没有符号由编译器决定（标准称之为”实现定义”）。看看这行代码：

char c = 0xC4;      // 200
printf("%d\n", c);  // 在某些编译器上是 -60！

如果你拿 char 当”字节容器”处理二进制数据（比如解析协议），一旦出现 ≥ 0x80 的字节，负数就来了，位移、比较全部出错。处理字节流请一律用 unsigned char，或者直接使用uint8_t类型来表示（uint8_t 是 C99 标准引入的固定宽度整数类型）。

6.3 strlen 数的是字节，不是字符

printf("%zu\n", strlen("你好"));   // 6，不是 2！

UTF-8 下每个汉字 3 字节，“你好”占 6 字节。C 的字符串只是一个以 \0 结尾的字节数组，它根本不知道”字符”是什么。所以处理 UTF-8 文本时：

  • 截断字符串要小心——可能拦腰截断一个汉字的 3 个字节，产生乱码；
  • 不要在字节流中间按 0x00 分界（UTF-8 序列不含 0x00，但 GBK 等可能遇到）；
  • 逐个字节打印，你会看到 E4 B8 AD 在眼前流过——这就是”中”字在计算机里的真面目。

七、总结

编码字节数特点现状
ASCII1（只用 7 bit）128 个字符，英语友好成为历史基石
GBK / Big51~2中文 2 字节，独立字典遗留系统中存活
Unicode（码点）—只编号不存储，U+XXXX全球身份证
UTF-81~4（变长）ASCII 兼容、自同步、无 BOM互联网事实标准
UTF-162 或 4需 BOM 声明字节序Windows 内部使用
UTF-324（定长）简单但浪费基本被淘汰

一句话总结全文：

字符从来不是文字，只是一串按约定解释的数字；char 是整数，字符串是字节流——把这两句话刻进脑子里，乱码就再也伤不到你。

TIP

实战建议

  1. 所有字符都用 UTF-8 （无 BOM）编码，避免使用 GBK 等旧编码。一般的 IDE 都支持设置 UTF-8 编码。
  2. 在 Windows 下开发时，打印的日志/交互提示尽可能使用英文，避免编码问题。
  3. 在接收/发送/存储字节流时，建议使用 uint8_t 类型，避免 char 类型的符号问题。

评论区