手持兩把錕斤拷,口中疾呼燙燙燙。腳踏千朵屯屯屯,笑看萬物鍩鍩鍩

錕斤拷編碼

Unicode和老編碼體系的轉化過程當中,確定有一些字,用Unicode是無法表示的,Unicode官方用了一個佔位符來表示這些文字,這就是:U+FFFD REPLACEMENT CHARACTER。
那麼U+FFFD的UTF-8編碼出來,剛好是 '\xef\xbf\xbd'。若是這個'\xef\xbf\xbd',重複屢次,例如 '\xef\xbf\xbd\xef\xbf\xbd',而後放到GBK/CP936/GB2312/GB18030的環境中顯示的話,一個漢字2個字節,最終的結果就是:錕斤拷——錕(0xEFBF),斤(0xBDEF),拷(0xBFBD)[1]  。
url

http://baike.baidu.com/link?url=GCoDM7HBIV_JcJfXzIU9p1Rx7r8Ns2w6jVoZwnhn9ZizxhNG7egrUWojSETDzxb74uZFeVGIBK_qZYgNTo7So_spa

鍩鍩鍩原理調試

BOM 是 Byte Order Mark 的縮寫。是UTF編碼方案裏用於標識編碼的標準標記,在UTF-16裏原本是FF FE,變成UTF-8就成了EF BB BF。這個標記是可選的,由於UTF8字節沒有順序,因此它能夠被用來檢測一個字節流是不是UTF-8編碼的。
code

  • EFBB
  • BFEF
  • BBBF


出現這個問題確定是你寫網頁的時候用了記事本 ,記事本在保存文件的時候把本來文件的編碼改了記事本會默認保存爲UTF-8的編碼,而若是你本來網頁是GBK編碼的,就會出現亂碼~BOM就是把一個Unicode保留字符U+FEFF,按照文件存儲者的編碼方式編碼後,塞到文件內容的最前邊。這樣用不一樣的Unicode編碼去解析文件頭,就能夠得知文件的編碼方式和大小端順序。結果就是文件頭部多出來了兩三個字節。內存

有了BOM全部的程序都必須爲BOM做出修改,這無疑是一個「大折騰」的行爲。因此通常不認爲BOM是個好主意。BOM引起的問題,我能想起來兩個:unicode

PHP沒法指定header(由於有BOM至關於開啓輸出)
UNIX可執行腳本的Shabang標記(#!)不能識讀
io


任什麼時候候都採用無BOM的UTF-8編碼的Unicode,絕對是一個引起麻煩最少的最實用策略。UTF-8是Unicode的最佳實踐,沒有之一。
必須指出的是,何棄療的微軟常常作出非要DOM不可的行爲,最典型的例子就是那個記事本(存盤就加DOM)。因此任什麼時候候,都千萬別偷懶用記事本編輯PHP。華語驕傲Notepad++是Windows下的不二之選。
變量


燙燙燙屯屯屯原理

在Visual Studio中的Debug模式下,若是聲明一個變量,可是沒有初始化,微軟會給未初始化的內存複製爲0xCC。給爲初始化的內存賦0xCC是有緣由的,0xCC實際上是INT3中斷指令,因此若是在Debug模式下試圖去執行這塊未初始化的內存的話就會中斷程序。

但VS中調試器默認的字符集是MBCS,而在MBCS中0xCCCC正好就是中文中的「燙」,因此顯示出來就都是燙……

若是是用分配堆的內存,會初始化成0xCD,0xCDCD在MBCS字符集中就是……

錕斤拷則涉及unicode的字符集轉換問題,Unicode和老編碼體系的轉化過程當中,確定有一些字,用Unicode是無法表示的,Unicode官方用了一個佔位符來表示這些文字,這就是:U+FFFD REPLACEMENT CHARACTER。U+FFFD的UTF-8編碼是0xEFBFBD,若是重複屢次造成:EFBFBDEFBFBDEFBFBD 這樣

在GBK/CP936/GB2312/GB18030的環境(都是中國標準惹的禍)中顯示的話,一個漢字2個字節,最終的結果就是:錕斤拷——錕(0xEFBF),斤(0xBDEF),拷(0xBFBD)……