【字符编码】有无BOM的UTF-8

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

要理解带BOM的UTF-8 和普通UTF-8（无BOM）的区别与联系，首先需要明确BOM的本质：

BOM是Byte Order Mark（字节顺序标记）的缩写，本质是Unicode字符U+FEFF（零宽无中断空格）的编码形式，最初设计用于UTF-16/UTF-32编码：

UTF-16/UTF-32是多字节编码（2/4字节），存在**字节序（大端/小端）**问题（比如U+4E2D在UTF-16中大端是4E 2D，小端是2D 4E）。
BOM通过自身的编码字节（如UTF-16大端BOM是FE FF，小端是FF FE）标识字节序，解析器可据此正确解析字符。

而UTF-8是单字节为主的变长编码 ，本身不存在字节序问题 ，因此UTF-8的BOM并非必需，只是一个可选的编码标识 （UTF-8编码U+FEFF得到的字节是EF BB BF，这就是UTF-8 BOM的三个字节）。

核心编码规则完全一致

两者都遵循UTF-8的编码算法（用1_{4个字节表示Unicode字符，ASCII字符（0}127）编码与ASCII完全兼容），带BOM的UTF-8只是在字节流开头添加了EF BB BF，去掉这三个字节后，与普通UTF-8的字节流完全相同。
同属UTF-8编码体系

两者都能完整表示所有Unicode字符，是UTF-8编码的两种表现形式（标准形式与变体形式）。
ASCII兼容性一致

两者对ASCII字符（0~127）的编码完全相同，因此都能兼容传统的ASCII文本。

维度	普通UTF-8（无BOM）	带BOM的UTF-8（UTF-8-SIG）
字节前缀	无额外前缀，开头即为字符编码	开头有`EF BB BF`三个字节（BOM标识）
标准规范	Unicode标准推荐的标准UTF-8，国际通用	属于UTF-8的非标准变体（Unicode称其为UTF-8 with BOM/UTF-8-SIG）
BOM的作用	无BOM，无需处理字节序/标识	BOM仅作为编码标识（无字节序实际作用）
跨平台兼容性	极佳：Linux/macOS/Windows、编程语言、服务器（Nginx/Apache）、数据库均完美支持	兼容性差： 1. Windows工具（记事本/VS）支持良好； 2. 类Unix系统（Linux/macOS）的脚本/配置文件会因BOM出现语法错误或解析异常
字符解析	从第一个字节开始正常解析	解析器识别BOM则忽略`EF BB BF`；不识别则将其当作`U+FEFF`字符（不可见乱码）处理

Python脚本 ：带BOM的.py文件执行时，解释器会将BOM当作字符，导致开头出现SyntaxError（需用encoding='utf-8-sig'读取）。
Nginx配置：带BOM的配置文件会被解析为无效字符，导致服务启动失败。
Shell脚本 ：带BOM的.sh文件会因开头的EF BB BF出现command not found错误。

优先选择普通UTF-8（无BOM）

适用于跨平台场景、编程开发、服务器配置、数据库存储等绝大多数场景，避免兼容性问题。
仅Windows本地场景可用带BOM的UTF-8

如用记事本编辑的本地纯文本文件、仅在Windows软件中使用的文档，带BOM不影响使用（Windows工具默认识别BOM）。
特殊场景的兼容处理

若需处理带BOM的UTF-8文件，可使用支持UTF-8-SIG（SIG=Signature，签名）的解析方式：
- Python：open("file.txt", encoding="utf-8-sig")（自动去掉BOM）。
- Java：InputStreamReader(new FileInputStream("file.txt"), "UTF-8")（部分库需手动处理BOM）。

带BOM的UTF-8是普通UTF-8的变体，核心编码逻辑一致，但因开头的BOM字节导致兼容性差异。普通UTF-8是标准且通用的选择，带BOM的UTF-8仅适用于Windows本地有限场景。