Window/Linux 跨平台字符编码架构与工程实践深度研究报告

摘要

字符编码的异构性一直是跨平台软件工程中最为深层且棘手的技术挑战之一。随着全球化软件交付需求的激增，开发者需要在 Microsoft Windows 与 Linux（及类 Unix 系统）这两大截然不同的架构之间游走。这种差异并非单纯的技术选型分歧，而是根植于两大操作系统内核设计初期对 Unicode 标准不同演进阶段的历史性映射：Windows 在 Unicode 尚未成熟的早期选择了 UCS-2（后演进为 UTF-16）作为内核原生编码，而 Linux 则在后期通过 glibc 的 locale 机制拥抱了更为灵活且向后兼容 ASCII 的 UTF-8。

本报告旨在提供一份详尽的、专家级的编程指导，深入剖析 Windows 与 Linux 在字符编码架构上的底层差异，涵盖内核接口、系统调用、编译器行为（MSVC vs GCC/Clang）、主流编程语言（C++、Java、Python）的运行时演进，以及现代开发工具链（Git、Docker、PowerShell）中的编码陷阱。报告将特别关注近年来 Windows 10/11 在 UTF-8 支持上的架构性变革（如 Manifest 机制），并提供针对性的工程实践策略，以协助架构师与高级工程师构建稳健的 “UTF-8 Everywhere” 跨平台系统。

—

1. 历史渊源与架构分歧：计算环境的“巴别塔”

要理解当前 Windows 与 Linux 在字符处理上的巨大鸿沟，必须回溯到 20 世纪 90 年代初的决策时刻。这不仅是技术标准的竞争，更是对未来字符集扩展性预测的博弈。

1.1 Windows 的 Unicode 豪赌：UCS-2 与“宽字符”的遗产

在 Windows NT 内核设计的早期（约 1990-1993 年），Unicode 标准（1.0 版）刚刚问世。当时的 Unicode 联盟承诺，全世界的所有字符都可以被容纳在 16 位的空间内（即 65,536 个码位）。对于微软的架构师而言，这是一个极具诱惑力的技术承诺：固定宽度的字符集意味着字符串处理算法可以极其简化，无需处理变长编码的复杂性，且能一劳永逸地解决多语言支持问题。因此，Windows NT 决定将 wchar_t（宽字符）作为内核的一等公民，采用 UCS-2 编码。

然而，历史的发展并未如预期。随着 Unicode 的扩充，字符数量迅速突破了 16 位平面的限制（即 BMP，基本多文种平面）。为了支持辅助平面字符（如 Emoji、冷僻汉字、历史文字），Unicode 引入了代理对（Surrogate Pairs）机制，演进为 UTF-16。Windows 不得不跟随这一变化，从 UCS-2 迁移至 UTF-16LE（Little Endian）。这一转变导致了一个尴尬的架构遗留问题：wchar_t 依然保持 16 位大小，但实际上字符编码变成了变长的（1 个或 2 个 wchar_t 代表一个字符），彻底打破了最初“定长编码”的假设，却保留了定长编码 API 的复杂性。

为了保持对旧版 Windows（如 Windows 95/98，基于 ANSI 代码页）的向后兼容性，Windows 引入了双重 API 架构：

• W 后缀 API（如 CreateFileW）： 直接接受 UTF-16 字符串，直接与内核交互，性能最高。
• A 后缀 API（如 CreateFileA）： 接受基于当前系统代码页（Code Page）的单字节或多字节字符串（即所谓的 “ANSI” 字符串）。系统会在运行时分配内存，将其转换为 UTF-16，然后再调用 W 版本 API。

这种设计导致了 Windows 开发中长期存在的“ANSI vs Unicode”二元对立，开发者必须时刻警惕字符集转换带来的性能损耗和潜在的数据丢失风险（当字符不在当前 ANSI 代码页时）。

1.2 Linux 的字节流哲学与 UTF-8 的胜利

与 Windows 紧密的内核集成不同，Linux 及其前身 Unix 遵循“一切皆文件”和“字节流”的哲学。在 Linux 内核层面，文件名、路径和系统调用参数仅仅是一串非空（NUL, \0）字节序列，内核并不关心这些字节代表什么字符（除了路径分隔符 /）。这种设计赋予了用户空间极大的灵活性。

当 UTF-8 在 1993 年由 Ken Thompson 和 Rob Pike 发明并在随后的几年标准化后，它迅速成为了 Linux 世界的首选。UTF-8 的优势完美契合了 Unix 的哲学：

• ASCII 兼容性： 任何标准的 ASCII 文件也是合法的 UTF-8 文件，这意味着无数现有的系统工具（如 cat, grep, awk）无需修改即可处理 UTF-8 文本。
• 无字节序问题： 作为以字节为单位的编码，UTF-8 不存在大端（BE）或小端（LE）之争，避免了跨架构数据传输时的字节交换开销。
• 鲁棒性： UTF-8 的自同步特性使得即使数据流在传输中中断，也能很容易地找到下一个字符的起始位置。

Linux 系统并没有像 Windows 那样在内核强制推行一种编码，而是通过 glibc 和环境变量（Locale）在用户空间达成约定。这种松耦合的架构使得 Linux 能够在不破坏内核 ABI 的前提下，平滑地从 ISO-8859-1 等单字节编码过渡到 UTF-8。

—

2. 内核接口与系统级编程深度剖析

对于系统级程序员（C/C++、Rust、Go）而言，理解内核边界的字符串处理机制是编写无 Bug 跨平台代码的前提。

2.1 Windows 内核对象与字符串转换机制

在 Windows 平台上，几乎所有的内核对象（文件、互斥体、事件、注册表键）在底层都是通过 UTF-16 命名的。当一个传统的 C++ 程序调用 std::fstream::open(“config.ini”) 时，Microsoft 的 C 运行时库（CRT）会调用 CreateFileA。如果系统区域设置（System Locale）是英文（CP1252），文件名将被解释为 Windows-1252；如果是中文（CP936），则解释为 GBK。

这种机制的致命缺陷在于全域性和有损性。系统区域设置是一个全局配置，需要重启生效。如果一个运行在中文 Windows 上的程序试图读取一个文件名为希腊语（如 αβγ.txt）的文件，且该文件名不在 GBK 字符集中，CreateFileA 转换过程将失败或使用替代字符（如 ?），导致无法打开文件。

2.1.1 wchar_t 的跨平台陷阱

wchar_t 类型的设计初衷是提供一个足以容纳所有字符的“宽字符”类型。然而，C++ 标准并未规定其大小，导致了严重的平台分裂：

• Windows (MSVC): wchar_t 为 16 位（2 字节），对应 UTF-16 代码单元。这意味着处理辅助平面字符（如 Emoji 🌍）时，程序员必须处理代理对逻辑，字符串长度 wcslen 返回的是代码单元数而非字符数。
• Linux (GCC/Clang): wchar_t 通常为 32 位（4 字节），对应 UTF-32。这意味着每个 wchar_t 直接对应一个 Unicode 码点（Code Point）。

这种大小差异（2 字节 vs 4 字节）使得 std::wstring 在跨平台序列化或网络传输中完全不可用。开发者若试图将 Windows 内存中的 std::wstring 直接写入文件并在 Linux 上读取，将面临不仅是编码格式（UTF-16 vs UTF-32）更是字节序和数据宽度的多重灾难。

2.2 Linux 系统调用与 Glibc 的 Locale 仲裁

在 Linux 上，执行 open(“文件名.txt”, O_RDONLY) 时，传递给内核的仅仅是字符串的内存地址。内核通过文件系统驱动（如 ext4, xfs）将这些字节存储到磁盘。如果文件系统本身不强制编码（大多数现代 Linux 文件系统不强制），那么理论上可以在同一个目录下存在 UTF-8 编码的文件名和 GBK 编码的文件名。

这种混乱由用户空间的 glibc 库通过 Locale 机制来管理。Locale 定义了程序运行时的语言环境，由一组环境变量控制。其优先级逻辑如下：

1. LC_ALL：最高优先级，一旦设置，强制覆盖所有其他 LC_* 变量。常用于脚本中强制设定确定性行为（如 export LC_ALL=C）。
2. LC_CTYPE：决定字符分类（什么是字母、数字）和编码处理。这是编程中最关键的变量。如果 LC_CTYPE 设置为 C 或 POSIX，系统将回退到 7 位 ASCII 模式，任何多字节字符（UTF-8）都可能被视为乱码或导致程序崩溃。
3. LANG：默认值。当上述变量未设置时生效。

工程隐患： 在 Docker 容器或精简版 Linux 发行版中，常常因为缺少生成的 locale 数据包，导致程序（尤其是 Python 或 Perl 脚本）抛出 LocaleError 或默认回退到 ASCII，进而在处理 UTF-8 文件名时崩溃。必须确保在 Dockerfile 中显式生成并设置 locale（如 en_US.UTF-8）。

—

3. C/C++ 开发生态：从混乱走向标准化的阵痛

C/C++ 处于操作系统 API 的第一线，因此受编码差异的影响最为直接。

3.1 编译器行为差异：MSVC 的 /utf-8 革命

长期以来，MSVC 编译器默认假设源代码文件是按照当前系统的 ANSI 代码页编码的。如果开发者在中文 Windows 下编写代码 const char* s = “你好”; 并保存为 UTF-8（无 BOM），MSVC 可能会错误地按照 GBK 解析源文件，导致编译后的字符串字面量在运行时出现乱码。

为了解决这一问题，现代 MSVC（Visual Studio 2015 Update 2 及以后）引入了 /utf-8 编译选项。该选项具有双重作用：

1. /source-charset:utf-8：告诉编译器源文件是 UTF-8 编码。
2. /execution-charset:utf-8：告诉编译器在生成可执行文件时，将字符串字面量（char*）编码为 UTF-8 字节序列。

CMake 配置建议：
对于跨平台项目，强烈建议在 CMakeLists.txt 中检测 MSVC 并启用此选项，以确保 Windows 上的 std::string 字面量行为与 Linux（默认 UTF-8）一致：

if (MSVC)
    add_compile_options(/utf-8)
endif()

这一设置是实现 “UTF-8 Everywhere” 策略的基石。

3.2 C++17 std::filesystem 与路径处理

在 C++17 之前，跨平台处理文件路径是一场噩梦，开发者通常依赖 Boost.Filesystem。C++17 将其标准化为 std::filesystem，试图屏蔽底层差异。

• std::filesystem::path：这是一个智能容器。在 Windows 上，它内部通常维护一个 std::wstring（UTF-16）；在 Linux 上，它维护一个 std::string（UTF-8）。
• u8path 的兴衰：C++17 引入了 std::filesystem::u8path(u8_string) 工厂函数，专门用于将 UTF-8 编码的字符串转换为系统原生的路径格式（在 Windows 上自动转宽字符）。这曾是推荐的标准写法。
• C++20 的剧变：C++20 引入了原本缺失的 char8_t 类型，并将 u8path 标记为弃用（Deprecated）。现在，std::filesystem::path 的构造函数可以直接接受 u8string（即 std::basic_string<char8_t>）。然而，这引入了新的复杂性：std::string（通常是 UTF-8）与 std::u8string 是不同的类型，无法隐式转换，开发者被迫进行 reinterpret_cast 或数据拷贝，引发了社区的广泛争议。

最佳实践： 尽管 u8path 已弃用，但在过渡期（或为了兼容 C++17），它仍然是处理 UTF-8 路径最安全、最便携的方式。对于 C++20，建议构建统一的字符串视图适配层。

3.3 字符串类型的选择策略

综合各方研究，跨平台 C++ 开发的最佳策略是 “UTF-8 Everywhere”：

1. 内部存储： 应用程序内部逻辑全部使用 std::string 存储 UTF-8 数据。
2. 避免 wchar_t： 除非调用 Windows API，否则绝不使用 wchar_t 或 std::wstring。
3. 边界转换： 仅在调用 Windows API 的瞬间，使用轻量级转换函数（如 MultiByteToWideChar 或现代 C++ 的 std::wstring_convert，尽管后者也被弃用，需寻找替代品如 ICU 或 simdutf）将 UTF-8 转为 UTF-16。
4. Linux 直通： 在 Linux 上，std::string 直接传递给系统 API，零开销。

—

4. 托管语言与运行时环境的演进

Java 和 Python 等高级语言试图屏蔽 OS 差异，但这种抽象往往在处理文件 I/O 时发生泄漏。

4.1 Java：JEP 400 与 UTF-8 的全面标准化

在 JDK 18 之前，Java 的 Charset.defaultCharset() 行为取决于操作系统。在 Windows 上，它通常是 windows-1252 或 GBK；在 Linux 上通常是 UTF-8。这意味着代码 new FileReader(“file.txt”) 在开发机（Mac/Linux）上运行正常，但在 Windows 生产环境上可能因为读取中文乱码而崩溃。

JEP 400 的变革（JDK 18+）：
Java 18 引入了 JEP 400，规定标准 Java API 的默认字符集一律为 UTF-8，无论底层操作系统的配置如何。这是一个巨大的破坏性变更，但长远来看极大地提升了可移植性。

• 兼容性开关： 如果遗留系统必须依赖旧行为，需通过启动参数 -Dfile.encoding=COMPAT 回退。
• native.encoding： 引入了新的系统属性 native.encoding，允许开发者在极少数需要获知 OS 实际编码的场景下使用。

4.2 Python：从 mbcs 到 UTF-8 Mode

Python 3 对 Unicode 的严格区分（str vs bytes）虽然在初期造成了迁移痛苦，但为处理 Windows 编码问题奠定了基础。

• PEP 529（Windows 文件系统编码）： 自 Python 3.6 起，Python 在 Windows 上处理文件路径时，默认不再使用遗留的 mbcs（ANSI）编码，而是内部转换为 UTF-16 调用 Windows API，但对外表现为 UTF-8。这解决了“文件名包含当前代码页无法表示的字符”这一经典问题。
• PEP 540（UTF-8 Mode）： 引入了 -X utf8 命令行选项或 PYTHONUTF8=1 环境变量。开启后，Python 会忽略 POSIX locale 设置，强制将 stdin/stdout/stderr 和文件系统接口视为 UTF-8。这对容器化部署（locale 缺失时）尤为重要。
• 控制台输出： Python 在 Windows 控制台上也经历了漫长的进化，现代版本（3.8+）使用 io.TextIOWrapper 配合 Windows 的 Unicode API，基本解决了 print(“你好”) 在 cmd.exe 中的乱码问题，前提是字体支持。

—

5. Windows 的现代化革命：Manifest 机制与 UTF-8 代码页

随着 Windows 10 Version 1903（2019 年 5 月更新）的发布，Microsoft 终于提供了一种系统级的机制来打破 ANSI/Unicode 的二元对立，这被视为 Windows 字符编码架构的里程碑。

5.1 ActiveCodePage 清单（Manifest）

现在的 Windows 应用程序可以在其 Manifest 清单文件中声明 ActiveCodePage 属性为 UTF-8。

<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
  <application>
    <windowsSettings>
      <activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">UTF-8</activeCodePage>
    </windowsSettings>
  </application>
</assembly>

技术影响：
一旦声明，该进程调用的所有 “A” 后缀 API（如 CreateFileA, SetWindowTextA）不再将 char* 解释为 CP1252 或 GBK，而是直接解释为 UTF-8。这意味着开发者可以在 Windows 上像在 Linux 上一样，直接使用 std::string (UTF-8) 与内核交互，无需进行 MultiByteToWideChar 转换，也无需重写代码使用 wchar_t。这极大地降低了旧代码移植到 Windows 的成本。
局限性： 这仅影响当前进程。如果程序加载了第三方的 DLL，而该 DLL 内部假定 “A” API 必然是单字节编码（例如进行指针算术 s++ 来跳过字符），可能会导致崩溃或逻辑错误。

5.2 系统级 Beta 设置：双刃剑

Windows 提供了一个管理设置：“Beta: 使用 Unicode UTF-8 提供全球语言支持”。启用后，整个系统的 ACP（Active Code Page）变为 65001（UTF-8）。

风险警告： 尽管这看起来是终极解决方案，但该设置被标记为 Beta 是有原因的。它会破坏大量未针对 UTF-8 适配的传统软件。例如，某些旧版 CAD 软件、打印机驱动程序甚至部分游戏模组工具（如 Skyrim 的 Nemesis）会因为无法处理多字节的 ANSI 字符串而闪退或乱码。因此，严禁在通用的生产环境或最终用户机器上默认开启此选项，除非完全受控。推荐的方式始终是应用程序级别的 Manifest。

—

6. 工程工具链中的编码陷阱与配置

编码问题不仅仅存在于代码中，更潜伏在开发工具链的配置里。

6.1 Git 的跨平台换行符与文件名策略

Git 的设计源于 Linux，因此对大小写敏感的文件系统和 LF 换行符最友好。在 Windows 上，这会导致多种问题。

换行符（CRLF vs LF）：

• Windows 使用 \r\n，Linux 使用 \n。

• 最佳配置： 为了保证仓库的一致性，推荐在 Windows 上设置 core.autocrlf true（检出时转 CRLF，提交时转 LF），在 Mac/Linux 上设置 core.autocrlf input（检出时不转换，提交时转 LF）。

• 强制策略： 更稳健的做法是在仓库根目录添加 .gitattributes 文件：
  * text=auto eol=lf
  *.bat text eol=crlf

  这样可以强制大多数文本文件在所有平台上以 LF 形式存在（现代编辑器如 VS Code 在 Windows 上处理 LF 毫无问题），唯独保留批处理文件为 CRLF。

核心配置 core.precomposeunicode：
macOS 的文件系统（HFS+/APFS）采用 NFD（分解形式）存储 Unicode 文件名（例如 é 存储为 e + ´），而 Linux 和 Windows 通常使用 NFC（组合形式）。这会导致 Git 认为文件名发生了变化。设置 git config --global core.precomposeunicode true 可以让 Git 在 macOS 上自动处理这种正规化差异。

6.2 Docker 挂载与文件系统映射

当在 Windows 主机上通过 Docker Desktop 挂载卷（Volume）到 Linux 容器时，实际上发生了 NTFS 到 ext4 的映射。

• Mojibake 现象： 如果文件名包含非 ASCII 字符（如德语变音符号或中文），在容器内 ls 可能会看到乱码或问号 ???。这是因为 Docker 在通过 SMB 或 gRPC 协议传输文件名时，如果两端的 Locale 配置不匹配，会导致编码截断或错误解析。
• 解决方案： 尽量使用 Docker 的 Named Volumes 而非 Bind Mounts（主机路径挂载）来存储数据库或持久化数据。如果必须挂载主机代码，确保 Windows 主机和容器内的 LANG 环境变量均显式设置为 UTF-8 支持的值（如 C.UTF-8）。

6.3 PowerShell 的编码怪癖

PowerShell（尤其是 v5.1）在处理外部命令输出时，极其容易发生编码损坏。

• 管道腐败： 当执行 cmd.exe /c output_utf8.exe | Select-String “pattern” 时，PowerShell 可能会用默认的 ANSI 编码去解码 EXE 的输出，导致 UTF-8 字符变成乱码。

• BOM 问题： PowerShell 5.1 在重定向输出到文件（> file.txt）时，默认使用 UTF-16LE 并带有 BOM。这会导致 Linux 工具（如 grep, bash）无法读取该文件。

• 修复方案： 在脚本头部显式设置输出编码：

[Console]::OutputEncoding =::UTF8
$PSDefaultParameterValues['Out-File:Encoding'] = 'utf8'

对于控制台显示乱码，使用 chcp 65001 可以解决显示问题，但需注意这可能会让某些旧的命令行工具工作异常。

—

7. 数据交换与持久化：BOM 的诅咒与解法

在文本文件的持久化层面，BOM（字节顺序标记）是一个引发无数争议的技术细节。

7.1 Excel CSV 与 BOM 的博弈

在 UTF-8 规范中，BOM（0xEF 0xBB 0xBF）是可选且不推荐的（Neither required nor recommended），因为 UTF-8 没有字节序问题。然而，Microsoft Excel 是一个例外。

• 现象： 如果直接双击打开一个不带 BOM 的 UTF-8 CSV 文件，Excel 往往会默认使用系统 ANSI 代码页（如 CP1252）打开，导致中文或特殊符号乱码。

• 权衡：

  • 带 BOM (UTF-8-BOM)： Excel 能自动识别并正确显示，但在 Linux 环境下，脚本读取第一行时会包含不可见的 BOM 字符，导致表头解析失败（例如 ID 变成了 \ufeffID）。
  • 不带 BOM (UTF-8)： Linux/Web 友好，但 Excel 用户体验极差（需要使用“数据 -> 获取数据 -> 来自文本”并手动选择 UTF-8）。

• Visual Studio 与 EditorConfig： VS 和 VS Code 对此有不同的默认行为。通过 .editorconfig 可以规范化项目中的文件：

[*.{cs,json,xml}]
charset = utf-8

注意：VS 曾有一个 bug，即使设置 utf-8 也会添加 BOM，但现代版本已修复，明确区分了 utf-8 和 utf-8-bom。

7.2 数据库与 Web 栈

• MySQL: 永远不要使用 utf8（它是 MySQL 早期的一个别名，最多只支持 3 字节，无法存储 Emoji）。必须使用 utf8mb4。
• HTTP: 必须在 Content-Type 头中显式指定 charset=utf-8。现代浏览器虽然有探测机制，但显式声明是防止 XSS 攻击和乱码的最后一道防线。

—

8. 战略性建议与最佳实践总结

基于上述深度分析，针对跨平台开发团队，提出以下分层级的最佳实践：

8.1 架构级决策：UTF-8 Everywhere

在任何新的 C++ 项目中，应坚定不移地采用 UTF-8 Everywhere 宣言。

• 内部数据：全部使用 std::string (UTF-8)。
• Windows 适配：使用 /utf-8 编译选项；在 Manifest 中声明 ActiveCodePage 为 UTF-8；仅在不得不与未适配的旧 API 交互时进行转换。
• Linux 适配：无需额外操作，享受原生性能。

8.2 工程化配置清单

1. 编辑器规范：项目根目录必须包含 .editorconfig，强制 charset = utf-8（无 BOM）和 end_of_line = lf。
2. Git 规范：配置 .gitattributes 以统一换行符策略。
3. 容器化规范：Dockerfile 中必须包含 locale 生成步骤：

RUN apt-get update && apt-get install -y locales \
    && locale-gen en_US.UTF-8
ENV LANG en_US.UTF-8
ENV LANGUAGE en_US:en
ENV LC_ALL en_US.UTF-8

4. 脚本规范：所有 PowerShell 脚本应显式设置 OutputEncoding 为 UTF-8；所有 Bash 脚本避免使用非 ASCII 字符作为变量名。

8.3 遗留系统迁移策略

对于历史包袱沉重的 Windows C++ 代码库（大量使用 CString, TCHAR）：

• 阶段一：不修改代码，但在构建流中引入 /utf-8 标志，观察字面量乱码问题是否解决。
• 阶段二：逐步替换文件 I/O 模块，引入 std::filesystem 替代 Win32 API。
• 阶段三：启用 Manifest UTF-8 选项，逐步移除 A 到 W 的转换层，但需进行广泛的回归测试，特别是针对第三方 DLL 的兼容性。

通过理解历史的包袱与现代的工具链能力，开发者完全可以在 Windows 和 Linux 之间构建起一座稳固的桥梁，让代码在“巴别塔”倒塌后的世界中依然能自由交流。

—

9. 附录：核心技术数据参考表

表 1：操作系统原生字符串处理对比

特性	Windows (传统/标准)	Linux (标准)	Windows (现代/Manifest)
原生 API 编码	UTF-16LE	UTF-8 (用户空间约定)	UTF-8 (通过 “A” API)
wchar_t 大小	16-bit (2 字节)	32-bit (4 字节)	16-bit (2 字节)
std::filesystem 后端	std::wstring	std::string	std::string (需转换)
文件名限制	大小写不敏感 (通常)，UTF-16	大小写敏感，字节流	大小写不敏感，UTF-16
控制台默认编码	OEM (如 CP437, GBK)	UTF-8 (通过 LANG)	UTF-8 (若 chcp 65001)

表 2：常见乱码（Mojibake）特征分析表

表现形式	原因诊断	技术解释
é	UTF-8 被误读为 Latin-1/CP1252	字符 é 的 UTF-8 字节是 C3 A9，这两个字节在 Latin-1 中分别对应 à 和 ©。
``	Latin-1/GBK 被误读为 UTF-8	许多单字节或双字节编码（如 GBK）的高位字节在 UTF-8 规范中是非法的起始字节，显示为替换字符 。
\u00E9	JSON/Java 转义未解析	源代码或日志中直接输出了转义序列，而非字符本身。
	UTF-8 BOM 被误读为 Latin-1	文件头的 BOM (EF BB BF) 在不支持 BOM 的编辑器中显示为这三个字符。

引用的著作

1. The UTF-8 encoding was invented in 1992 and standardized by January 1993. UTF-… | Hacker News, 访问时间为 一月 1, 2026， https://news.ycombinator.com/item?id=29748679
2. wchar_t Is a Historical Accident - moria.us, 访问时间为 一月 1, 2026， https://www.moria.us/articles/wchar-is-a-historical-accident/
3. Character encoding - Wikipedia, 访问时间为 一月 1, 2026， https://en.wikipedia.org/wiki/Character_encoding
4. Working with Strings - Win32 apps | Microsoft Learn, 访问时间为 一月 1, 2026， https://learn.microsoft.com/en-us/windows/win32/learnwin32/working-with-strings
5. Use UTF-8 code pages in Windows apps - Microsoft Learn, 访问时间为 一月 1, 2026， https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
6. Explaining the ANSI Charset - Chilkat Software, 访问时间为 一月 1, 2026， https://www.chilkatsoft.com/ansi_charset_explained.asp
7. Windows code page - Wikipedia, 访问时间为 一月 1, 2026， https://en.wikipedia.org/wiki/Windows_code_page
8. Difference between ANSI and UTF-8 - Vovsoft, 访问时间为 一月 1, 2026， https://vovsoft.com/blog/difference-between-ansi-and-utf-8/
9. Is “UTF-8 with BOM” the old UTF? What is UTF-8 now? - Super User, 访问时间为 一月 1, 2026， https://superuser.com/questions/1553666/is-utf-8-with-bom-the-old-utf-what-is-utf-8-now
10. Understanding locale environment variables - IBM, 访问时间为 一月 1, 2026， https://www.ibm.com/docs/ssw_aix_71/globalization/understand_locale_environ_var.html
11. Glibc and the kernel user-space API - LWN.net, 访问时间为 一月 1, 2026， https://lwn.net/Articles/534682/
12. What are the differences between char, char16_t, char32_t, string and wchar_t? - Reddit, 访问时间为 一月 1, 2026， https://www.reddit.com/r/C_Programming/comments/184tnyw/what_are_the_differences_between_char_char16_t/
13. wchar_t for UTF-16 on Linux? - Stack Overflow, 访问时间为 一月 1, 2026， https://stackoverflow.com/questions/12865564/wchar-t-for-utf-16-on-linux
14. Locale Environment Variables in Linux - Baeldung, 访问时间为 一月 1, 2026， https://www.baeldung.com/linux/locale-environment-variables
15. PEP 538 – Coercing the legacy C locale to a UTF-8 based locale | peps.python.org, 访问时间为 一月 1, 2026， https://peps.python.org/pep-0538/
16. How do I fix my locale issue? - Ask Ubuntu, 访问时间为 一月 1, 2026， https://askubuntu.com/questions/162391/how-do-i-fix-my-locale-issue
17. Setting the LANG Environment Variables and Locales (UNIX) - Informatica Documentation, 访问时间为 一月 1, 2026， https://docs.informatica.com/master-data-management/multidomain-mdm/10-3-hotfix-3/configuration-guide/introduction/configuring-international-data-support/configuring-language-in-oracle-environments/setting-the-lang-environment-variables-and-locales–unix-.html
18. /utf-8 (Set source and execution character sets to UTF-8) | Microsoft Learn, 访问时间为 一月 1, 2026， https://learn.microsoft.com/en-us/cpp/build/reference/utf-8-set-source-and-executable-character-sets-to-utf-8?view=msvc-170
19. /execution-charset (Set execution character set) | Microsoft Learn, 访问时间为 一月 1, 2026， https://learn.microsoft.com/en-us/cpp/build/reference/execution-charset-set-execution-character-set?view=msvc-170
20. Visual Studio /utf-8 source files - Scientific Computing, 访问时间为 一月 1, 2026， https://www.scivision.dev/msvc-utf8-source-files/
21. std::filesystem::u8path - cppreference.com - C++ Reference, 访问时间为 一月 1, 2026， https://en.cppreference.com/w/cpp/filesystem/path/u8path.html
22. Understanding std::u8string: Does It Have to Be UTF-8? - YouTube, 访问时间为 一月 1, 2026， https://www.youtube.com/watch?v=j47LAvnMk4U
23. How does std::u8string vary from the more common std::string? - Stack Overflow, 访问时间为 一月 1, 2026， https://stackoverflow.com/questions/56420790/how-does-stdu8string-vary-from-the-more-common-stdstring
24. Mastering Unicode in C++: A Comprehensive Guide to UTF-8 and UTF-16 in Windows | by Akash Pandit | Medium, 访问时间为 一月 1, 2026， https://medium.com/@panditakash38/mastering-unicode-in-c-a-comprehensive-guide-to-utf-8-and-utf-16-in-windows-355687c35641
25. JEP 400: UTF-8 by Default - OpenJDK, 访问时间为 一月 1, 2026， https://openjdk.org/jeps/400
26. JDK 18 and the UTF-8 as default charset | by Andrea Binello | Medium, 访问时间为 一月 1, 2026， https://medium.com/@andbin/jdk-18-and-the-utf-8-as-default-charset-8451df737f90
27. JDK 18 Release Notes, Important Changes, and Information - Oracle, 访问时间为 一月 1, 2026， https://www.oracle.com/java/technologies/javase/18-relnote-issues.html
28. File encoding and UTF-8 as default charset - IBM, 访问时间为 一月 1, 2026， https://www.ibm.com/docs/en/semeru-runtime-ce-z/21.0.0?topic=guide-file-encoding-utf-8-as-default-charset
29. PEP 529 – Change Windows filesystem encoding to UTF-8 | peps.python.org, 访问时间为 一月 1, 2026， https://peps.python.org/pep-0529/
30. PEP 540 – Add a new UTF-8 Mode - Python Enhancement Proposals, 访问时间为 一月 1, 2026， https://peps.python.org/pep-0540/
31. PEP 540: Add a new UTF-8 mode (v2) - LWN.net, 访问时间为 一月 1, 2026， https://lwn.net/Articles/741365/
32. UTF-8 in manifest in non-Unicode build - Codejock Forums, 访问时间为 一月 1, 2026， https://forum.codejock.com/topic24483&OB=ASC&MobileView=off.html
33. Inventor 2020 crashes when creating a category in Content Center Editor - Autodesk, 访问时间为 一月 1, 2026， https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/Inventor-2020-crashes-when-creating-a-category-in-Content-Center-Editor.html
34. Help with accents and regional characters : r/nanDECK - Reddit, 访问时间为 一月 1, 2026， https://www.reddit.com/r/nanDECK/comments/1j4w42k/help_with_accents_and_regional_characters/
35. Errors caused by Windows 10 Unicode UTF-8 encoding - nShift Help Center, 访问时间为 一月 1, 2026， https://helpcenter.nshift.com/hc/en-us/articles/360016886479-Errors-caused-by-Windows-10-Unicode-UTF-8-encoding
36. Configuring Git to handle line endings - GitHub Docs, 访问时间为 一月 1, 2026， https://docs.github.com/articles/dealing-with-line-endings
37. Complete Guide to Git for Multi-Platform Development: From Mac to Windows Without Conflicts | by Antonio Demarcus | Medium, 访问时间为 一月 1, 2026， https://medium.com/@antoniodemarcus/complete-guide-to-git-for-multi-platform-development-from-mac-to-windows-without-conflicts-01ca50f9e13d
38. Special characters in filenames of shared volumes are replaced with ?? (e.g. German umlauts) · Issue #36616 - GitHub, 访问时间为 一月 1, 2026， https://github.com/moby/moby/issues/36616
39. Files in host volume that have special characters filenames, have the filename translated to ?'s in Linux container · Issue #986 · docker/for-win - GitHub, 访问时间为 一月 1, 2026， https://github.com/docker/for-win/issues/986
40. UTF8 Script in PowerShell outputs incorrect characters - Stack Overflow, 访问时间为 一月 1, 2026， https://stackoverflow.com/questions/14482253/utf8-script-in-powershell-outputs-incorrect-characters
41. Extremely prone to utf8-related errors when executing commands using Windows PowerShell - Atlassian Community, 访问时间为 一月 1, 2026， https://community.atlassian.com/forums/Rovo-questions/Extremely-prone-to-utf8-related-errors-when-executing-commands/qaq-p/3060395
42. PowerShell pipe default OutputEncoding should match [System.Console]::OutputEncoding to avoid encoding issues with native console tools like more #25698 - GitHub, 访问时间为 一月 1, 2026， https://github.com/PowerShell/PowerShell/issues/25698
43. What’s the difference between UTF-8 and UTF-8 with BOM? - Codemia, 访问时间为 一月 1, 2026， https://codemia.io/knowledge-hub/path/whats_the_difference_between_utf-8_and_utf-8_with_bom
44. Should UTF-8 CSV files contain a BOM (byte order mark)?, 访问时间为 一月 1, 2026， https://softwareengineering.stackexchange.com/questions/372692/should-utf-8-csv-files-contain-a-bom-byte-order-mark
45. Opening CSV with UTF-8 BOM via Excel - java - Stack Overflow, 访问时间为 一月 1, 2026， https://stackoverflow.com/questions/20275470/opening-csv-with-utf-8-bom-via-excel
46. Specifying charset=utf-8 in .editorconfig incorrectly adds a BOM - Developer Community, 访问时间为 一月 1, 2026， https://developercommunity.visualstudio.com/content/problem/36385/specifying-charsetutf-8-in-editorconfig-incorrectl.html
47. Why is utf-8-bom discouraged? · Issue #297 · editorconfig/editorconfig - GitHub, 访问时间为 一月 1, 2026， https://github.com/editorconfig/editorconfig/issues/297
48. How to Handle Unicode and Emoji Encoding in Production Systems - Strapi, 访问时间为 一月 1, 2026， https://strapi.io/blog/unicode-and-emoji-encoding