隨著各種多字節字符集的廣泛應用，而在軟體開發里人數比例非常高的操英文的程式設計師對多字節字符並不是很了解，這是最近幾年很多漏洞都是多字節引起的一個原因。本文作者就MySQL的字符集架構作用談了自己的看法。 最近幾個月，我每次都用MySQL，我幾乎都會想：MySQL現在這樣層次分明的字元集架構效果真的很大嗎？
MySQL的字符集處理
發送請求
客戶端(character_set_client)=》資料庫連線(character_set_connection)=》儲存(table,column)
返回請求
儲存(table,column)=》資料庫連線(character_set_connection )=》客戶端(character_set_results)
在每一個非初始節點，都會做一次從上一個結點到目前節點的字元集轉換操作。舉個例子，有以下環境：
◆ character_set_connection utf-8
◆ character_set_results gbk
◆ character_set_client gb2312
◆ 有表A，字段字元集全部為BIG5
發送請求的時候，首先資料從gbk轉換為utf-8，再轉換為BIG5，然後再儲存。
回傳請求的時候，首先資料從BIG5轉換為utf-8，再轉換為gb2312，然後再傳送給客戶端。
架構的作用
1. 允許不同的客戶端具有不同的字元集。典型的例子就是，我有一個utf-8的站點，這個站點就是一個charset client為utf-8的客戶端。同時，我有可能需要在一個gbk的終端機上讀寫資料庫，這又是一個客戶端，不過它的字元集是gbk。
2. 透過資料庫操作檔案系統的時候，需要把檔案路徑轉為檔案系統的字元集。例如我的客戶端是gbk，而伺服器檔案系統是utf-8。操作”/A片/Rina.rmvb”，發送過去的資料裡，“片”的資料和伺服器是不一樣的。這時候就需要有個辦法可以把轉換GBK的「片」到utf-8。這裡MySQL引入了一個叫做character_filesystem的東西來完成這個事情。
除此之外，我暫時想不到其他的作用了。但仔細想想，我們真的需要這樣的處理嗎？很多網站，無非就是希望自己的資料怎麼進去就怎麼出來。這裡又有兩種情況了。
1. 希望可以根據資料進行排序或做like操作。首先說排序，對於包含中文的欄位來說，根據字元集排序的概念如同雞肋。簡體中文排序，一般都是希望按拼音來排序。我沒有去真正了解MySQL裡的校驗，但是從我接觸過的程式來看，需要做這類排序，都是專門建立一個存放拼音的欄位來排序。而拼音又存在多音字的情況。如果是UTF-8，還存在某個區間的中文同時被中日韓三國共用的情況。實作起來不是這麼容易，所以MySQL無論的GBK還是UTF-8的校驗集應該都沒有實現拼音。我敢說，現在國內使用MySQL的多數網站，所使用的校驗集，只是一個byte排序而已。而byte排序，根本不需要使用什麼字元集。所以說對於中文站點，MySQL字元校驗在排序上沒任何意義。
但是在like操作上，倒是有了一點意義。例如我like '%a%'，就有可能配對到某個中文某個部分含有a。當然這種情況在utf-8下不會遇到，因為utf-8的儲存格式導致a只可能是a，不可能是一個多位元組字元的一部分。但是在其他字符集可能就會有這個問題了。說到最後，like又變得和order一樣使得校驗沒意義了。暈倒。
2. 如果完全不需要對資料進行排序，like或全文檢索，那麼請停止使用char，varchar，text之類的吧。 binary，varbinary，BLOB才是正確的選擇。 binary之類的在存儲，取出的時候都不會進行字符集轉換，而在排序時候，只根據二進制內容排序，所以在效率上高出char，varchar，text很多。
這種情況更不需要字符集了。但依照目前MySQL的架構，在client和connection之間的字元集操作，是忽略欄位類型的，在這兩個節點之間，還是會進行字元集轉換。
另外提一下PHP裡的設定字符集。大家請不要再使用mysql_query(”set names utf8″)這樣的語句了。 mysql_set_charset()才是最完整的字元集設定方式。後者比前者多一個設置，就是把struct MySQL的charset成員也設置了。這個成員變數在escape的時候起著很重要的作用，特別是對於GBK這種運行把“”作為字符一部分的編碼格式。如果你只使用mysql_query(”set names XXX”)，那麼在某些字元集，會有重大的安全漏洞，導致mysql_real_escape_string變得和addslashes一樣不安全。
-