字符编码本质：把字符映射成二进制字节的规则。同样的字节流，用错误编码解析，就会出现乱码、问号、方框、文字错乱。常见编码：ASCII、GB2312/GBK/GB18030、UTF‑8、UTF‑16、UTF‑32。
1、各编码简单说明
ASCII
只支持英文字母、数字、半角符号，不支持中文，1 字节 / 字符。
现象：打开中文文档，中文全部变成乱码。
GB2312 → GBK → GB18030（中文国标）
GB2312：早期简体中文，2 字节汉字，生僻字无法显示。
GBK：兼容 GB2312，支持简繁中文、日文假名、部分符号，Windows 中文系统传统编码。
GB18030：GBK 超集，支持全部中日韩汉字，包含大量生僻字，兼容单字节 ASCII。
Windows 记事本 “ANSI” 实际就是本机区域编码，中文 Windows 就是 GBK。
UTF‑8（互联网主流）
变长编码：英文 1 字节，中文 3 字节，emoji 4 字节。
兼容 ASCII，全球通用，网页、Linux、JSON、程序源码标准编码。
带 BOM 的 UTF‑8：文件开头多出
EF BB BF三个字节，Windows 记事本保存 UTF‑8 默认带 BOM；Linux/macOS 一般不用 BOM，带 BOM 会造成程序解析异常。
UTF‑16
Windows 内核、Java 内存字符串底层；2 字节 / 常用字符，生僻字符 4 字节。
分小端 LE、大端 BE；没有 BOM 就分不清字节序。
直接用文本编辑器打开 UTF‑16 文件，大量乱码，因为字节错位。
UTF‑32
固定 4 字节每个字符，极少用于存储文件，多用于程序内部处理。
2、编码不匹配典型现象
① 问号 ?
解码器无法找到对应字符，替换为问号。 例：GBK 文档，用 ASCII 打开，中文全部变成
????。
② 方框 □ / 豆腐块 �
当前字体没有这个字形，或者编码缺失字符。 注意：黑色菱形�是替换字符 (U+FFFD)：字节流无效，解码器无法解析字节，输出这个符号。
③ 莫吉博吉乱码（Mojibake），最常见
字节用错误编码翻译出一堆奇怪符号。 示例：
GBK 文本，当成 UTF‑8 打开：
��ѧϰ、ÂñºÃ这类奇怪符号。UTF‑8 文本当成 GBK 打开：大量
浣犲ソ这类中文乱码。
例子：“你好” UTF‑8 字节用 GBK 解析：就会出现
浣犲ソ经典乱码。
④ 部分文字正常，生僻字 /emoji 丢失
GBK 打开 GB18030 文档：普通汉字正常，古汉字、生僻字变成问号 / 方框。
GBK 完全不支持 emoji，emoji 直接乱码消失。
⑤ 换行异常、脚本解析报错
UTF‑8 BOM 坑：Linux shell、Python 源码如果带 UTF‑8 BOM，第一行报错；网页带 BOM 会破坏 HTTP 头。
⑥ 文件大小差异
同样中文文本：
GBK：每个中文 2 字节
UTF‑8：每个中文 3 字节 UTF‑8 中文会比 GBK 文件体积更大；英文 UTF‑8 体积和 ASCII 一样很小。
3、常见场景问题
Windows 记事本 保存选择 ANSI=GBK；UTF‑8 默认带 BOM；跨平台发给 Linux 容易出问题。
网页 HTML 没写
<meta charset="utf‑8">，浏览器猜测编码，中文乱码。数据库 数据库字段字符集设置错误，存入中文变成问号；MySQL 最常见
latin1编码坑。程序读写文件 Java/Python 读取文件不指定编码，使用系统默认编码，Windows 默认 GBK，Linux 默认 UTF‑8，同一套代码跨平台就乱码。
4、对比简表
5、最佳实践
互联网、源码、JSON、日志：一律UTF‑8（无 BOM）。
兼容老 Windows 国产软件：GB18030 优先，不要 GBK。
读写文件强制指定编码参数，不要依赖系统默认编码。
数据库、表、字段统一设置字符集 utf8mb4（MySQL），完整支持 emoji。
本文原创作者：易君召，详见：https://www.yijunzhao.cn/authors/yijunzhao，转载请注明出处。
原文链接
欢迎访问 小易撩挨踢