網上流傳著乙個笑話，說微軟和聯通有仇，內容大致如下：
如果你的電腦作業系統是win2000或winxp的話，那麼：
1. 在桌面上點右鍵，選擇新建 — 文字文件；
2. 開啟"新建 文字文件"，錄入"移動"兩字後儲存後關掉
3. 重新開啟"新建 文字文件"，看到什麼了？是不是剛剛錄入的"移動"兩字？
4. 把"移動"分別換成"電信"和"網通"，重複1--3步，是不是也都沒什麼問題？
5. 現在我們拿"聯通"來試試，重複1--3步，你會發現剛剛錄入的"聯通"兩字不見了，取而代之是個燒焦的手機電池（乙個符號）。 看來微軟確實跟聯通有仇呀！
笑話當然是笑話，不能當真。但為什麼會這樣呢？是微軟的bug嗎？確實有點像，不過——微軟是世界頂級的軟體公司，記事本則有可能是windows中最簡單應用程式，說這是bug未免有點不合情理吧？
好了，既然把自己的主觀臆斷否定了，就讓我們踏上尋找事實真相的艱苦歷程吧:)。
不知你注意過沒有，記事本的開啟、儲存對話方塊比普通的檔案對話方塊多乙個編碼選項，可以通過它指定檔案的編碼是unicode、ansi還是utf8。"喔，我知道了"，你可能會說，"這肯定是windows api istextunicode惹的禍。因為文字檔案本身不儲存編碼資訊，所以記事本開啟檔案時就要呼叫istextunicode來判斷檔案的編碼。而istextunicode是根據文字的內容猜測其編碼，所以肯定是它猜錯編碼格式了。想想『聯通'只有兩個字，這樣的錯誤有情可原，ok了，問題解決了"。
說實話，一開始我也是這麼想的，但後來發現，我犯了兩個錯誤。①istextunicode並沒有猜錯，不信你可以檢查一下istextunicode("聯通", 4, null)的返回值。②記事本有可能儲存編碼資訊，這個後面再說。
原來，記事本除了判斷編碼是不是unicode以外，還要判斷它是不是utf8。"聯通"兩個字的**是（位元組順序從低到高）：c1 aa cd a8，轉換為二進位制是：11000001 10101010 11001101 10101000。對照utf8編碼方案（詳情請見http://.cis.ohio-state.edu/htbin/rfc/rfc2279.html）：
0000-007f之間的字元不做轉換
0080-07ff之間的編碼為110***xx 10******
0800-ffff之間的編碼為1110***x 10****** 10******
不難發現，"聯通"的編碼符合第二種情況，所以記事本把它判定為utf8編碼，而對其進行解碼後，將變成00000000 01101010 00000011 01101000。注意：前兩個位元組解碼後並不在0080--07ff之間，所以被認為是錯誤的值，忽略了。後面兩個位元組經過調整位元組順序後，將變為16進製制的0x0368，也就是那塊燒毀的電池了（取決於所使用的字型）。
ps:
1. 如果你儲存檔案時，指定使用除ansi以外的編碼，記事本將用檔案開頭的幾個位元組儲存檔案編碼，unicode對應0xfeff，unicode big endian對應0xfffe，utf-8對應0xbfbbef。這幾個位元組被稱為bom（我也不知道是那幾個單詞的縮寫）。如果檔案有bom，記事本直接使用它判斷編碼，否則它就根據檔案內容判斷編碼。
2. 分析的過程中我用ultra edit來檢視檔案的16進製制內容，但它會自動進行編碼轉換並給檔案加上乙個bom，導致看到的和實際不符(檔案4位元組，到了ultraedit中就成了6位元組)，讓我走了一些彎路。
微軟和雅虎大量技術重疊
據微軟首席研究和戰略 蒙代稱，微軟和雅虎有 大量重迭的開發 活動 尤其是在 搜尋 和 廣告領域。微軟和雅虎重迭業務有adcenter和panama windows live hotmail和yahoo mail live search和yahoo search windows live spaces...
微軟和Linux 真正的浪漫還是有毒的愛情？
時不時的我們會讀到乙個能讓你喝咖啡嗆到或者把熱拿鐵噴到你顯示器上的新聞故事。微軟最近宣布的對 linux 的鍾愛就是這樣乙個鮮明的例子。從常識來講，微軟和自由開源軟體 foss 運動就是恆久的敵人。在很多人眼裡，微軟體現了過分的貪婪，而這正為自由開源軟體運動 foss 所拒絕。另外，之前微軟就已經給...
微軟和蘋果21大失敗的創新技術
古往今來,大獲成功的產品未必是最具創新性的產品,而最具創新性的產品卻未必能獲得成功.以下是微軟和蘋果的21大創新技術,但遺憾的是它們都失敗了.提起失敗的技術,人們馬上會想起微軟bob和ibm pcjr等產品.其實,這些產品根本上算不上偉大產品,bob從創意上講本身就比較失敗.而獲得成功的產品卻未必就...