記事本輸入“聯通”倆字，關閉再開啟亂碼，再開啟亂碼

記事本輸入“聯通”倆字，關閉再開啟亂碼，再開啟亂碼
記事本輸入“聯通”倆字，關閉再開啟亂碼    這是個很有意思的事情。    這裡需要提一下ANSI，不同的國家和地區制定了不同的標準，由此產生了 GB2312, BIG5, JIS 等各自的編碼通訊協定。然後，這些編碼方式沒有固定的格式，但是比如說UTF-8的格式是非常明顯的，比如最高位是0，110，1110等等。

在記事本儲存操作中，windows預設儲存的編碼是ANSI（在中國是GB2312）。

    這樣聯通這兩個字的二進位內碼是：（一個字佔兩個位元組）

“聯”ANSI編碼是  0xC1AA 二進位排列是 1100 0001   1010 1010；

“通”ANSI編碼是  0xCDA8 二進位排列是 1100 1101  1010 1000；

    巧合的地方在於：“聯通”這兩個字的ANSI編碼符合utf8編碼的第二個模板（參考這裡）。“聯”的兩個位元組、“通”的兩個個位元組的起始部分的都是"110"和"10"，正好與UTF8規則裡的兩位元組模板是一致的，於是再次開啟記事本時，記事本就誤認為這是一個UTF8編碼的檔案（這才是原因），讓我們把第一個位元組的110和第二個位元組的10去掉，我們就得到了"00001 101010"，再把各位對齊，補上前置的0，就得到了"0000 0000 0110 1010"，不好意思，這是UNICODE的0x006A，也就是小寫字母"j"（用UltraEdit可以看到字母 j ），而之後的兩位元組用UTF8解碼之後是0x0368，這個字元什麼也不是，顯示亂碼

    這就是只有"聯通"兩個字的檔案沒有辦法在記事本裡正常顯示的原因。

    可以認為：當文檔中的所有字元的二進位編碼在[C0 ≤ AA(第一個位元組) ≤ DF]  [80 ≤ BB(第二個位元組) ≤ BF]時，記事本都無法確認文本的編碼格式，就按照UTF-8的格式來顯示。   用“聯通”來分析就是 C1在[C0,DF]之間，CD也在[C0,DF]，AA和A8在[80,BB]之間。

    這麼說，不只是“聯通”二字造成了亂碼，只要找兩個字的gbk碼值在[C0,DF]之間就行，貌似聯通躺著也中槍，那麼我們力挺聯通吧，比如“力挺聯通”四個字兒照樣是亂碼。呵呵，沒轍兒了，開玩笑。其實你只要找到合格漢字太容易了。

建立記事本檔案，錄入 ‘未知’ 兩字，儲存並關閉，再開啟此檔案後出現亂碼

　　這個是微軟沒有處理好編碼問題造成的，我記得出現亂碼不只是這兩個字，你以前有沒有看過一個用記事本畫畫的，就是利用特殊編碼。
　　總之，這個是windows的系統問題，無解~~
 
記事本顯示亂碼

在記事本中儲存的編碼方式是ANIC編碼，為 c1aa cda8
就是11000001101010101100110110101000正好符合utf-8編碼方式，所以誤認為utf-8，你可以看到最後變成utf-8編碼方式了。這是記事本本身存在的漏洞。你可以輸入aaaa aaa aaa aaaaa試試，結果也挺有意思，呵呵