這是個很有意思的事情。
這裡需要提一下ansi，不同的國家和地區制定了不同的標準，由此產生了 gb2312, big5, jis 等各自的編碼標準。然後，這些編碼方式沒有固定的格式，但是比如說utf-8的格式是非常明顯的，比如最高位是0，110，1110等等。在記事本儲存操作中，windows預設儲存的編碼是ansi（在中國是gb2312）。
這樣聯通這兩個字的二進位制內碼是：（乙個字佔兩個位元組）
「聯」ansi編碼是 0xc1aa 二進位制排列是 1100 0001 1010 1010；
「通」ansi編碼是 0xcda8 二進位制排列是 1100 1101 1010 1000；
下圖是utf-8的格式的部分截圖
巧合的地方在於：「聯通」這兩個字的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]之間就行，貌似聯通躺著也中槍，那麼我們力挺聯通吧，比如「力挺聯通」四個字兒照樣是亂碼。呵呵，沒轍兒了，開玩笑。其實你只要找到符合條件的漢字太容易了。
如何標明乙個檔案是utf8格式呢？這個標記是可選的：ef bb bf。比如，用windows自帶的記事本建立乙個utf8格式的檔案，就會加上這個標記。但是，如果用ultraedit建立utf8檔案，並不會加上這個標記。這個標記有個術語，叫做bom（byte order mark）。不帶bom的utf8檔案和gb2312檔案怎麼區分呢？我也不知道。唯一能想到的辦法就是：先用一種試，如果出現亂碼，就用另一種再試
個人記事本
size t strlen const char s the strlen function calculates the length of the string s,excluding 不包括 the terminating null byte 0 計算長度時，不包括末尾的結束符 0 但是，換行...
記事本 陳慧琳
翻開隨身攜帶的記事本 寫著許多事都是關於你 你討厭被冷落 習慣被守候 寂寞才找我 我看見自己寫下的心情 把自己放在卑微的後頭 等你等太久 想你淚會流 而幸福快樂是什麼 愛的痛了 痛的哭了 哭的累了 日記本裡頁頁執著 記載著你的好 像上癮的毒藥 它反覆騙著我 愛的痛了 痛的哭了 哭的累了 矛盾心裡總是...
記事本程式
anchor 控制項與容器周圍的距離保持不變 dock 定義容器要停靠到哪一邊，重要的乙個是fill填充 using system using system.collections.generic using system.componentmodel using system.data using...