主要是因為notepad這個程式作為乙個小工具，識別編碼的功能不方便做大。當文件中所有字元都在c0≤aa≤df 80≤bb≤bf這個範圍的時候，notepad都無法確認文件的格式，沒有自動按照utf-8格式來"display"。"聯通"就是c1 aa cd a8，剛好在上面的範圍內，所以不能正常顯示[**網上]
。
其中提到如果用ascii方式開啟txt檔案,就是正常的了。或者用utf-8方式儲存 。用utf-8儲存則以ef bb bf打頭的，然後中文位元組將以三個位元組編碼乙個漢字。若以unicode編碼,則以ff fe打頭,中文位元組還以2個位元組編碼乙個漢字。
我寫了好幾個有著「聯通」字元的文字，分別儲存為ansi，utf-8，unicode形式,然後在utraedit中檢視,轉成hex形式,結果發現分別表示為
除了最後乙個對外,其他兩個都有問題,第乙個按理沒有ff fe,後面更加不對,應該就四個位元組,是這個漢字的gb碼才對啊,第二個utf-8跟第三個不一樣了麼。沒有按以上理論來啊，我怎麼也沒懷疑到ue上，還懷疑編碼是不是有什麼規則轉換的。將
ansi的檔案位元組刪去了ff fe，用ansi的方式開啟，發現只剩下乙個「通」字了，用ue再看一下，發現剩下的是「ff fe 68 03」，反而將第三，四個位元組刪了。怪了，右擊檔案屬性顯示2個位元組。於是調出我的終極**winhex，他的顯示分別為：
和傳說中的字元編碼理論描述是一致的。
utraedit他是優先識別文字，然而識別編碼的功夫又是這麼差勁，還停留在記事本的初級階段。這樣也就不說他了，但用hex檢視的時候，顯示的又是當前文字中unicode編碼二進位制表示，不是檔案本身的位元組表示，所以才有以上的結果。那個ansi碼檔案的顯示是因為不能識別，預設unicode編碼，顯示的是當前亂碼的unicode編碼位元組。真是害人不淺哪，枉我信任他這麼多年。所以呢,還是要用懷疑的態度去研究問題,不要迷信軟體。
字元編碼研究
應用開發中，經常會遇到亂碼的問題，對於新手尤其如此。為了解決亂碼問題帶來的困擾，特整理一下字元編碼的相關知識，從根本上杜絕亂碼的出現。一，相關概念 在計算機的世界中，所有的資訊都是由01組成的二進位制資訊，當然也包含字元。字元是各種文字和符號的總稱，包括各國家文字 標點符號 圖形符號 數字等。那麼如...
字元編碼 使用c 研究
一 ascii碼 我們知道，在計算機內部，所有的資訊最終都表示為乙個二進位制的字串。每乙個二進位制位 bit 有0和1兩種狀態，因此八個二進位制位就可以組合出256種狀態，這被稱為乙個位元組 byte 也就是說，乙個位元組一共可以用來表示256種不同的狀態，每乙個狀態對應乙個符號，就是256個符號，...
字元編碼 使用c 研究
一 ascii碼 我們知道，在計算機內部，所有的資訊最終都表示為乙個二進位制的字串。每乙個二進位制位 bit 有0和1兩種 狀態，因此八個二進位制位就可以組合出256種狀態，這被稱為乙個位元組 byte 也就是說，乙個位元組一共可以用來表示256種不同的狀態，每乙個狀態對 應乙個符號，就是256個符...