今天看文档无意间碰到了微软对编码格式解释，如下链接：
https://learn.microsoft.com/en-us/powershell/scripting/dev-cross-plat/vscode/understanding-file-encoding?view=powershell-5.1下图为节选，微软表达的意思很明确UTF-8确实已经成为Llinux乃至行业主流，但windows历史上默认的文件编码格式都是是 Windows-1252，可以等同理解为即 ANSI 编码，这一点已经不能改变，这就是为什么vs、命令行和windows记事本等默认都是本地化格式改变GB2312。
后来微软开始支持Unicode，虽然BOM是可选但微软认为应该选上这样编译器就可以凭借这个BOM确定你要用Unicode编码了，即微软认可的UTF-8是UTF-8 BOM（vs默认编译器也被设计为看源码文件有没有bom标识没有对不起不认识按默认ANSI处理了） ，它认为Linux没有选BOM是因为约定俗称了大家都不带bom而已(这仅仅是微软自认为)，依然推荐开发者首选BOM。
事实上，在 Linux 等类 Unix 系统中，默认不使用 BOM 的主要原因是 BOM 在 UTF-8 编码中并不是必须的，并且在某些情况下可能会导致一些问题。在 Unix 系统中，文本文件的编码通常由文本编辑器或其他工具根据文件头部的字符集声明来自动识别，而不是依赖于 BOM。
1、vs不同时期版本默认项目编码格式对比
下图为vs2019默认新建C++ 控制台项目，默认文件编码格式为UTF-8 BOM
下图为VS2010默认新建C++ 控制台项目，默认文件编码格式为GB2312
2、vs默认编码格式三个阶段历史
阶段一 vs2002到2017ANSI为主 混乱阶段
Visual Studio 2002开始到2003,2005,2008,2010,2012,2013,2015,2017共九个版本，默认的文件编码格式可以根据不同的国家/地区设置而有所不同。一般来说，对于英语和西方国家的用户，默认的文件编码格式都是是 Windows-1252，即 ANSI 编码。而对于一些非西方国家的用户，可能会根据当地的字符集设置而选择不同的默认编码格式，比如 GB2312（简体中文）、Shift-JIS（日文）、EUC-KR（韩文）等；
阶段二 vs2010首次尝试UTF-8 BOM 小试牛刀阶段
从 Visual Studio 2010 开始，微软逐渐开始将默认的文本文件编码格式逐步转向 Unicode，以支持更多语言和更好地支持国际化。MFC 库提供了更多的 Unicode 相关类和函数，使得开发者可以更方便地处理 Unicode 字符串和文本，也支持在源代码中使用 Unicode 字符串（如
wchar_t类型的字符串）等；最终，Visual Studio 2010 SP1中引入了新的编码设置选项，允许开发者在创建新项目时选择默认的文件编码格式。虽然默认文件编码格式仍然是 ANSI，但是开发者可以选择将其更改为 Unicode 格式（UTF-8 或 UTF-16）。
总结：支持了UTF-8 BOM但未敢默认
阶段三 vs2019转正UTF-8 BOM 一统天下阶段
Visual Studio 2019 在 Unicode 方面继续增强了对多语言、国际化和全球化的支持，正式将默认文件编码格式更改为 UTF-8 with BOM，这使得创建的新项目和文件都采用了 UTF-8 编码，以更好地支持多语言和 Unicode 字符。
总结：VS2019正式让UTF-8 BOM转正为默认文件编码格式
3、现状——陷入永无休止的循环 分庭对抗
可能原因：vs2019开始到vs2022微软继续坚持认可UTF-8 BOM的方式，原因最大可能是历史包袱，带 BOM 的 UTF-8 格式可以与一些旧版本的Windows系统和其他软件更好地兼容。
目前现状：现实世界是UTF-8已经是一种广泛支持的Unicode 编码格式，在跨平台开发中具有很好的兼容性，从前端都到后端，甚至到嵌入式都已经成为开发者约定俗成的习惯。
开发者继续不断尝试脱离带bom的UTF-8以提高兼容性和跨平台，比如借助vs插件或者手动将项目的文件设置为不使用 BOM 的编码格式；
从2011年到现在整整13年了，微软vs大版本发布了五六个了，但仍然继续固执己见的坚持只有带BOM的UTF-8才是真正的大一统，然而最新版的win11 23h2的默认组件记事本txt的默认编码格式却已经被微软默认成了不带bom的UTF-8.
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
