我相信很多人都知道,不得不處理德語元音變音和UTF8歸類可能是有問題的。諸如a = ä
,o = ö
,u = ü
之類的東西不僅能夠影響結果的排序順序,而且還能夠影響實際結果。下面是一個例子,通過簡單地區分名詞的單數和複數形式(Bademantel
- 單數,Bademäntel
- 複數),可以清楚地表明事物如何出錯。德國變音符號和UTF8歸類,重訪
CREATE TABLE keywords (
id INT (11) PRIMARY KEY AUTO_INCREMENT,
keyword VARCHAR (255) NOT NULL
) ENGINE = MyISAM DEFAULT CHARACTER
SET = utf8 COLLATE = utf8_unicode_ci;
INSERT INTO keywords (keyword) VALUES ('Bademantel'), ('Bademäntel');
SELECT * FROM keywords WHERE keyword LIKE ('%Bademäntel%');
結果應該是
+----+------------+
| id | keyword |
+----+------------+
| 1 | Bademäntel |
+----+------------+
尚未與utf8_unicode_ci
輸出是
+----+------------+
| id | keyword |
+----+------------+
| 1 | Bademantel |
| 2 | Bademäntel |
+----+------------+
這顯然不是所要求的結果。
實際問題與我目前的項目並列。它涉及編寫一個關鍵字解析器,該關鍵字解析器基本上應該用鏈接到相應的產品頁面來替換網站上每個關鍵字的出現。爲了避免不必要的資源浪費只是不同的關鍵字是牽強,但使用任何
SELECT keyword FROM keywords GROUP BY keyword ORDER BY LENGTH(keyword) DESC
或
SELECT DISTINCT keyword FROM keywords ORDER BY LENGTH(keyword) DESC
將導致無法處理(鏈接)的話,所有的非變音版本簡單因爲它們在查詢過程中沒有被提取(即所有包含Bademäntel
的關鍵字都將被提取,但Bademantel
將被忽略)。
現在我意識到我有幾個選項來解決這個問題。
1)使用utf8_swedish_ci
作爲關鍵字表或在查詢期間,這將有效地節省我不必修改大量現有代碼。
SELECT DISTINCT keyword COLLATE utf8_swedish_ci AS keyword FROM keywords ORDER BY LENGTH(keyword) DESC;
可惜我不是說不願意放棄utf8_unicode_ci
因爲)它提供分揀「Eszett」的一個非常不錯的功能(ss
和ß
被認爲是相同的),B)不知何故,只是覺得不妥使用瑞典語整理來處理德國相關的東西。
2)修改現有的代碼以利用utf8_bin
。
SELECT DISTINCT keyword COLLATE utf8_bin AS keyword FROM keywords ORDER BY LENGTH(keyword) DESC;
這按預期工作,但它有一個討厭的缺點,所有的比較是大小寫敏感的,這意味着如果我決定依靠utf8_bin
作爲針對該問題的解決方案,我將有一個很難做到不區分大小寫像LIKE('%Mäntel%')
這樣的查詢將絕對省略像Bademäntel
這樣的記錄。
我知道這個問題每時每刻都會彈出,但現在有些答案已經很老了,我只想知道是否有其他解決方案可能出現在此期間。我的意思是,我真的無法繞過這樣的想法,即允許簡單的整理來完全改變查詢的結果。排序順序是,但結果本身?
對不起,有點長的帖子,並提前感謝任何形式的建議或評論。
檢查這可以幫助你:* MySQL的字符集/自動分頁*](http://mysql.rjweb.org/doc.php/charcoll) –