直接用 fopen 写 "\xEF\xBB\xBF" 有时不生效，因文本模式会触发换行转换或 BOM 误判；宽字符写入未设编码易覆盖 BOM；Windows 记事本依赖 BOM 识别 UTF-8。应使用二进制模式（"wb" 或 ios::binary），BOM 必为前三个字节，禁用宽字符串字面量，避免混用 C/C++ I/O。
为什么直接用 fopen 写 "\xEF\xBB\xBF" 有时不生效
因为 C++ 标准库（尤其是 std::ofstream）在以文本模式打开文件时，会触发底层 CRT 或系统对换行符的转换（如 `\n` → `\r\n`），还可能对 BOM 做误判或截断；更关键的是，如果文件后续写入的是宽字符（如 std::wstring）但流未正确设置编码，BOM 可能被覆盖或解析错位。Windows 上尤其常见：记事本依赖 BOM 判断 UTF-8，没它就当 ANSI，中文全乱码。
实操建议：
- 必须用二进制模式打开文件（
"wb"或std::ios::binary），彻底禁用文本模式的自动转换 - BOM 必须作为文件开头的**前三个字节**写入，不能中间插入、不能带空格、不能用宽字符串字面量（如
L"\uFEFF"）代替 - 避免混用 C 风格和 C++ 风格 I/O：比如先用
fwrite写 BOM，再用std::ofstream 追加内容——缓冲区和定位不一致会导致 BOM 被跳过或覆盖
用 std::ofstream 安全写入 UTF-8 BOM 的最小可靠代码
核心是：开二进制模式 + 手动写入三字节 + 后续所有内容都按 char 字节流处理（别用 .imbue() 或 std::codecvt_utf8，它们在 C++17 已弃用且行为不可靠）。
#include <fstream>
#include <string>
<p>int main() {
std::ofstream file("out.txt", std::ios::binary);
// 先写 BOM
file.write("\xEF\xBB\xBF", 3);
// 再写 UTF-8 内容（确保源字符串本身是 UTF-8 编码）
std::string utf8_content = "你好，世界！";
file.write(utf8_content.c_str(), utf8_content.size());
file.close();
return 0;
}</p>注意点：
立即学习“C++免费学习笔记（深入）”；
-
utf8_content必须是真正的 UTF-8 字节序列——如果你在 Windows MSVC 下用普通字符串字面量，需确认源文件保存为 UTF-8 with BOM，且编译器未做编码转换（Clang/GCC 默认按源码编码读取，MSVC 需加/utf-8编译选项） - 不要调用
file ，这会触发 locale 相关格式化，破坏二进制一致性 - 写完不要用
file.seekp(0, std::ios::beg)回退重写，容易留脏数据
用 fopen + fwrite 写 BOM 更直白但要注意平台差异
纯 C 方式反而更可控，尤其适合嵌入式或跨平台构建中规避 C++ 标准库实现差异。
FILE* fp = fopen("out.txt", "wb");
if (fp) {
unsigned char bom[] = {0xEF, 0xBB, 0xBF};
fwrite(bom, 1, 3, fp);
fwrite("Hello 世界", 1, 12, fp); // 确保第二参数是 1（字节单位）
fclose(fp);
}
易踩坑：
- Windows 下若用
"w"模式（非"wb"），BOM 可能被当成控制字符丢弃，或导致后续\n多写一个\r -
fwrite第二个参数必须是1，否则长度计算错误（例如fwrite(..., sizeof(char), 3, ...)可以，但sizeof(int)就崩了） - Linux/macOS 对文本/二进制模式区分弱，但显式写
"wb"是跨平台安全习惯
验证 BOM 是否真写进去了？别信编辑器显示
很多编辑器（包括 VS Code、Notepad++）默认隐藏 BOM，或根据内容猜测编码，显示“UTF-8”不代表有 BOM。真正验证得看头三字节。
推荐方法：
- 命令行：
xxd -l 8 out.txt（Linux/macOS）或certutil -hashfile out.txt SHA1 | findstr /v "hash"不行，改用 PowerShell：Get-Content out.txt -Encoding Byte -TotalCount 5 | ForEach-Object { $_.ToString("X2") } - 看到前三个输出是
EF BB BF才算成功；如果只有48 65 6C...（即 "Hel..." 的 ASCII 码），说明 BOM 没写进去或被覆盖 - 用十六进制编辑器（如 HxD、Bless）直接打开文件，定位 offset 0x0000，肉眼确认前三字节
BOM 是字节级契约，不是元信息——它只在文件开头存在才有意义，任何偏移、重复、截断都会让依赖它的工具（如 Windows 记事本、某些 JSON 解析器）失效。写的时候多看一眼十六进制视图，比事后调半天 locale 可靠得多。
