概述

前期在整理 《IDE/VS項(xiàng)目屬性中的 ＜字符集＞ 配置項(xiàng)》 和 《IDE /Qt Creator 文本編輯器之文件編碼設(shè)置》和 《IDE /C4819: 該文件包含不能在當(dāng)前代碼頁(yè)(936)中表示的字符》等文章的過(guò)程中，做了不少關(guān)于字符編碼的測(cè)試，解決了一些問(wèn)題，但是也讓我有了些新的問(wèn)題和思考。簡(jiǎn)單但麻煩的測(cè)試讓我有點(diǎn)煩躁，總覺得有什么根本性的知識(shí)點(diǎn)，我沒有g(shù)et到，致使我在整理如上文章時(shí)很不舒服。于是我暫停了如上文章的整理，試圖先找出如它們共同關(guān)注的問(wèn)題。初步分析后，我把這些問(wèn)題的總和稱作 “字符編碼與文本文件編輯器之間的協(xié)同運(yùn)作機(jī)制”。具體的可能要關(guān)注：

文本編輯器是如何識(shí)別文件的編碼類型的？靠譜嗎？
為什么刪除文本文件中的全部中文字符后，其又從 GB2312 “變回了” UTF-8 編碼格式？
BOM因何而生，是如何運(yùn)作的？
QtCreator 和 VS 中的文本編輯器，可以“篡改”源代碼文件的編碼格式，這似乎不太合理！
系統(tǒng)記事本以及Notepad++等文本編輯器是查看或修改字符編碼的基礎(chǔ)工具，你可能了解的并不夠！

文本編輯器如何識(shí)別文件的編碼格式

如下是我在踩了很多坑之后才明白的，把它提到前面來(lái)講，這樣有些原本晦澀問(wèn)題就好解釋了。

如上圖，Notepad++中選擇使用最常見的UTF-8編碼格式（文中UTF-8均代表無(wú)BOM格式，帶BOM的我們將標(biāo)稱做UTF-8-BOM），在文本文件中只輸入一個(gè)數(shù)字1，保存，使用WinHex打開查看其二進(jìn)制存儲(chǔ)。只有一個(gè)0x31字節(jié)值，沒有其他的。你能通過(guò)0x31判斷出這個(gè)文件使用了什么編碼格式嗎？你不能，大神也不能！

目前并沒有一種通用的、百分之百準(zhǔn)確的編碼識(shí)別技術(shù)。因?yàn)樵跊]有明確的標(biāo)識(shí)信息或者上下文的情況下，僅僅根據(jù)字節(jié)序列等信息來(lái)確定文件的編碼是具有一定難度的，是不太可能的。不同的文本編輯工具可能使用不同的編碼識(shí)別技術(shù)。一種常見的方法是根據(jù)文件的字節(jié)序列進(jìn)行推測(cè)和猜測(cè)，嘗試識(shí)別文件的編碼方式。這包括檢查文件是否有 BOM（字節(jié)順序標(biāo)記），以及通過(guò)分析字符分布和編碼規(guī)律來(lái)猜測(cè)文件的編碼。然而，由于某些編碼的相似性或文件的特殊性，這種猜測(cè)并不總是準(zhǔn)確的。
因此，在處理文件編碼時(shí)，最好的方式是結(jié)合其他信息進(jìn)行判斷，比如文件的來(lái)源、文件的約定等?；蛘呷绻尚械脑?，在文件中顯式地包含編碼信息，如采用 BOM 或添加特定的編碼聲明。這樣可以確保編碼的準(zhǔn)確性和可靠性。

以Notepad++為例，
Notepad++會(huì)根據(jù)文件的開頭幾個(gè)字節(jié)來(lái)識(shí)別編碼方式。它會(huì)檢查文件是否包含字節(jié)順序標(biāo)記（BOM，Byte Order Mark），如果文件包含BOM，Notepad++會(huì)使用BOM中指定的編碼方式。如果文件沒有BOM，Notepad++會(huì)根據(jù)字節(jié)序列的分布模式和特征來(lái)嘗試猜測(cè)編碼方式。它會(huì)使用一系列的編碼檢測(cè)算法，比較文件在不同編碼方式下的字節(jié)序列與預(yù)定義的模式之間的相似性，從而推斷出最有可能的編碼方式。這種編碼識(shí)別并不是完全準(zhǔn)確的，特別是對(duì)于一些特殊或混合編碼的文件，可能會(huì)存在識(shí)別錯(cuò)誤的情況。因此，在處理文件時(shí)，建議根據(jù)實(shí)際情況選擇適當(dāng)?shù)木幋a方式，并進(jìn)行必要的確認(rèn)和調(diào)整。

優(yōu)先推測(cè)使用了UTF-8編碼？

前期的測(cè)試中，記錄了一些規(guī)律：通常在IDE下被新建出來(lái)的代碼文件中若不包含中文字符，則它們始終被記事本或Notepad等文本編輯器軟件加載識(shí)別為UTF-8無(wú)BOM編碼格式；我們使用記事本或Notepad新建的文件，在其為空或者輸入任何中文字符之前，無(wú)論你保存和重新加載多少次，它們也都始終顯示為UTF-8無(wú)BOM格式。

這難道是因?yàn)閁TF-8過(guò)硬的威望嗎？非要先創(chuàng)建為UTF-8，然后伺機(jī)而動(dòng)，再改變其他編碼格式？

事實(shí)上，UTF-8字符編碼格式只是文本編輯器軟件給當(dāng)前這個(gè)文件貼上的一個(gè)標(biāo)簽。因?yàn)?，?duì)于一個(gè)文本文件，在其沒有BOM、沒有其他外部描述的情況下，任何使用者都不知道它是何種編碼的；文件自己也不知道它是啥編碼的，因?yàn)樗脑煳镏鞑]有告訴它它是誰(shuí)。字符編碼不是文本文件的屬性，也不是文本編輯器的屬性，而是介于兩者之間的一種約定。當(dāng)文本編輯器嘗試加載文件時(shí)，由于文件不能自述其到底使用了何種約定，其只能使用一定的算法來(lái)進(jìn)行推測(cè)，優(yōu)先推演出來(lái)的那個(gè)類型，就被顯示在了文件編輯器軟件中。

是的，只能去猜測(cè)，
一個(gè)磁盤上的文本文件就那里存放著，EncodeA能加載它顯示為有意義的字符內(nèi)容，我們就可以說(shuō)他是EncodeA編碼類型。EncodeB能加載它顯示為有意義的字符內(nèi)容，我們就可以說(shuō)他是EncodeB編碼類型。
對(duì)于只包含ASCII字符的文本文件，主流的多種編碼格式通常都可以正確的加載它，且加載結(jié)果完全一致。即使是包含中文字符的文本文件，我覺得如果經(jīng)過(guò)非?？桃獾卦O(shè)計(jì)，甚至EncodeM和EncodeN都可以加載它為有意義的內(nèi)容，只不過(guò)此時(shí)不同的編碼方式會(huì)將文件加載成不同的字符內(nèi)容。寫到這里，我想起了 “菩提本無(wú)樹，明鏡亦非臺(tái)。本來(lái)無(wú)一物，何處染塵埃”。從早些年一開始的時(shí)候，就把字符編碼這個(gè)事情看的過(guò)于神秘過(guò)于復(fù)雜啦。文件的編碼格式格式就是一種約定，這種約定告訴你，該如何去正確的將它們顯示為合理的字符。你甚至可以自己去定義這種約定，比如 0x01代表"中"，0x02代表"國(guó)"。

確實(shí)是UTF-8具有優(yōu)先被嘗試的機(jī)會(huì)，
驗(yàn)證過(guò)程，我們使用Notepad++新建兩個(gè)文件，然后在 編碼(N) 菜單中均選擇使用ANSI編碼，如下圖，

然后在第一個(gè)文件中輸入 “//abc”，在第二個(gè)文件中輸入 “中國(guó)漢字”，分別將它們保存為 text1.txt 和 text2.txt 文本文件。使用記事本或Notepad++重新打開加載它們，可以發(fā)現(xiàn)，text1.txt 編碼格式 “變回了” UTF-8格式，而 text2.txt 顯示為 ANSI 格式。
在《IDE /Qt Creator 文本編輯器之文件編碼設(shè)置》一文中，我當(dāng)時(shí)覺得上述 “變回UTF-8” 的現(xiàn)象是神奇的。到這里我們就明白其中的原因啦。原來(lái)，這只是文本編輯器嘗試認(rèn)定它為UTF-8時(shí)，沒有發(fā)現(xiàn)什么異常，便蓋棺定論了。本質(zhì)上 GB2312、UTF-8等主流字符編碼，都完全兼容ASCII字符集，所以當(dāng)一個(gè)文本文件中只用ASCII字符時(shí)，任何主流編碼都能無(wú)異常的加載它，但是文本編輯器優(yōu)先使用UTF-8來(lái)進(jìn)行嘗試，故此UTF-8便優(yōu)先上位。

字符編碼的BOM字節(jié)序標(biāo)記

BOM，全稱為字節(jié)順序標(biāo)記（Byte Order Mark），是一種特殊的字符序列，用于標(biāo)識(shí)文本文件中的字節(jié)順序和編碼方式。BOM最初是為了使用Unicode字符集的文件而設(shè)計(jì)的，因?yàn)閁nicode編碼支持多種字節(jié)序，如UTF-16的大端序和小端序，因此需要一種機(jī)制來(lái)標(biāo)識(shí)文件的字節(jié)順序。然而隨著時(shí)間的推移，BOM的使用已經(jīng)擴(kuò)展到其他編碼方案，如UTF-8、UTF-32等。在這些編碼方案中，BOM的含義和用途可能有所不同。那些非Unicos的多字節(jié)編碼體系，如GB2312，是沒有字符編碼BOM這么一說(shuō)的。

UTF-8的BOM由三個(gè)字節(jié)表示，分別是0xEF, 0xBB, 0xBF。UTF-16 編碼的BOM由兩個(gè)字節(jié)表示， 0xFFFE 表示大端序、0xFEFF表示小端序。如下測(cè)試中，使用Notepad++，分別構(gòu)建 UTF-8-BOM.txt 和 UTF-16-BE.txt 文本文件，使用的編碼格式如文件名稱所示，其文本內(nèi)容都只輸入一個(gè)數(shù)字1，使用WinHex打開，

需要注意的是，使用UTF-8或UTF-16編碼文件都是可以不包含BOM的。對(duì)于UTF-8編碼，大多應(yīng)用程序和系統(tǒng)都不使用BOM，因此對(duì)于UTF-8編碼來(lái)說(shuō)，BOM是可選但不推薦使用的。 對(duì)于UTF-16編碼，一般推薦使用BOM，但是有些應(yīng)用程序或操作系統(tǒng)可能不在UTF-16文件中包含BOM，而是假設(shè)文件使用特定的大端或小端字節(jié)順序中的一個(gè)。

重分析各文本編輯器下的測(cè)試效果

在著手寫本文之前，整理摘要中提到的那些文章額過(guò)程中，我已對(duì)系統(tǒng)記事本、Notepad++、VS文本編輯器、Qt Creator 文本編輯器，做了不少的測(cè)試，有了一丁點(diǎn)心得。再結(jié)合上幾個(gè)章節(jié)新get到的新知識(shí)點(diǎn)，將重新分析當(dāng)時(shí)的一些測(cè)試現(xiàn)象，以便讓神奇不再神奇。

Qt Creator的文本編輯器

迫使我較為深入的來(lái)研究學(xué)習(xí)字符編碼相關(guān)問(wèn)題的，正是Qt Creator集成開發(fā)環(huán)境下遇到的多個(gè)問(wèn)題，尤其是 Qt Creator + MSVC編譯器組成的集成開發(fā)環(huán)境的搭建和使用過(guò)程中遇到的那些。

無(wú)論你為QtCreator文本編輯器文件編碼配置了GB2312編碼還是UTF-8編碼，由工程創(chuàng)建過(guò)程或新建類等過(guò)程觸發(fā)而創(chuàng)建的源代碼文件，都會(huì)被Notepad++識(shí)別為UTF-8編碼。但我們也注意到，這些文本文件統(tǒng)統(tǒng)的是不包含任何的中文字符的?，F(xiàn)在我們可以輕松理解它，正是因?yàn)槿紴锳SCII字符，Notepad++優(yōu)先使用UTF-8對(duì)其嘗試加載，因?yàn)楫惓?，便蓋棺定論。
這里我們可以大膽的猜測(cè)，若將QtCreator文本編輯器的文件編碼配置成GB2312編碼，QtCreator本意上在創(chuàng)建過(guò)程就想要使用GB2312編碼的，奈何，這里的創(chuàng)建過(guò)程無(wú)法包含進(jìn)任何中文字符去，因此無(wú)法驗(yàn)證。
不必糾結(jié)，那沒有意義，我們只要明確：在將IDE配置為GB2312編碼的情況下，只要有中文輸入進(jìn)去，QtCreator文本編輯器便會(huì)以GB2312編碼來(lái)存儲(chǔ)代碼文件中的任意中文字符；若將IDE配置為UTF-8編碼，則只要有中文字符輸入進(jìn)去并保存，QtCreator文本編輯器便會(huì)以UTF-8編碼來(lái)存儲(chǔ)代碼文件中的任意中文字符。

其實(shí)更合理的理解，更抽象的總結(jié)描述，應(yīng)該是這樣的：
在QtCreator文本編輯器配置的文件編碼格式是被用作代碼文本文件的默認(rèn)加載方式的，如果加載過(guò)程沒有異常，則后續(xù)的保存過(guò)程，都將以此編碼格式進(jìn)行。QtCreator文本編輯器沒有改變文件編碼類型的功能，但是會(huì)進(jìn)行編碼檢查，然后使用默認(rèn)編碼格式加載時(shí)遇到無(wú)法解析的編碼值，會(huì)告警，進(jìn)而提示你選擇新的編碼方式重新載入。如果沒有告警提示，便算是加載成功。

系統(tǒng)記事本

在 Windows 操作系統(tǒng)中，記事本（Notepad）是一個(gè)基本的文本編輯器應(yīng)用程序，它通常隨操作系統(tǒng)安裝。在一些版本較高或較商用的系統(tǒng)中，其記事本程序是可以在右下角展示文件的編碼格式的，

— 20230701 --Begin–
在《IDE/VS項(xiàng)目屬性中的 ＜字符集＞ 配置項(xiàng)》整理過(guò)程中的某個(gè)測(cè)試階段，我得出了如下荒謬的結(jié)論：任何編碼格式的文件，只要經(jīng)過(guò)OS記事本編輯，并輸入了漢字字符，文件的編碼格式都變成ANSI編碼。當(dāng)時(shí)肯定是哪個(gè)步驟上自己耍了自己，因?yàn)榧词箯睦碚撋戏治觯@也是不可能的。細(xì)想若OS記事本真有此功能，那實(shí)在是太危險(xiǎn)了，只是從你走了一遭，你卻徹底改變了我。

我還是重新驗(yàn)證了下，使用Notepad++建立了如下4個(gè)不同編碼的文件，并分別輸入以下內(nèi)容后保存，

使用OS記事本，分別在上述4個(gè)文件中編輯添加中文字符串 “//我是大河”，然后保存，要注意的是文件中本來(lái)就含有中文。使用Notepad++重新打開查看它們的編碼格式，可以發(fā)現(xiàn)，它們的編碼格式并沒有變化。
再重新新建4個(gè)文件，依然通過(guò)Notepad編碼菜單分別選擇使用上述上圖所示的編碼格式，保存文件名稱分別為 TesstA/B/C/D.cpp。這回只先輸入英文字符，保存后關(guān)閉。

同上，使用記事本分別編輯添加中文字符串 “//我是大河”，然后保存。使用Notepad++重新打開查看它們的編碼格式，可見，TestA/C/D，保持了原有的文件編碼格式。而TestB.cpp 從ANSI編碼 "變回“ UTF-8 編碼。
— 20230701 --End–

— 20230712 --Begin–
嘿，此刻相比于10天前，我們有了新的知識(shí)支撐，
結(jié)合BOM那一節(jié)的講述，UTF-8-BOM編碼 和 UTF-16-BE 編碼，都是有BOM標(biāo)識(shí)的，因此text3和text4的即使在只有ASCII字符的情況下，也不會(huì)再被識(shí)別為UTF-8無(wú)BOM類型。
當(dāng)我們使用記事本打開TestB.cpp時(shí)，該文件被是被為UTF-8，這正符合我們?cè)?“優(yōu)先推測(cè)文件使用了UTF-8編碼” 這一章節(jié)的描述。而由于記事本是以UTF-8來(lái)正確加載和顯示了TestB.cpp文件，因此后續(xù)的保存工作，也將以此編碼格式進(jìn)行，而不是以那個(gè)早就沒有蛛絲馬跡的曾經(jīng)想作用于它的GB2310編碼格式。系統(tǒng)記事本的這個(gè)行為與QtCreator文本編輯器的保存行為是完全一致的，可以將它們表現(xiàn)出來(lái)的此規(guī)律，相對(duì)統(tǒng)一的描述為：文本編輯器以什么編碼正確打開加載了文本文件，便會(huì)以此編碼保存后續(xù)用戶編輯的所有內(nèi)容。
— 20230712 --End–

VS的文本編輯器

在 《IDE/VS項(xiàng)目屬性中的 ＜字符集＞ 配置項(xiàng)》的相關(guān)測(cè)試過(guò)程中，有一個(gè)小插曲，當(dāng)時(shí)沒理解，

在VS項(xiàng)目中新建ClassX類（生成的文件沒有中文字符串），加載顯示為UTF-8編碼，現(xiàn)在這些都可以很好理解。但當(dāng)時(shí)，我在 ClassX.h 中輸入 “//中國(guó)”，保存后，使用Notepad++查看識(shí)別出來(lái)的編碼格式是"斯拉夫語(yǔ)"，且在Notepad++編輯頁(yè)面顯示為亂碼，但在VS編輯器中顯示是正常的。我繼續(xù)在VS編輯器中將上述注釋修改為“中國(guó)漢字”，再保存，重新打開查看其編碼，可見文件編碼稱為GB2312，當(dāng)時(shí)沒有搞明白這是什么情況？

現(xiàn)在基本可以理解為:"中國(guó)"這兩個(gè)字的編碼在斯拉夫語(yǔ)編碼中也是存在的，而Notepad++先嘗試了這種編碼來(lái)解析文本文件。當(dāng)漢字變多時(shí)，Notepad的識(shí)別算法有了更多的參考依據(jù)，從而將ClassX.h識(shí)別為本地編碼的文件，即識(shí)別為ANSI-GB2312編碼格式。

另外在 《IDE/VS項(xiàng)目屬性中的 ＜字符集＞ 配置項(xiàng)》文中，我們已經(jīng)驗(yàn)證了，VS項(xiàng)目屬性中字符集配置，與其文本編輯器的行為是沒有半毛關(guān)系的。該配置不會(huì)影響代碼文件的默認(rèn)加載方式，也不會(huì)影響文件保存時(shí)的字符編碼方式，它也不是源字符集設(shè)置、也不是執(zhí)行字符集設(shè)置，而只是影響了UNICODE宏的定義，進(jìn)而決定接口上是使用寬字節(jié)字符串還是多字節(jié)字符。

默認(rèn)情況下，VS編譯器不能正確加載 UTF-8無(wú)BOM的代碼文件，除非你設(shè)定了/source-charset :utf-8。進(jìn)一步的探究，將返回到《IDE/VS項(xiàng)目屬性中的 ＜字符集＞ 配置項(xiàng)》博文中繼續(xù)，敬請(qǐng)參考。

Notepad++

Notepad++是一個(gè)開源項(xiàng)目，其源代碼托管在GitHub上，可以在GitHub倉(cāng)庫(kù)中找到。前陣子網(wǎng)傳其在原則性問(wèn)題上有點(diǎn)作妖，因此在碼云上又出來(lái)個(gè)Notepad–的項(xiàng)目。都是開源的，有機(jī)會(huì)可以去看看其在字符編碼識(shí)別這一塊的代碼實(shí)現(xiàn)。Notepad++ 的字符編碼識(shí)別原理的一般步驟：

1、檢查文件的 BOM (字節(jié)順序標(biāo)記)，若存在則根據(jù) BOM 的類型確定文件的編碼。
2、使用統(tǒng)計(jì)信息進(jìn)行猜測(cè)。如果文件沒有 BOM，Notepad++ 將根據(jù)文件內(nèi)容的統(tǒng)計(jì)信息進(jìn)行猜測(cè)，將其與已知的字符編碼進(jìn)行匹配。根據(jù)匹配結(jié)果和一些啟發(fā)式算法，Notepad++ 可能會(huì)猜測(cè)文件使用的字符編碼。
3、用戶手動(dòng)指定編碼。如果 Notepad++ 無(wú)法準(zhǔn)確識(shí)別文件的編碼，它將提示用戶手動(dòng)選擇適當(dāng)?shù)木幋a。

需要注意的是，字符編碼的識(shí)別并非是一個(gè)絕對(duì)準(zhǔn)確的過(guò)程，尤其是對(duì)于沒有明確標(biāo)識(shí)編碼的文件。因此，有時(shí)候字符編碼的自動(dòng)識(shí)別可能會(huì)出現(xiàn)錯(cuò)誤。在這種情況下，用戶可以手動(dòng)選擇正確的編碼以確保文件內(nèi)容正確顯示。

編譯器與代碼文件的字符編碼

在《IDE/VS項(xiàng)目屬性中的 ＜字符集＞ 配置項(xiàng)》寫了個(gè)簡(jiǎn)單的測(cè)試用例，如下，

#include <iostream>

using namespace std;
int main()
{
    std::cout << "我愛你中國(guó)！\r\n";
    system("pause");
    return 0;
}

在那篇文章中，我們重點(diǎn)從”VS字符集配置是否會(huì)影響文本編輯器行為 “這個(gè)角度上做出了分析。這里，我們將重點(diǎn)從 “VS編輯器是使用何種編碼來(lái)解析代碼文件” 這個(gè)角度上，重新分析測(cè)試過(guò)程中的現(xiàn)象。

在 設(shè)置執(zhí)行字符集 這篇文章中找到了確切的VS如何加載代碼文件的過(guò)程：

其實(shí)上述相關(guān)文件已經(jīng)全部在 《IDE/VS項(xiàng)目屬性中的 ＜字符集＞ 配置項(xiàng)，它到底是干什么用的？》文中講明白啦。主要參考microsoft 設(shè)置源字符集、設(shè)置執(zhí)行字符集、將源字符集和執(zhí)行字符集設(shè)置為 UTF-8 等官方幫助文檔。

以MSVC為例，正式編譯過(guò)程前，編譯器需要以一定的字符編碼來(lái)讀取源代碼文件，并將其中的字節(jié)序列解析為相應(yīng)的字符序列。這樣編譯器才能正確理解和處理源代碼中的字符、字符串和符號(hào)，之后才能進(jìn)行詞法和語(yǔ)法分析等編譯過(guò)程的其他步驟。編譯器讀取源代碼的過(guò)程是獨(dú)立于文本編輯器的。在這個(gè)過(guò)程中，
Visual Studio會(huì)檢測(cè)字節(jié)順序標(biāo)記BOM，來(lái)確定源文件是否使用編碼的Unicode格式，如UTF-16或UTF-8。如果沒有找到字節(jié)順序標(biāo)記，源文件將被假定為使用當(dāng)前用戶代碼頁(yè)進(jìn)行編碼，除非通過(guò) /source-charset 選項(xiàng)指定了字符集名稱或代碼頁(yè)。

“編譯過(guò)程”中在上述提到的加載代碼文件時(shí)會(huì)用到字符編碼，這通常稱為源字符集設(shè)置。還有一個(gè)執(zhí)行字符集設(shè)置，必須對(duì)比著來(lái)理解，在上述官網(wǎng)文章中也有較詳實(shí)的說(shuō)明，總結(jié)如下：
在將源代碼編譯位可執(zhí)行文件時(shí)，編譯器會(huì)將源代碼中的字符轉(zhuǎn)換成可執(zhí)行程序中的二進(jìn)制數(shù)據(jù)。由于不同字符集采用不同的編碼方式，因此在編譯時(shí)必須確定所使用的編碼方式，以便程序運(yùn)行時(shí)可以正確讀取和顯示字符。細(xì)細(xì)品味，源字符集和執(zhí)行字符集，它們?cè)诰幾g過(guò)程的使用目的是相反的。前者是將字符轉(zhuǎn)換為二進(jìn)制數(shù)據(jù)，而后者討論的是如何將二進(jìn)制數(shù)據(jù)加載為字符。

ANSI編碼

在其他的文章中，我們講述了大部分的編碼格式。這里我們重點(diǎn)說(shuō)一下ANSI這種編碼格式。

ANSI編碼不是一個(gè)具體的字符集，而是表示一種字符編碼的概念。具體使用哪種字符集來(lái)實(shí)現(xiàn)ANSI編碼，取決于操作系統(tǒng)和軟件的實(shí)現(xiàn)。在不同的環(huán)境中，ANSI編碼可能指代不同的字符集。在 Windows 系統(tǒng)中，“ANSI 編碼” 這個(gè)術(shù)語(yǔ)通常用于指代特定的默認(rèn)本地編碼。這個(gè)默認(rèn)的本地編碼是根據(jù)操作系統(tǒng)和區(qū)域設(shè)置來(lái)確定的。對(duì)于區(qū)域設(shè)置為中國(guó)的 Windows 系統(tǒng)，其默認(rèn)的 ANSI 編碼格式通常是 GBK（或稱 GB2312）。

通常使用 0x00-0x7f 范圍的1 個(gè)字節(jié)來(lái)表示 1 個(gè)英文字符。超出此范圍的使用0x80-0xFFFF來(lái)編碼，即擴(kuò)展的ASCII編碼。為使計(jì)算機(jī)支持更多語(yǔ)言，通常使用 0x80~0xFFFF 范圍的 2 個(gè)字節(jié)來(lái)表示 1 個(gè)字符。比如：漢字 ‘中’ 在中文操作系統(tǒng)中，使用 [0xD6,0xD0] 這兩個(gè)字節(jié)存儲(chǔ)。不同的國(guó)家和地區(qū)制定了不同的標(biāo)準(zhǔn)，由此產(chǎn)生了 GB2312、GBK、GB18030、Big5、Shift_JIS 等各自的編碼標(biāo)準(zhǔn)。這些使用多個(gè)字節(jié)來(lái)代表一個(gè)字符的各種漢字延伸編碼方式，稱為 ANSI 編碼。在簡(jiǎn)體中文Windows操作系統(tǒng)中，ANSI 編碼代表 GB2312編碼；在繁體中文Windows操作系統(tǒng)中，ANSI編碼代表Big5；在日文Windows操作系統(tǒng)中，ANSI 編碼代表 JIS 編碼。

從ANSI編碼這個(gè)定義維度上來(lái)看，那么字符集可能要分為3個(gè)大類，ASCII、ANSI、UNICODE。

其他

還有一些問(wèn)題，我沒有十分確定的搞清楚，如：
輸入法、剪切板等傳遞的應(yīng)該是字符，不是字符編碼把？否則你也怎么可能在不同編碼的文件中來(lái)回復(fù)制文本。
控制臺(tái)、IDE調(diào)試輸出窗口、UI界面等都應(yīng)該算是顯示設(shè)備，它們的運(yùn)行過(guò)程中，字符編碼扮演了怎樣的角色？
還有qDebug() 中文字符串亂碼問(wèn)題等，
這些問(wèn)題的草稿也都存好多年了，加油，騷年！文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-586624.html

到了這里，關(guān)于IDE /字符串 /字符編碼與文本文件(如cpp源代碼文件)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！