但是如果你了解這些概念你就應該能夠解決你遇到這些相關的問題。
但是既然提到了這項東西，那麼我下面也會順便解釋一下是爲何會造成這樣的問題。
在來第二個革新就是開始支援UTF-8的字元集以及連線校對的指令，這個非常重要並且也是我寫這篇最主要的主角。
如果你發現你的資料庫的密碼的值開頭為*那就表示是使用4.1或是5.1版本的PASSWORD 產生出來的，這有識別的作用。
關於密碼的故事我想就此打住了，畢竟這不是我寫這篇主要的內容。
你可能會納悶為何那些還在使用甚至是MySQL3.X的資料庫，他們的網站也是用UTF-8編碼的，不是不支援嗎？
因為不支援嚕，所以MySQL用預設的「latin1字元集」來存的。
而這樣也是可以用不過還是有差異的，這是個遺憾….但是早期我們都這樣來弄。
這樣造成很難正確切割一段字串，而現在使用UTF-8也會遇到這樣的問題，因為老是不知道該如何才能正確的切斷字串。
當時對於UTF-8的技術不夠普及所以很多人都犯過這樣的錯誤(包括我)。
更慘的是不是精準的切斷，這樣就延生出被切斷後字串的最後一個字給切壞了。
用說的可能還不太有說服力，所以我還是實際用行動來解釋這個東西，請先看下圖。
所以一個字元是3，那麼我要求取出6就變成只有取出『讓討』這樣而已了。
UTF-8的MySQL4.1以上版本能夠正確精準的取出你指定要的字元數。
這樣說可能讓人有點迷惑。
所以用set的指令下達參數讓資料庫知道，如果你沒有告訴資料庫你要使用哪種字元集來連線的話，資料庫將使用他的預設值。
如果你沒有修改過預設值而且你的資料庫是4.1(含)以上的話，你看到的情況應該也是跟上圖一樣才對。
似乎有寫朋友雖然幫忙解決其他人對於編碼的問題卻沒有告訴他這些東西代表什麼，這樣好像有點可惜。
基本上4.1(含)以上的查詢流程必須要先告訴資料庫一些東西。
我還是要強調，你如果不告訴資料庫的話它就是用預設值來處理。
例如用UTF-8編碼的網站用latin1 不就延生出我上面提到的字元數無法準確計算的問題嚕。
以上的屁話其實蠻多的，事實上我寫這篇我也不知道是要表達什麼，就當作純粹的交流，或許我說的並不是正確的。
這樣也很好啦，如果你願意告訴我我哪裏寫錯了也可以告訴我，有錯誤並且找到真實的答案有助於加強記憶。
最後由 神川小羽 於 2007-04-28 03:37 編輯，總共編輯了 1 次。
精彩的文章要推一下，允許轉載嘛？
同時再推薦另一篇英文的教學文章：
但是我實在很難肯定我這些內容是不是任何會造成誤導的錯誤。
如果你發現你的資料庫的密碼的值開頭為*那就表示是使用4.1版本的PASSWORD 產生出來的，這有識別的作用。
MySQL Reference Manual 上面也是寫 4.1 以後 (嚴格一點說是 4.1.2 以後) 都是這麼長。
就是因為 MySQL 4.1+ 對 Unicode 的支援讓很多人手癢去改 charset，才會有像這篇一樣自爆已後的心得。
然後也因為很多人對 charset 和 collation 的觀念錯誤或是沒花時間去了解，所以才會很多人到現在還停留在 MySQL 4.0 (or 3.23) 這些 EOL 的版本上。
小羽寫的這篇文章極富參考價值。
移動至「教學文件庫」版面。