在编程和日常办公中，你一定遇到过“乱码”问题：明明写的是“你好”，结果打开文件后却成了 ÄãºÃ。这个问题的根源，就在于字符编解码, 本文将带你从头理清：

• 为什么需要编码
• Unicode 与 UTF-8 的关系
• GBK、UTF-8 的差别
• 为什么 UTF-8 使用最广
• UTF-8 的基本原理与注意事项（特别是换行符）
• 编辑器如何识别和处理编码
• 未来可能的发展方向

为什么需要编码？

计算机只能存储和处理 二进制数字，而人类使用的是文字，编解码就是一座桥梁，把人类的文字和计算机的数字一一对应起来：

例如：

• ASCII 里，字母 A 的编码是十进制 65，16进制是0x41。
• GBK/UTF-8 中，“你”对应的二进制就会不同。

编码和解码规则不统一就会出现“你写的和我看到的不一样”的情况（比如你用utf-8编码来存储一个文本，传递给我，我用GBK来解码打开），也就是乱码。

常见的编码方式

• ASCII
  早期标准，只包含英文+英文字符，1 个字节（0–127）。
• GBK/GB2312
  中文扩展编码，用两个字节表示汉字。
• Unicode
  一个全球统一的字符集，给每个字符一个唯一编号，比如“你”是 U+4F60  。
• UTF-8
  Unicode 的一种实现方式，用可变长度字节表示字符，兼容 ASCII，节省存储。

Unicode 与 UTF-8 的关系

很多人会把 Unicode 和 UTF-8 混淆，其实它们分属不同层面：

• Unicode是字符集标准，为全世界的每一个字符分配唯一编号（码点）。
• “你” → U+4F60
  其中：U+：表示这是一个 Unicode 码点（Unicode Code Point）。
  4F60：十六进制数字，表示这个字符的编号。
            换成十进制就是：4F60₁₆ = 20320₁₀。

所以 U+4F60 就是 Unicode 给“你”这个汉字分配的唯一编号 20320

• UTF-8 / UTF-16 / UTF-32是编码方式，用来把 Unicode 编号转换为实际存储的字节流。

举例：“你”（U+4F60）：

• UTF-8 → E4 BD A0 （3 字节）
• UTF-16 → 4F 60 （2 字节，LE 序）

👉 可以这么理解：

• Unicode 是“全球字符身份证号”，解决“每个字符的唯一标识是什么”的问题。
• UTF-8/16 是“存储方案”，解决“怎么存起来这个唯一标识”的问题。

为什么 UTF-8 最流行？

1. 兼容性好
   UTF-8 对 ASCII 完全兼容，英文存储不变。
2. 通用性强
   支持所有语言，解决跨国开发、跨平台协作问题。
3. 互联网普及
   HTML、JSON 等网络协议几乎都默认 UTF-8。
4. 跨系统一致性
   Linux、Mac、现代 Windows 都推荐 UTF-8。

UTF-8 的基本原理

UTF-8 是 变长编码：

• 英文等常用字符 → 1 个字节
• 欧洲符号 → 2 个字节
• 中文、日文等 → 3 个字节
• 生僻字符、emoji → 4 个字节

例如：

• A：41（1 个字节）
• 你：E4 BD A0（3 个字节）

这样既保证了对英文文本的高效，又能覆盖全世界的字符。

UTF-8具体规则大致是这样的：

0xxxxxxx                          （1 字节，ASCII）110xxxxx 10xxxxxx                 （2 字节）1110xxxx 10xxxxxx 10xxxxxx        （3 字节）11110xxx 10xxxxxx 10xxxxxx 10xxxxxx （4 字节）

• 第一个字节的前缀（0 / 110 / 1110 / 11110）决定了字符的长度。

• 后续字节都以 10 开头，避免和 ASCII 冲突。

举个例子：

汉字 “你” → Unicode 码点（唯一标识）是 U+4F60。
转成 UTF-8 是三个字节：11100100 10111101 10100000

编码中的注意事项

1. 换行符差异

• Windows：\r\n
• Linux/Unix：\n
• macOS（早期）：\r

不同系统间交换文件时，如果工具没处理好，就可能导致一行变多行，一般vscode等编辑器会提供选择换行显示的功能

2. BOM（Byte Order Mark）

  BOM 是文件开头的特殊字节，用于标识编码（和字节序），方便程序正确解析文本。

• 有些 UTF-8 文件开头会加 BOM (EF BB BF)，表明自己是 UTF-8。
• 但很多工具（特别是 Linux 系统程序）会把 BOM 当成内容，从而出错。
• 建议大部分场景下用 UTF-8 无 BOM。

3. 混用风险

• 用 GBK 保存的文件，如果用 UTF-8 打开，会显示乱码。
• UTF-8 文件如果硬套 GBK 打开，同样会出现奇怪字符。

编辑器如何识别编码？

很多人以为编辑器“自动识别”编码格式的，其实背后有一套规则：

1. BOM 标记

• UTF-8 with BOM：EF BB BF
• UTF-16 LE：FF FE
• UTF-16 BE：FE FF有 BOM 时，编辑器几乎能 100% 确定编码。

• HTML：<meta charset="UTF-8">
• Python：# -*- coding: utf-8 -*-编辑器会优先参考这些。

• Windows 早期默认 GBK/Shift-JIS 等本地化编码。
• Linux/Unix 默认 UTF-8。
• 编辑器没发现 BOM 或声明时，通常就按“系统/用户配置”的默认来。

• 根据字节分布规律来推测。
• 但这种方式并不可靠，经常出现误判。

👉 所以：乱码往往是“（在一台设备）写文件时用了一种编码，（在另一台设备不同的编辑器）读文件时用另一种编码”造成的。

编辑器与编码操作：重新选择编码，究竟改了什么？

常见编辑器支持情况：

• VS Code
  底栏可切换“以某编码重新打开”或“以某编码保存”。
• Notepad
  菜单里直接切换 GBK、UTF-8（有/无 BOM）。
• JetBrains 系列
  自动检测 + 手动指定。
• Windows 记事本
  新版默认 UTF-8（带 BOM），老版多为 ANSI。

关键区别：

• 重新以某编码“打开”文件
  👉 相当于换一副“眼镜”看同样的字节流，文件本身没变。 以某编码“保存”文件👉 真正把内存里的字符重新编码成新的字节流，从而改写了文件。

一句话总结：

• 打开时换更改编码方式 = 不改文件，只改解码方式。
• 保存时换编码 = 改变文件字节流。

未来的发展趋势

1. UTF-8 将成为事实标准

• W3C、IETF 等几乎都推荐 UTF-8。
• 操作系统和编程语言也在统一过渡。
  
  

• 未来编辑器可能会结合 AI，几乎零错误地推断文件编码。
  
  

• GBK、Shift-JIS 仍在少数存量项目中使用，但新系统和软件基本都转向 UTF-8。

总结

• 编码是“人类文字 ↔计算机中的数字”的桥梁。
• UTF-8 因兼容性和通用性成为最广泛的标准。
• BOM、换行符、保存编码方式等细节要格外注意。
• 编辑器识别编码依赖 BOM、声明、默认配置和启发式猜测，并非全能。
• 重新选择编码方式保存文件，其实就是修改了文件内容。
• 未来趋势很明确：UTF-8 一统天下。

阅读原文：原文链接