摄影工作室网站建设,做阿里巴巴网站要多少钱,找人开发一个网站多少钱,注册安全工程师职业资格制度规定文章目录 概述文本编辑器如何识别文件的编码格式优先推测使用了UTF-8编码#xff1f;字符编码的BOM字节序标记重分析各文本编辑器下的测试效果Qt Creator的文本编辑器系统记事本VS的文本编辑器Notepad 编译器与代码文件的字符编码ANSI编码其他 概述
前期在整理 《IDE/VS项目属… 文章目录 概述文本编辑器如何识别文件的编码格式优先推测使用了UTF-8编码字符编码的BOM字节序标记重分析各文本编辑器下的测试效果Qt Creator的文本编辑器系统记事本VS的文本编辑器Notepad 编译器与代码文件的字符编码ANSI编码其他 概述
前期在整理 《IDE/VS项目属性中的 字符集 配置项》 和 《IDE /Qt Creator 文本编辑器之文件编码设置》和 《IDE /C4819: 该文件包含不能在当前代码页(936)中表示的字符》等文章的过程中做了不少关于字符编码的测试解决了一些问题但是也让我有了些新的问题和思考。简单但麻烦的测试让我有点烦躁总觉得有什么根本性的知识点我没有get到致使我在整理如上文章时很不舒服。于是我暂停了如上文章的整理试图先找出如它们共同关注的问题。初步分析后我把这些问题的总和称作 “字符编码与文本文件编辑器之间的协同运作机制”。具体的可能要关注
文本编辑器是如何识别文件的编码类型的靠谱吗 为什么删除文本文件中的全部中文字符后其又从 GB2312 “变回了” UTF-8 编码格式 BOM因何而生是如何运作的 QtCreator 和 VS 中的文本编辑器可以“篡改”源代码文件的编码格式这似乎不太合理 系统记事本以及Notepad等文本编辑器是查看或修改字符编码的基础工具你可能了解的并不够
文本编辑器如何识别文件的编码格式
如下是我在踩了很多坑之后才明白的把它提到前面来讲这样有些原本晦涩问题就好解释了。 如上图Notepad中选择使用最常见的UTF-8编码格式文中UTF-8均代表无BOM格式带BOM的我们将标称做UTF-8-BOM在文本文件中只输入一个数字1保存使用WinHex打开查看其二进制存储。只有一个0x31字节值没有其他的。你能通过0x31判断出这个文件使用了什么编码格式吗你不能大神也不能
目前并没有一种通用的、百分之百准确的编码识别技术。因为在没有明确的标识信息或者上下文的情况下仅仅根据字节序列等信息来确定文件的编码是具有一定难度的是不太可能的。不同的文本编辑工具可能使用不同的编码识别技术。一种常见的方法是根据文件的字节序列进行推测和猜测尝试识别文件的编码方式。这包括检查文件是否有 BOM字节顺序标记以及通过分析字符分布和编码规律来猜测文件的编码。然而由于某些编码的相似性或文件的特殊性这种猜测并不总是准确的。 因此在处理文件编码时最好的方式是结合其他信息进行判断比如文件的来源、文件的约定等。或者如果可行的话在文件中显式地包含编码信息如采用 BOM 或添加特定的编码声明。这样可以确保编码的准确性和可靠性。
以Notepad为例 Notepad会根据文件的开头几个字节来识别编码方式。它会检查文件是否包含字节顺序标记BOMByte Order Mark如果文件包含BOMNotepad会使用BOM中指定的编码方式。如果文件没有BOMNotepad会根据字节序列的分布模式和特征来尝试猜测编码方式。它会使用一系列的编码检测算法比较文件在不同编码方式下的字节序列与预定义的模式之间的相似性从而推断出最有可能的编码方式。这种编码识别并不是完全准确的特别是对于一些特殊或混合编码的文件可能会存在识别错误的情况。因此在处理文件时建议根据实际情况选择适当的编码方式并进行必要的确认和调整。
优先推测使用了UTF-8编码
前期的测试中记录了一些规律通常在IDE下被新建出来的代码文件中若不包含中文字符则它们始终被记事本或Notepad等文本编辑器软件加载识别为UTF-8无BOM编码格式我们使用记事本或Notepad新建的文件在其为空或者输入任何中文字符之前无论你保存和重新加载多少次它们也都始终显示为UTF-8无BOM格式。
这难道是因为UTF-8过硬的威望吗非要先创建为UTF-8然后伺机而动再改变其他编码格式
事实上UTF-8字符编码格式只是文本编辑器软件给当前这个文件贴上的一个标签。因为对于一个文本文件在其没有BOM、没有其他外部描述的情况下任何使用者都不知道它是何种编码的文件自己也不知道它是啥编码的因为它的造物主并没有告诉它它是谁。字符编码不是文本文件的属性也不是文本编辑器的属性而是介于两者之间的一种约定。当文本编辑器尝试加载文件时由于文件不能自述其到底使用了何种约定其只能使用一定的算法来进行推测优先推演出来的那个类型就被显示在了文件编辑器软件中。
是的只能去猜测 一个磁盘上的文本文件就那里存放着EncodeA能加载它显示为有意义的字符内容我们就可以说他是EncodeA编码类型。EncodeB能加载它显示为有意义的字符内容我们就可以说他是EncodeB编码类型。 对于只包含ASCII字符的文本文件主流的多种编码格式通常都可以正确的加载它且加载结果完全一致。即使是包含中文字符的文本文件我觉得如果经过非常刻意地设计甚至EncodeM和EncodeN都可以加载它为有意义的内容只不过此时不同的编码方式会将文件加载成不同的字符内容。写到这里我想起了 “菩提本无树明镜亦非台。本来无一物何处染尘埃”。从早些年一开始的时候就把字符编码这个事情看的过于神秘过于复杂啦。文件的编码格式格式就是一种约定这种约定告诉你该如何去正确的将它们显示为合理的字符。你甚至可以自己去定义这种约定比如 0x01代表中0x02代表国。
确实是UTF-8具有优先被尝试的机会 验证过程我们使用Notepad新建两个文件然后在 编码(N) 菜单中均选择使用ANSI编码如下图 然后在第一个文件中输入 “//abc”在第二个文件中输入 “中国汉字”分别将它们保存为 text1.txt 和 text2.txt 文本文件。使用记事本或Notepad重新打开加载它们可以发现text1.txt 编码格式 “变回了” UTF-8格式而 text2.txt 显示为 ANSI 格式。 在《IDE /Qt Creator 文本编辑器之文件编码设置》一文中我当时觉得上述 “变回UTF-8” 的现象是神奇的。到这里我们就明白其中的原因啦。原来这只是文本编辑器尝试认定它为UTF-8时没有发现什么异常便盖棺定论了。本质上 GB2312、UTF-8等主流字符编码都完全兼容ASCII字符集所以当一个文本文件中只用ASCII字符时任何主流编码都能无异常的加载它但是文本编辑器优先使用UTF-8来进行尝试故此UTF-8便优先上位。
字符编码的BOM字节序标记
BOM全称为字节顺序标记Byte Order Mark是一种特殊的字符序列用于标识文本文件中的字节顺序和编码方式。BOM最初是为了使用Unicode字符集的文件而设计的因为Unicode编码支持多种字节序如UTF-16的大端序和小端序因此需要一种机制来标识文件的字节顺序。然而随着时间的推移BOM的使用已经扩展到其他编码方案如UTF-8、UTF-32等。在这些编码方案中BOM的含义和用途可能有所不同。那些非Unicos的多字节编码体系如GB2312是没有字符编码BOM这么一说的。
UTF-8的BOM由三个字节表示分别是0xEF, 0xBB, 0xBF。UTF-16 编码的BOM由两个字节表示 0xFFFE 表示大端序、0xFEFF表示小端序。如下测试中使用Notepad分别构建 UTF-8-BOM.txt 和 UTF-16-BE.txt 文本文件使用的编码格式如文件名称所示其文本内容都只输入一个数字1使用WinHex打开 需要注意的是使用UTF-8或UTF-16编码文件都是可以不包含BOM的。对于UTF-8编码大多应用程序和系统都不使用BOM因此对于UTF-8编码来说BOM是可选但不推荐使用的。 对于UTF-16编码一般推荐使用BOM但是有些应用程序或操作系统可能不在UTF-16文件中包含BOM而是假设文件使用特定的大端或小端字节顺序中的一个。
重分析各文本编辑器下的测试效果
在着手写本文之前整理摘要中提到的那些文章额过程中我已对系统记事本、Notepad、VS文本编辑器、Qt Creator 文本编辑器做了不少的测试有了一丁点心得。再结合上几个章节新get到的新知识点将重新分析当时的一些测试现象以便让神奇不再神奇。
Qt Creator的文本编辑器
迫使我较为深入的来研究学习字符编码相关问题的正是Qt Creator集成开发环境下遇到的多个问题尤其是 Qt Creator MSVC编译器组成的集成开发环境的搭建和使用过程中遇到的那些。
无论你为QtCreator文本编辑器文件编码配置了GB2312编码还是UTF-8编码由工程创建过程或新建类等过程触发而创建的源代码文件都会被Notepad识别为UTF-8编码。但我们也注意到这些文本文件统统的是不包含任何的中文字符的。现在我们可以轻松理解它正是因为全都为ASCII字符Notepad优先使用UTF-8对其尝试加载因为异常便盖棺定论。 这里我们可以大胆的猜测若将QtCreator文本编辑器的文件编码配置成GB2312编码QtCreator本意上在创建过程就想要使用GB2312编码的奈何这里的创建过程无法包含进任何中文字符去因此无法验证。 不必纠结那没有意义我们只要明确在将IDE配置为GB2312编码的情况下只要有中文输入进去QtCreator文本编辑器便会以GB2312编码来存储代码文件中的任意中文字符若将IDE配置为UTF-8编码则只要有中文字符输入进去并保存QtCreator文本编辑器便会以UTF-8编码来存储代码文件中的任意中文字符。
其实更合理的理解更抽象的总结描述应该是这样的 在QtCreator文本编辑器配置的文件编码格式是被用作代码文本文件的默认加载方式的如果加载过程没有异常则后续的保存过程都将以此编码格式进行。QtCreator文本编辑器没有改变文件编码类型的功能但是会进行编码检查然后使用默认编码格式加载时遇到无法解析的编码值会告警进而提示你选择新的编码方式重新载入。如果没有告警提示便算是加载成功。
系统记事本
在 Windows 操作系统中记事本Notepad是一个基本的文本编辑器应用程序它通常随操作系统安装。在一些版本较高或较商用的系统中其记事本程序是可以在右下角展示文件的编码格式的 — 20230701 --Begin– 在《IDE/VS项目属性中的 字符集 配置项》整理过程中的某个测试阶段我得出了如下荒谬的结论任何编码格式的文件只要经过OS记事本编辑并输入了汉字字符文件的编码格式都变成ANSI编码。当时肯定是哪个步骤上自己耍了自己因为即使从理论上分析这也是不可能的。细想若OS记事本真有此功能那实在是太危险了只是从你走了一遭你却彻底改变了我。
我还是重新验证了下使用Notepad建立了如下4个不同编码的文件并分别输入以下内容后保存 使用OS记事本分别在上述4个文件中编辑添加中文字符串 “//我是大河”然后保存要注意的是文件中本来就含有中文。使用Notepad重新打开查看它们的编码格式可以发现它们的编码格式并没有变化。 再重新新建4个文件依然通过Notepad编码菜单分别选择使用上述上图所示的编码格式保存文件名称分别为 TesstA/B/C/D.cpp。这回只先输入英文字符保存后关闭。 同上使用记事本分别编辑添加中文字符串 “//我是大河”然后保存。使用Notepad重新打开查看它们的编码格式可见TestA/C/D保持了原有的文件编码格式。而TestB.cpp 从ANSI编码 变回“ UTF-8 编码。 — 20230701 --End–
— 20230712 --Begin– 嘿此刻相比于10天前我们有了新的知识支撑 结合BOM那一节的讲述UTF-8-BOM编码 和 UTF-16-BE 编码都是有BOM标识的因此text3和text4的即使在只有ASCII字符的情况下也不会再被识别为UTF-8无BOM类型。 当我们使用记事本打开TestB.cpp时该文件被是被为UTF-8这正符合我们在 “优先推测文件使用了UTF-8编码” 这一章节的描述。而由于记事本是以UTF-8来正确加载和显示了TestB.cpp文件因此后续的保存工作也将以此编码格式进行而不是以那个早就没有蛛丝马迹的曾经想作用于它的GB2310编码格式。系统记事本的这个行为与QtCreator文本编辑器的保存行为是完全一致的可以将它们表现出来的此规律相对统一的描述为文本编辑器以什么编码正确打开加载了文本文件便会以此编码保存后续用户编辑的所有内容。 — 20230712 --End–
VS的文本编辑器
在 《IDE/VS项目属性中的 字符集 配置项》的相关测试过程中有一个小插曲当时没理解
在VS项目中新建ClassX类生成的文件没有中文字符串加载显示为UTF-8编码现在这些都可以很好理解。但当时我在 ClassX.h 中输入 “//中国”保存后使用Notepad查看识别出来的编码格式是斯拉夫语且在Notepad编辑页面显示为乱码但在VS编辑器中显示是正常的。我继续在VS编辑器中将上述注释修改为“中国汉字”再保存重新打开查看其编码可见文件编码称为GB2312当时没有搞明白这是什么情况
现在基本可以理解为:中国这两个字的编码在斯拉夫语编码中也是存在的而Notepad先尝试了这种编码来解析文本文件。当汉字变多时Notepad的识别算法有了更多的参考依据从而将ClassX.h识别为本地编码的文件即识别为ANSI-GB2312编码格式。
另外在 《IDE/VS项目属性中的 字符集 配置项》文中我们已经验证了VS项目属性中字符集配置与其文本编辑器的行为是没有半毛关系的。该配置不会影响代码文件的默认加载方式也不会影响文件保存时的字符编码方式它也不是源字符集设置、也不是执行字符集设置而只是影响了UNICODE宏的定义进而决定接口上是使用宽字节字符串还是多字节字符。
默认情况下VS编译器不能正确加载 UTF-8无BOM的代码文件除非你设定了/source-charset :utf-8。进一步的探究将返回到《IDE/VS项目属性中的 字符集 配置项》博文中继续敬请参考。
Notepad
Notepad是一个开源项目其源代码托管在GitHub上可以在GitHub仓库中找到。前阵子网传其在原则性问题上有点作妖因此在码云上又出来个Notepad–的项目。都是开源的有机会可以去看看其在字符编码识别这一块的代码实现。Notepad 的字符编码识别原理的一般步骤
1、检查文件的 BOM (字节顺序标记)若存在则根据 BOM 的类型确定文件的编码。 2、使用统计信息进行猜测。如果文件没有 BOMNotepad 将根据文件内容的统计信息进行猜测将其与已知的字符编码进行匹配。根据匹配结果和一些启发式算法Notepad 可能会猜测文件使用的字符编码。 3、用户手动指定编码。如果 Notepad 无法准确识别文件的编码它将提示用户手动选择适当的编码。
需要注意的是字符编码的识别并非是一个绝对准确的过程尤其是对于没有明确标识编码的文件。因此有时候字符编码的自动识别可能会出现错误。在这种情况下用户可以手动选择正确的编码以确保文件内容正确显示。
编译器与代码文件的字符编码
在《IDE/VS项目属性中的 字符集 配置项》写了个简单的测试用例如下
#include iostreamusing namespace std;
int main()
{std::cout 我爱你中国\r\n;system(pause);return 0;
}在那篇文章中我们重点从”VS字符集配置是否会影响文本编辑器行为 “这个角度上做出了分析。这里我们将重点从 “VS编辑器是使用何种编码来解析代码文件” 这个角度上重新分析测试过程中的现象。
在 设置执行字符集 这篇文章中找到了确切的VS如何加载代码文件的过程 其实上述相关文件已经全部在 《IDE/VS项目属性中的 字符集 配置项它到底是干什么用的》文中讲明白啦。主要参考microsoft 设置源字符集、设置执行字符集、将源字符集和执行字符集设置为 UTF-8 等官方帮助文档。
以MSVC为例正式编译过程前编译器需要以一定的字符编码来读取源代码文件并将其中的字节序列解析为相应的字符序列。这样编译器才能正确理解和处理源代码中的字符、字符串和符号之后才能进行词法和语法分析等编译过程的其他步骤。编译器读取源代码的过程是独立于文本编辑器的。在这个过程中 Visual Studio会检测字节顺序标记BOM来确定源文件是否使用编码的Unicode格式如UTF-16或UTF-8。如果没有找到字节顺序标记源文件将被假定为使用当前用户代码页进行编码除非通过 /source-charset 选项指定了字符集名称或代码页。
“编译过程”中在上述提到的加载代码文件时会用到字符编码这通常称为源字符集设置。还有一个执行字符集设置必须对比着来理解在上述官网文章中也有较详实的说明总结如下 在将源代码编译位可执行文件时编译器会将源代码中的字符转换成可执行程序中的二进制数据。由于不同字符集采用不同的编码方式因此在编译时必须确定所使用的编码方式以便程序运行时可以正确读取和显示字符。细细品味源字符集和执行字符集它们在编译过程的使用目的是相反的。前者是将字符转换为二进制数据而后者讨论的是如何将二进制数据加载为字符。
ANSI编码
在其他的文章中我们讲述了大部分的编码格式。这里我们重点说一下ANSI这种编码格式。
ANSI编码不是一个具体的字符集而是表示一种字符编码的概念。具体使用哪种字符集来实现ANSI编码取决于操作系统和软件的实现。在不同的环境中ANSI编码可能指代不同的字符集。在 Windows 系统中“ANSI 编码” 这个术语通常用于指代特定的默认本地编码。这个默认的本地编码是根据操作系统和区域设置来确定的。对于区域设置为中国的 Windows 系统其默认的 ANSI 编码格式通常是 GBK或称 GB2312。
通常使用 0x00-0x7f 范围的1 个字节来表示 1 个英文字符。超出此范围的使用0x80-0xFFFF来编码即扩展的ASCII编码。为使计算机支持更多语言通常使用 0x80~0xFFFF 范围的 2 个字节来表示 1 个字符。比如汉字 ‘中’ 在中文操作系统中使用 [0xD6,0xD0] 这两个字节存储。不同的国家和地区制定了不同的标准由此产生了 GB2312、GBK、GB18030、Big5、Shift_JIS 等各自的编码标准。这些使用多个字节来代表一个字符的各种汉字延伸编码方式称为 ANSI 编码。在简体中文Windows操作系统中ANSI 编码代表 GB2312编码在繁体中文Windows操作系统中ANSI编码代表Big5在日文Windows操作系统中ANSI 编码代表 JIS 编码。
从ANSI编码这个定义维度上来看那么字符集可能要分为3个大类ASCII、ANSI、UNICODE。 其他
还有一些问题我没有十分确定的搞清楚如 输入法、剪切板等传递的应该是字符不是字符编码把否则你也怎么可能在不同编码的文件中来回复制文本。 控制台、IDE调试输出窗口、UI界面等都应该算是显示设备它们的运行过程中字符编码扮演了怎样的角色 还有qDebug() 中文字符串乱码问题等 这些问题的草稿也都存好多年了加油骚年
