ASCII、GBK、Unicode、UTF‑8 / UTF‑16 / UTF‑32编码总结
摘要：编码乱码是开发、爬虫、后端、文件处理中最常见的问题。绝大多数人始终分不清Unicode、UTF-8、UTF-16、UTF-32、ASCII、GBK的关系。本文用通俗语言+对比表格+编码实例+适用场景，一次性讲透所有主流字符编码，帮你彻底搞定编码原理与乱码问题。
关键词：字符编码、ASCII、GBK、Unicode、UTF-8、UTF-16、UTF-32、乱码原理
前言
做开发一定会遇到这些问题：
Windows打开文件乱码，Linux正常
爬虫网页有的UTF-8、有的GBK，解析报错
Java、JS字符串特殊emoji、生僻汉字显示异常
分不清 Unicode 和 UTF-8 到底有啥区别
核心根源：字符编号（码点）≠ 存储字节编码。
本文从零梳理6种主流编码，区分「区域性编码」和「Unicode通用编码体系」，彻底终结编码盲区。
一、基础认知：两个核心概念（必看）
1.1 字符集 & 编码的区别
字符集：定义了有哪些文字、符号（比如英文、中文、符号）
编码：把字符转换成计算机可识别的二进制字节的规则
1.2 最大误区：Unicode 不是编码！
很多新手终身搞错：
✅Unicode 是全球唯一字符编号（码点），只给每个字符分配唯一ID，不规定怎么存成字节。
✅UTF-8/UTF-16/UTF-32 是 Unicode 的存储/传输编码实现，负责把Unicode编号转成二进制字节。
二、ASCII 编码（最基础的英文编码）
2.1 核心特性
字节长度：固定 1 字节（8bit）
有效范围：只用低7位，0~127
包含内容：数字、大小写英文字母、英文标点、控制字符（换行、回车等）
兼容性：所有现代编码均兼容ASCII
2.2 优缺点
✅ 优点：体积最小、解析简单、通用度极高
❌ 缺点：完全不支持中文、日文、韩文、特殊符号，仅适用于纯英文场景
2.3 编码示例
字符A→ ASCII 二进制：01000001（ASCII值：65）
三、GBK 编码（中文专属区域性编码）
3.1 核心定位
GBK 是中国国标编码，独立于Unicode体系，是Windows简体中文系统默认的ANSI编码，兼容GB2312。
3.2 编码规则
ASCII字符：1字节，与ASCII编码完全一致
中文、繁体、特殊符号：固定2字节
3.3 优缺点
✅ 优点：中文字符占用体积小（2字节），老旧Windows软件、本地文档、txt文件大量使用
❌ 缺点：
非国际标准，海外设备、服务器不兼容
与Unicode体系不互通，互相转换必须依赖映射表，极易乱码
不支持emoji、生僻古汉字
3.4 编码示例
字符中→ GBK 二进制：11010110 11010000（十六进制：0xD6D0）
四、Unicode 统一字符集（所有UTF编码的底层基石）
4.1 核心作用
解决全球各国编码不统一、互相不兼容的问题，给全世界所有文字分配唯一的数字编号（码点）。
4.2 编码格式
统一写法：U+四位/五位十六进制数
基础平面BMP：
U+0000 ~ U+FFFF（包含99%常用文字：中英文、日韩、常用符号）辅助平面：
U+10000 ~ U+10FFFF（emoji、生僻古汉字、特殊字体）
4.3 关键结论
Unicode只定义字符ID，不定义存储方式，本身不能直接用于文件存储、网络传输，必须配合UTF系列编码使用。
五、UTF-32（最简单、最浪费的Unicode编码）
5.1 编码规则
固定4字节存储任意Unicode码点，直接将字符的Unicode编号转为4字节二进制，无任何转换算法。
5.2 优缺点
✅ 优点：结构简单，字符对齐规整，支持随机访问字符，程序读取效率极高
❌ 缺点：空间极度浪费，纯英文文本体积是UTF-8的4倍，几乎不用于存储和网络传输
5.3 适用场景
仅用于部分程序内存字符处理、底层内核计算，互联网完全不用。
5.4 编码示例
字符中（U+4E2D）→ UTF-32BE 二进制：00000000 00000000 01001110 00101101（十六进制：00 00 4E 2D）
六、UTF-16（Windows/Java默认内存编码）
6.1 编码规则
变长编码，2字节 或 4字节
常用字符（U+0000~U+FFFF）：2字节存储
生僻字、emoji（超出BMP平面）：使用代理对，占用4字节
6.2 大小端模式
UTF-16BE：大端模式
UTF-16LE：小端模式（Windows、Java默认）
6.3 优缺点
✅ 优点：常用汉字、符号仅占2字节，内存存储效率高
❌ 缺点：
不兼容ASCII，纯英文文本体积翻倍
存在字节序问题，网络传输易出错
无法简单判断字符边界，容错性差
6.4 适用场景
Windows系统内核、Java字符串内存、.NET程序、桌面软件。
6.5 编码示例
字符中（U+4E2D）→ UTF-16LE 二进制：00101101 01001110（十六进制：2D 4E）
七、UTF-8（互联网通用标准编码）
7.1 编码规则
目前最主流、最通用的变长Unicode编码，占用1~4字节
U+0000~U+007F（ASCII字符）：1字节，完全兼容ASCII
U+0080~U+07FF：2字节
U+0800~U+FFFF（绝大多数汉字）：3字节
U+10000~U+10FFFF（emoji、生僻古汉字）：4字节
7.2 核心优势
完美兼容ASCII，老旧英文系统、设备无缝适配
无字节序问题，不需要BOM头，网络传输安全稳定
自同步特性，丢包、截断不会大面积乱码
全球通用，所有浏览器、服务器、编程语言默认支持
7.3 适用场景
网页、HTML、JSON、接口传输、Linux/macOS系统、日志文件、爬虫、代码文件。
开发铁律：所有新项目、网络传输、代码文件，一律使用UTF-8 无BOM编码。
7.4 编码示例
字符中（U+4E2D）→ UTF-8 二进制：11100100 10111000 10101101（十六进制：E4 B8 AD）
八、六大编码横向终极对比表
编码 | 字节长度 | 兼容ASCII | 归属体系 | 核心特点 | 典型场景 |
|---|---|---|---|---|---|
ASCII | 固定1字节 | — | 基础英文编码 | 仅支持英文，体积最小 | 基础协议、纯英文文本 |
GBK | 1/2字节 | ✅ 兼容 | 独立中文国标编码 | 中文体积小，国际不通用 | 老旧Windows本地文件、旧软件 |
Unicode | 无固定字节 | — | 全球字符编号标准 | 只定义ID，不存储字节 | 所有UTF编码的底层依据 |
UTF-8 | 1~4字节可变 | ✅ 完全兼容 | Unicode实现编码 | 全网通用、无字节序、容错高 | 互联网、代码、接口、服务器 |
UTF-16 | 2/4字节可变 | ❌ 不兼容 | Unicode实现编码 | 内存效率高，网络适配差 | Windows内核、Java内存字符串 |
UTF-32 | 固定4字节 | ❌ 不兼容 | Unicode实现编码 | 结构简单、极度浪费空间 | 底层程序内存计算 |
九、开发高频易错点 & 乱码终极原理
9.1 乱码产生的唯一原因
文件/数据保存编码 ≠ 读取解析编码
比如：文件用GBK保存，代码用UTF-8读取，必然乱码。
9.2 高频误区纠正
误区1：UTF-8就是Unicode ✅正解：Unicode是字符ID，UTF-8是存储规则，完全不是一个东西
误区2：GBK属于Unicode ✅正解：GBK是独立编码，和Unicode互不归属，转换必须查表
误区3：所有UTF-8都带BOM ✅正解：开发、服务器、网络传输必须用无BOM的UTF-8
误区4：Java char可以表示所有字符 ✅正解：Java char基于UTF-16，仅能表示基础平面字符，emoji、生僻字需要双char存储
9.3 开发编码最佳实践
所有代码文件、配置文件、日志统一使用UTF-8 无BOM
接口传输、JSON、HTTP请求强制UTF-8
处理老旧本地文件时，先判断编码（GBK/UTF-8）再解析
禁止新项目使用GBK、GB2312编码
9.3 Java中对字符编码解码的方法
public static void main(String[] args) throws UnsupportedEncodingException { String str="a编码b"; byte[] bytes = str.getBytes();//不加编码方式默认为平台编码方式 byte[] bytes1 = str.getBytes("GBK");//指定编码方式 String str1=new String(bytes);//默认按平台字符集解码 String str2=new String(bytes1,"GBK");//使用指定字符串解码方式 }十、总结
1.ASCII：英文基础编码，单字节，所有编码的基石，无中文能力。
2.GBK：国产中文编码，本地老旧场景专用，不通用、不推荐新项目使用。
3.Unicode：全球字符唯一编号体系，解决编码不统一问题，无存储能力。
4.UTF-8：互联网王者，兼容ASCII、无乱码、无字节序，全场景通用。
5.UTF-16：内存编码专用，Windows、Java底层使用，不适合网络传输。
6.UTF-32：结构最简单、空间浪费严重，仅底层程序使用。
掌握这套编码逻辑，基本可以解决开发中99%的乱码问题。