一个“鱼”字,在电脑里到底是怎么保存的?

我们每天都会在电脑、手机里输入文字，但你有没有想过，当我们在记事本中输入一个“鱼”字，并点击保存时，硬盘里真的存进去一个“鱼”字吗？

答案当然是：没有。

硬盘不认识汉字，也不认识英文字母。它最终保存的，只是一串二进制数据。例如，简体“鱼”和繁体“魚”，在 UTF-8 编码下分别是：

鱼：E9 B1 BC

魚：E9 AD 9A

那么，这些十六进制数字是怎么变成文字的？这就要从最早的 ASCII 编码说起。

一、为什么字符“1”是 31？

早期计算机主要用于处理英文，因此产生了 ASCII 编码。ASCII 为英文字母、数字、标点和控制符分配了固定编号。例如：

字符	十进制	十六进制	二进制
`0`	48	`30`	`0011 0000`
`1`	49	`31`	`0011 0001`
`2`	50	`32`	`0011 0010`
`A`	65	`41`	`0100 0001`
`B`	66	`42`	`0100 0010`

所以，当我们在文本文件中输入：1，文件中实际保存的字节是：31，这里的 31 是十六进制，换成十进制就是：0x31 = 49。字符“1”和数值 1，并不是一回事，字符“1”是用来显示的文字，其 ASCII 编码是：31。

一个32位整数 1，在常见的小端系统中，内存里可能是：01 00 00 00，也就是说：数值 1 ≠ 字符“1”，一个用于数学计算，一个用于显示文本。

二、ASCII 能表示多少字符？

标准 ASCII 使用7个二进制位，它一共可以表示：2⁷ = 128个编号，范围为：

十进制：0～127

十六进制：00～7F

其中既有可见字符：A、B、a、b、0、1、!、@，也有一些控制字符：

名称	十进制	十六进制	作用
TAB	9	`09`	制表符
LF	10	`0A`	换行
CR	13	`0D`	回车
ESC	27	`1B`	转义
DEL	127	`7F`	删除控制符

Windows 文本文件传统上使用：0D 0A，也就是：CR + LF 作为换行。

Linux 通常只使用：0A，也就是 LF。

这也是不同系统的文本文件，有时会出现换行显示异常的原因。

三、ASCII 为什么无法保存中文？

ASCII 只能表示128个字符，可以保存：Fish，对应字节为：46 69 73 68，但它无法保存：鱼。因为“鱼”不在 ASCII 的字符表里。所以，随着计算机进入不同国家和地区，各地开始制定自己的字符编码，例如：

中国大陆：GB2312、GBK

中国台湾地区：Big5

日本：Shift-JIS

韩国：EUC-KR

这些编码通常会保留 ASCII 的 00～7F 区域，然后使用两个或更多字节表示本地文字，例如：

字符“1”：31

简体“鱼”的 GBK：D3 E3

繁体“魚”的 Big5：B3 BD

字符串：1鱼，保存为 GBK 时，字节是：31 D3 E3

字符串：1魚，保存为 Big5 时，字节是：31 B3 BD

可以看到，无论使用 GBK 还是 Big5，字符“1”仍然是 31。

四、Unicode 是什么？

各个国家和地区都有自己的编码，会带来一个很大的问题，就是同一组字节，在不同编码里，可能代表完全不同的字符，为了统一全世界的文字，Unicode 出现了。Unicode 为字符分配一个统一编号，这个编号叫作码点，例如：

字符“1”：U+0031

简体“鱼”：U+9C7C

繁体“魚”：U+9B5A

方框对勾“☑”：U+2611

可以把 Unicode 码点理解为字符的“身份证号码”。其中：U+，表示这是一个 Unicode 码点，后面的数字采用十六进制表示，例如：

鱼 = U+9C7C

魚 = U+9B5A

需要特别注意：

简体“鱼”和繁体“魚”不是同一个字符换了一种字体，而是两个不同的 Unicode 字符。它们含义相关，但码点不同。

五、Unicode 码点不等于文件字节

Unicode 解决的是：这个字符是谁。

但文件和网络最终只能保存、传输字节，因此，还需要一套规则，把 Unicode 码点转换成字节。常见的 Unicode 编码方式包括：UTF-8、UTF-16、UTF-32，例如：

简体“鱼”：

Unicode：U+9C7C

UTF-8：E9 B1 BC

UTF-16 LE：7C 9C

UTF-16 BE：9C 7C

繁体“魚”：

Unicode：U+9B5A

UTF-8：E9 AD 9A

UTF-16 LE：5A 9B

UTF-16 BE：9B 5A

同一个字符采用不同编码保存，得到的字节也不同。

六、UTF-8、GBK 和 Big5 都是 Unicode 吗？

当然不是。UTF-8 是 Unicode 的编码方式，UTF-8 专门用于把 Unicode 码点转换成字节，例如：

鱼：U+9C7C

按照 UTF-8 规则编码后：

E9 B1 BC

因此可以简单理解为：Unicode 规定字符编号，UTF-8 规定编号如何存成字节，GBK 不是 Unicode，GBK 是传统中文编码，有自己独立的字符映射表。例如：

D3 E3 → 鱼

F4 7E → 魚

GBK 和 Unicode 之间可以转换，但 GBK 本身不是 Unicode 编码。Big5 也不是 Unicode，Big5 是传统繁体中文编码，同样拥有自己的字符表。例如：

B3 BD → 魚

（另，标准 Big5 通常不能表示简体“鱼”。）

对比如下：

字符	Unicode	UTF-8	GBK	Big5
`1`	`U+0031`	`31`	`31`	`31`
鱼	`U+9C7C`	`E9 B1 BC`	`D3 E3`	不支持
魚	`U+9B5A`	`E9 AD 9A`	`F4 7E`	`B3 BD`

七、GBK 和 UTF-8 是怎么转换的？

GBK 和 UTF-8 一般不会直接互相“硬算”，转换通常要经过 Unicode 字符这一层，例如，简体“鱼”从 GBK 转换为 UTF-8：

GBK 字节：D3 E3

↓ （按 GBK 解码）

Unicode 字符：鱼（U+9C7C）

↓（按 UTF-8 编码）

UTF-8 字节：E9 B1 BC

繁体“魚”从 Big5 转换为 UTF-8：

Big5 字节：B3 BD

↓（按 Big5 解码）

Unicode 字符：魚（U+9B5A）

↓（按 UTF-8 编码）

UTF-8 字节：E9 AD 9A

因此，现代程序内部通常先把外部字节解码成 Unicode 字符，再根据需要编码为另一种格式。

八、为什么会出现乱码？

字节本身并不天然代表某个字符，它必须配合正确的编码规则，才能被解释为文字。例如，简体“鱼”的 UTF-8 字节是：

E9 B1 BC

如果软件按照 UTF-8 解码，就会显示：

鱼

但如果软件错误地把它当成 GBK 字节读取，就可能显示成别的汉字、特殊符号，甚至出现无法识别的内容。可以把它理解为，实际语言：日语，使用词典：英语词典，结果：翻译失败。

因此，正确显示文字需要两个条件：

正确的字节 + 正确的字符编码

所谓乱码，很多时候并不是文件损坏，而是保存时用了一套编码，打开时却用了另一套编码。

九、UTF-8 为什么成为主流？

UTF-8 已经成为互联网、程序开发和跨平台文本交换中最常见的编码。它有几个明显优势：

1. 可以编码全部 Unicode 字符，UTF-8 可以表示 Unicode 中定义的字符，包括：

中文：鱼、電腦

英文：Hello

日文：こんにちは

韩文：안녕하세요

俄文：Привет

阿拉伯文：مرحبا

Emoji：😀🐟✅

不过需要区分：

能保存：编码支持这个字符；

能显示：字体中存在对应字形。

有些生僻字虽然可以正常保存在 UTF-8 文件中，但如果当前字体不支持，可能显示成：

□

这通常是字体问题，不一定是编码问题。

2. UTF-8 完全兼容 ASCII

ASCII 范围内的字符，在 UTF-8 中保持不变，例如：

字符“1” ASCII：31 Unicode：U+0031 UTF-8：31

字符“A” ASCII：41 Unicode：U+0041 UTF-8：41

这意味着原有的英文文本、程序代码和网络协议，可以自然兼容 UTF-8。

3. UTF-8 是变长编码，UTF-8 根据字符范围使用不同数量的字节。

字符类型	UTF-8 字节数
英文、数字、基础符号	1字节
很多欧洲文字	2字节
常见中文、日文、韩文	3字节
部分生僻字和 Emoji	4字节

例如：

1 → 31

鱼 → E9 B1 BC

魚 → E9 AD 9A

😀 → F0 9F 98 80

十、一个文件里实际存了什么？

假设在记事本中输入：1鱼魚，并使用 UTF-8 无 BOM 保存，文件中的实际字节是：

31 E9 B1 BC E9 AD 9A

拆开来看：

31 字符“1”

E9 B1 BC 简体“鱼”

E9 AD 9A 繁体“魚”

如果保存成带 BOM 的 UTF-8，文件开头会增加三个字节：

EF BB BF

完整内容变成：

EF BB BF 31 E9 B1 BC E9 AD 9A

其中：

EF BB BF UTF-8 BOM

31 字符“1”

E9 B1 BC 简体“鱼”

E9 AD 9A 繁体“魚”

这里也能看出，文本文件里并没有真正保存“鱼”的图形，而是保存了一串字节。

十一、UTF-8 和带 BOM 的 UTF-8 有什么区别？

BOM 是 Byte Order Mark，中文常译为“字节顺序标记”。对于 UTF-8 来说，它不负责解决大小端问题，更多是作为一个文件签名，用于告诉软件：这个文件采用 UTF-8 编码。UTF-8 BOM 的固定字节是：EF BB BF。

普通 UTF-8 文件：

31 E9 B1 BC

带 BOM 的 UTF-8 文件：

EF BB BF 31 E9 B1 BC

通常可以这样选择：

使用场景	推荐
程序源代码	UTF-8，无 BOM
JSON、配置文件、日志	UTF-8，无 BOM
HTML、接口数据	UTF-8，无 BOM
普通文本	UTF-8
部分旧版 Excel 打开的 CSV	UTF-8，带 BOM
老旧 Windows 软件	根据软件要求决定

十二、记事本里的 ANSI、UTF-16 和 GB18030 是什么？

Windows 记事本保存文件时，常见以下选项：

ANSI，ANSI 并不是一种全球统一的编码。

在简体中文 Windows 中，它通常对应当前系统代码页，常见的是 CP936，大体相当于 GBK。但在英文、日文或其他语言系统中，“ANSI”可能代表不同编码。因此，ANSI 文件跨系统使用时比较容易乱码。

UTF-16 LE，LE 是 Little Endian，也就是小端字节序。例如简体“鱼”：UTF-16 LE：7C 9C

UTF-16 BE，BE 是 Big Endian，也就是大端字节序。简体“鱼”：UTF-16 BE：9C 7C

二者表示同一个字符，只是字节顺序不同。

GB18030，GB18030 是我国的国家标准字符编码，也是 GBK 的扩展。（GBK是GB2132的扩展）它能够表示比 GBK 更多的字符，并与 Unicode 建立映射关系。不过在普通程序开发、网页和跨平台文本交换中，UTF-8 仍然更加常见。

十三、那个需要 MagicWin 的年代

经历过 Windows 95、Windows 98 的用户，可能还记得一个软件：

MagicWin

当年不同国家和地区使用的编码并不统一，例如：

中国大陆软件：GB2312、GBK

中国台湾地区软件：Big5

日本软件：Shift-JIS

如果在简体中文 Windows 中运行一个使用 Big5 编码的繁体游戏，系统可能会错误地按照 GBK 解释文字。于是菜单、按钮和剧情就会变成乱码。

MagicWin 这类工具的作用

帮助旧版 Windows 和应用程序识别、转换或显示不同的内码。大致过程可以理解为：

游戏中的 Big5 字节

↓

按照 Big5 解码

↓

识别出对应文字

↓

使用合适的字库显示

它解决的并不只是简体和繁体之间的转换，而是：

这串字节究竟应该按照哪一种编码解释

在 Unicode 和 UTF-8 尚未全面普及的年代，MagicWin、南极星等软件，承担了多语言兼容层的角色。当年打开繁体游戏之前先开 MagicWin，就像现在运行老游戏之前先设置兼容模式。

不是游戏不会说中文，而是电脑听不懂它说的那套“方言”。😂

十四、C# 中的字符串是什么编码？

在 C#中，string text="1鱼魚";.NET 的 string 在逻辑上保存的是 Unicode 字符序列，底层使用 UTF-16 代码单元表示。当字符串需要写入文件、数据库字段或网络时，才要决定输出编码。转换成 UTF-8：

byte[] bytes=Encoding.UTF8.GetBytes("1鱼魚");

得到：

31 E9 B1 BC E9 AD 9A

转换成 GBK：

Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);

Encodinggbk=Encoding.GetEncoding("GBK");

byte[] bytes=gbk.GetBytes("1鱼魚");

得到：

31 D3 E3 F4 7E

所以，程序中的字符串和文件中的字节，并不是完全相同的概念。

十五、现在保存文件应该选什么编码？

对于现代项目，可以采用一个简单原则：

默认使用 UTF-8，只有对接旧系统时才使用其他编码。

使用场景	推荐编码
TXT 普通文本	UTF-8
C#、Java、Python、JavaScript	UTF-8
HTML、CSS、JSON、XML	UTF-8
网络接口	UTF-8
配置文件和日志	UTF-8
Excel CSV	UTF-8 BOM
老旧中文软件	GBK
国内特定行业系统	GB18030
老旧繁体中文系统	Big5

尤其是在工业软件、旧数据库、串口设备和历史接口中，不能因为 UTF-8 更现代，就直接修改编码。编码选择最重要的原则是：

发送方和接收方使用相同的编码规则

总结

最后把几个核心概念放在一起：

字符：我们看到的“1”“鱼”“魚”

ASCII：早期英文字符编码

字符“1”的十六进制编号是 31

Unicode：为全世界的字符分配统一编号

鱼 = U+9C7C

魚 = U+9B5A

UTF-8：把 Unicode 码点编码成字节

鱼 = E9 B1 BC

魚 = E9 AD 9A

GBK：传统简体中文编码

鱼 = D3 E3

魚 = F4 7E

Big5：传统繁体中文编码

魚 = B3 BD

计算机看到的始终只是数字，真正把这些数字解释成“1”“鱼”和“魚”的，是人们共同约定的字符编码规则。所以，电脑里并没有真正养着一条“鱼”。它保存下来的，只是：

E9 B1 BC

最后再举个栗子：

比如早期的《三国志》《轩辕剑》《大富翁》等繁体中文版的游戏，另外当年的日文游戏或软件经常用Shift-JIS，但是Windows 错误按照GBK来计算，所以也容易出现乱码，比如：

假设游戏菜单中有日文：

開始

也就是“开始”。

按照日文 CP932 编码，它的字节是：

開始 → 8A 4A 8E 6E

日文 Windows 按照 CP932 读取：

8A 4A 8E 6E    ↓ CP932開始

但是，如果简体中文 Windows 错误地按照 GBK 解码：

8A 4A 8E 6E    ↓ GBK奐巒

于是游戏菜单中原本应该显示的：

開始

就可能变成：

奐巒

这就是非常典型的乱码。

“鱼”的保存，简单介绍完了，

下期可以聊聊通信协议……