壹般來說，我們的網頁代碼編程都是基於壹定的規則來完成編寫的，而大部分的情況下我們采用也是utf的編輯規則。下面，昭通電腦培訓/就通過案例分析來了解壹下服務器開發可以使用哪些編碼規則。
服務器開發適用哪些編程開發規則
那麽什麽是編碼?什麽是UTF-8?
我們都知道，計算機使用0和1來存儲文本。比如字符“C”被存成“01000011”，那麽計算機在顯示這個字符時需要經過兩個步驟：
計算機讀取“01000011”，得到數字67，因為67被編碼成“01000011”。
計算機在Unicode字符集中查找67，找到了“C”。
同樣的：
我的電腦將“C”映射成Unicode字符集中的67。
我的電腦將67編碼成“01000011”，並發送給Web服務器。
幾乎所有的網絡應用都使用了Unicode字符集，因為沒有理由使用其他字符集。
Unicode字符集包含了上百萬個字符。簡單的編碼是UTF-32，每個字符使用32位。這樣做簡單，因為壹直以來，計算機將32位視為數字，而計算機在行的就是處理數字。但問題是，這樣太浪費空間了。
UTF-8可以節省空間，在UTF-8中，字符“C”只需要8位，壹些不常用的字符，比如“”需要32位。其他的字符可能使用16位或24位。壹篇類似本文這樣的文章，如果使用UTF-8編碼，占用的空間只有UTF-32的四分之壹左右。
MySQL的“utf8”字符集與其他程序不兼容，它所謂的“”，可能真的是壹坨
MySQL簡史
為什麽MySQL開發者會讓“utf8”失效?我們或許可以從提交日誌中尋找答案。
MySQL從4.1版本開始支持UTF-8，也就是2003年，而今天使用的UTF-8標準(RFC3629)是隨後才出現的。
舊版的UTF-8標準(RFC2279)多支持每個字符6個字節。2002年3月28日，MySQL開發者在壹個MySQL4.1預覽版中使用了RFC2279。
同年9月，他們對MySQL源代碼進行了壹次調整：“UTF8現在多只支持3個字節的序列”。
是誰提交了這些代碼?他為什麽要這樣做?這個問題不得而知。在遷移到Git後(MySQL開始使用的是BitKeeper)，MySQL代碼庫中的很多提交者的名字都丟失了。2003年9月的郵件列表中也找不到可以解釋這壹變更的線索。