光 UTF-8 並未解決中文問題!

[snaking]

以這個論壇來說,我用"打鐵匠" 這個名稱來註冊,結果存到資料庫再叫出來後,已是後面一堆亂碼,我想這是MySQL 的問題!

相信很多人都有同樣的困擾,而這問題也不只是MySQL 4.1.x 之後的問題,更早的版本也是, 但都見不到關於這方面的權威討論,大家都是瞎子摸象,見招拆招,是用於某人的方法不見得適用於別人,而 MySQL 的開發團隊,似乎對於解決中文問題也不熱衷,沒人知道黑箱裡賣什麼膏藥!

發這貼的原因,是想拋磚引玉一下,聽聽大家在這方面的看法!

[FIEND]

mysql 底層 預設都是拉丁語系 ...

而且 它看到不懂的字元  會以 html unicode 存入資料庫 您的問題可能不是發生在 資料庫

而是發生在 程式處理字串的邏輯  您有實驗過嗎 為何會有此定論 ^^  小弟只是好奇

[markwu]

以這個論壇來說,我用"打鐵匠" 這個名稱來註冊,結果存到資料庫再叫出來後,已是後面一堆亂碼,我想這是MySQL 的問題!

相信很多人都有同樣的困擾,而這問題也不只是MySQL 4.1.x 之後的問題,更早的版本也是, 但都見不到關於這方面的權威討論,大家都是瞎子摸象,見招拆招,是用於某人的方法不見得適用於別人,而 MySQL 的開發團隊,似乎對於解決中文問題也不熱衷,沒人知道黑箱裡賣什麼膏藥!

發這貼的原因,是想拋磚引玉一下,聽聽大家在這方面的看法!

如果只是光要討論 UTF-8 有沒有解決問題，我認為不適合在這裡討論。因為這會又要 討論到  UTF-8, GB2312 與 BIG5 的比較，而且跟 pLog 也沒有關係。

使用 UTF-8 的原因不在於他的『技術』比其他的編碼優越，在於他的『包容』性比其他編碼大。所以我們才可以在同一個畫面同時顯示簡體、繁體、日文、韓文、拉丁文、俄文、波斯文、希伯來文。

至於為什麼使用 UTF-8 還是為有亂碼的問題，那是因為目前的程式都是以英美語系為主來開發，所以他們常常會避掉(escape) ASCII 128 以上的字元，而這又剛好是其他語系所會用到的字元區，所以才會造成問題。所這就是為什麼 php 會有 mbstring 這個 library 來處理雙位元文字的原因。其他的開發環境也有相對應的問題。這也是為什麼再開發 Web 程式時，當編碼是 big5，常常需要 addslash 與 stripslash 的原因。

所以真要要解決這些問題，不是三言兩語就能說完的。從 OS/DB/LANGUAGE/APPLICATION ... 都是很重要的環節。這也是為什麼大家想盡辦法讓 OS/DB/LANGUAGE/APPLICATION 都能支援 UTF-8 的原因就在這。

所以如果你只想問『而 MySQL 的開發團隊,似乎對於解決中文問題也不熱衷,沒人知道黑箱裡賣什麼膏藥!』，建議到 mysql 的論壇或是郵件論壇去發問，你才能有機會得到比較正確的答案。

BTW, 你說的會變亂碼，通常是程式在處理雙位元字串時發生的問題，跟 MYSQL 似乎無關。

Mark

[snaking]

mysql 底層 預設都是拉丁語系 ...

而且 它看到不懂的字元  會以 html unicode 存入資料庫 您的問題可能不是發生在 資料庫

而是發生在 程式處理字串的邏輯  您有實驗過嗎 為何會有此定論 ^^

我也是認為如此,但曾耗費過無數青春,把網路上找的到的方法,所有排列組合都試過,依然無解,唯一動不到的,就是MySQL 的內部處理機制!

我曾用 blob 的二進位欄位來處理中文字的儲存問題,如此才能避免 MySQL 對我的文字做多餘的轉換!

我無法提供任何有效的解決方案或見解,因為我自己腦袋中因為試過太多種方法,已是一團亂. 任何非釜底抽薪的解決方式,我已經怕到了!

回應一下 Mark兄的看法, 若是改別人的 套裝程式,可能會因結構太過複雜而忽略了哪一部份的轉譯或處理而致修改無效, 但我碰到的例子是,完全自己開發的程式,變數已盡量降到0!

我拋磚的目的,只是想聽聽有沒有人已經看到走向康莊大道的曙光了!

[markwu]

mysql 底層 預設都是拉丁語系 ...

而且 它看到不懂的字元  會以 html unicode 存入資料庫 您的問題可能不是發生在 資料庫

而是發生在 程式處理字串的邏輯  您有實驗過嗎 為何會有此定論 ^^

我也是認為如此,但曾耗費過無數青春,把網路上找的到的方法,所有排列組合都試過,依然無解,唯一動不到的,就是MySQL 的內部處理機制!

我曾用 blob 的二進位欄位來處理中文字的儲存問題,如此才能避免 MySQL 對我的文字做多餘的轉換!

我無法提供任何有效的解決方案或見解,因為我自己腦袋中因為試過太多種方法,已是一團亂. 任何非釜底抽薪的解決方式,我已經怕到了!

回應一下 Mark兄的看法, 若是改別人的 套裝程式,可能會因結構太過複雜而忽略了哪一部份的轉譯或處理而致修改無效, 但我碰到的例子是,完全自己開發的程式,變數已盡量降到0!

我拋磚的目的,只是想聽聽有沒有人已經看到走向康莊大道的曙光了!

不太對！就 Mysql 4.0 來看，對 UTF-8 的支援真的不太好，預設的編碼字元也是 Latin-1。

可是到 Mysql 4.1，你可以更改處理字元為 UTF-8，另外檢查校對也可以處理成 UTF-8。我目前遇到會造成亂碼的問題，只有：
1. 我把 Mysql 的預設字元弄錯了。
2. 我把字元儲存進 Mysql 時，處理錯了。

所以，如果你確定做的都是對的，那麼就是 Mysql 對 UTF-8 處理的 Bug, 你有跟他們回報過嗎？另外，這是必須以實例來探討 Mysql 到底會對你的字元作了什麼轉換，這樣才有辦法來知道問題阿。

你可以看一下我們之前在 pLog 1.0 時處理 Mysql 4.1/UTF-8 的一些相關討論：http://pesty.yichi.org/plog/index.php?op=ViewArticle&articleId=336&blogId=1

Mark

[snaking]

謝謝您的指引,我好好拜讀過後再來請教!

Mark兄有考慮把過去的經驗好好整理一番嗎?  相信您探索問題的方法，會給我們很好的指引!

有很多問題不解，譬如 locale 跟編碼之間的關係為何? 各軟體之間,到底是依循著什麼樣的準則來判斷別人丟過來的文字編碼？又依循這什麼樣的準則、什麼時機來加以轉換? 非官方說法也無所謂!

或許大家一起來寫個標準測試程式，看看在不同的OS,不同的DB版本，不同的欄位屬性，不同的locale,default-language,default-charset宣告, 會產生什麼樣的結果!

[markwu]

謝謝您的指引,我好好拜讀過後再來請教!

另外你可以看一下：http://www.neo.com.tw/archives/000552.html

主要的原因通常都發生在 SET NAMES UTF-8

在 4.0 時不需這麼做，但到 MySQL 4.1 時你必須要 SET NAMES UTF-8 讓

SET character_set_client = utf-8;
SET character_set_results = utf-8;
SET character_set_connection = utf-8;

** BTW, 我實在不相信 MySQL 會怎麼動手腳自行幫你轉換資料，所以如果你都設對了，可是卻還是有亂碼，那麼把你實際的  CASE 跟 MySQL 反應。這才是使用 Open Source 開發專案的態度吧。

Mark

[snaking]

再次謝了!
因為目前研發案同時需面對很多問題以致分身乏術，加上自知對相關基礎知識所知尚淺，根本還沒考慮過直接跟MySQL 官方反應! 加上看到別人提的問題,官方也是一副愛莫能助的樣子，更無勇氣『見義勇為』!

(其實我很懷疑，如果開發小組的人都不懂中文，叫他們如何測試起呢 ?)

[FIEND]

  你知道 taiwan 的程式設計師最 矯傲 的是什麼嗎 .....

就是每天都在處理 語系的問題 被操的有夠強的 哈哈哈哈

很可悲吧 ccc

[markwu]

再次謝了!
因為目前研發案同時需面對很多問題以致分身乏術，加上自知對相關基礎知識所知尚淺，根本還沒考慮過直接跟MySQL 官方反應! 加上看到別人提的問題,官方也是一副愛莫能助的樣子，更無勇氣『見義勇為』!

(其實我很懷疑，如果開發小組的人都不懂中文，叫他們如何測試起呢 ?)

如果你的問題只是：『為什麼 UTF-8 中文從 mysql  取出後變亂碼？』，那大概沒人會幫你的。

如果你能附上完整的 Test Case、 Error Logs，並且讓他可以重製你的 bug，我相信他不會置之不理。

就像你最開始的問題，那麼大而且又含糊。丟到那邊誰會來幫你回答呢？不是嗎？

Mark

[minstrel]

MySQL 4.1以前好像根本就沒考慮到Unicode的問題, 對非歐系文字的處理出問題是常有的事.
新版的MySQL雖然號稱有支援Unicode, 不過在轉碼方面似乎有著更多問題.

以程式設計的觀點來看, 我會建議暫時不要在MySQL上處理Unicode的問題. 自己寫轉碼.

MySQL 5 不知會不會好一點.

另外, FIEND所提的語系問題, 其實很正常. 當同時要做外國與本國產品時, 多語系的支援就一定跑不掉. 以我現在手上的案子來看, 歐洲, 美國, 日本, 台灣客戶都有需求, 總不可能讓所有人只用英文吧. 其實多語系, 沒有那麼困難, 只是頗煩而已.

BTW, 這裡似乎是pLog支援論壇.....

[snaking]

那就勞煩大家指點了 ,我就不客氣問問題了:-P

執行安裝時,得到 MySQL 語法錯誤,於是我猜是MySQL 不認得utf-8編碼,於是我下:
mysql --default-character-set=utf-8

回應:
mysql: Character set 'utf-8' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index' file

Q1:用 latin1 代替可嗎?
Q1:若不行,去哪裡才能下載 utf-8.conf,還是有其他解法 (假設不考慮更新MySQL版本)?
Q3:執行安裝時,得到 MySQL 語法錯誤,是這個問嗎?

版本資訊

程式碼:

OS: Linux
MySQL:3.23.54

[markwu]

那就勞煩大家指點了 ,我就不客氣問問題了:-P

執行安裝時,得到 MySQL 語法錯誤,於是我猜是MySQL 不認得utf-8編碼,於是我下:
mysql --default-character-set=utf-8

回應:
mysql: Character set 'utf-8' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index' file

Q1:用 latin1 代替可嗎?
Q1:若不行,去哪裡才能下載 utf-8.conf,還是有其他解法 (假設不考慮更新MySQL版本)?
Q3:執行安裝時,得到 MySQL 語法錯誤,是這個問嗎?

版本資訊

程式碼:

OS: Linux
MySQL:3.23.54

這些問題屬於 MySQL 的設定範疇了，請到 MySQL 的相關論壇討論。另外，如果你希望正常使用 MySQL 提供的 UTF-8 功能。請把你的 MySQL Upgrade 到 4.1 吧。

Mark

[licheng]

mysql: Character set 'utf-8' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index' file

版本資訊
OS: Linux
MySQL:3.23.54

我個人使用 MySQL，都是自行抓取原始程式碼編譯安裝。從 3.23.xx 一直玩到 4.0.x。但是，因為工作的關係，已經一年多沒有碰觸 MySQL 了。僅記憶所及，大略說說。

MySQL 對於編碼的支援，其實大多只要在編譯時指定，作為預設值，或是作為支援的編碼，使用上都不會有問題。

而我發現，那些跟 MySQL 編碼奮鬥的，大多使用作業系統的套件管理程式來安裝。偏偏，那些 MySQL 套件，基本上不支援 Big5 或 UTF-8。於是，他們將腦筋動到 PHP 上面來。

我是  PHP 白痴。不過，在 Linux 跟 BSD 上頭跑的 PHP 程式，因為 MySQL 是自己編譯的，該支援的語系，老早就編譯進去，PHP 程式碼根本不用作任何更動，至今尚未發生編碼錯誤的情況。

當然，PHP, Apache 等， 我也是自己編譯。

我只會系統維護與管理，懂一些 shell script，不懂 PHP。

一點兒個人經驗，提供給 snaking 參考。

[snaking]

非常感謝以上各位的建議,任何的心得分享都讓我感到彌足珍貴