MySQL diacritische tekens in query negeren

[Verwijderd]

Hoi,

ik wil een query schrijven die een plaatsnaam suggestie doet ahv invoer gebruiker. Als iemand 'Kastel' intikt, wil ik ook resultaten zoals 'Kaštelir' tonen. Kan ik dit in de query oplossen? Ik heb me al rot gegoogled.

[mrBussy]

Heb je al geprobeerd met soundex?

http://dev.mysql.com/doc/...ons.html#function_soundex

[Verwijderd]

mrBussy schreef op donderdag 17 juni 2010 @ 15:10:
Heb je al geprobeerd met soundex?

http://dev.mysql.com/doc/...ons.html#function_soundex

Dit gaat niet voldoende zijn, want als je een deel van een string zoekt, moet je de volledige plaatsnaam terugkrijgen. soundex kun je gebruiken bij volledige strings

[NMe]

SQL:

SELECT 'Kaštelir' =  'Kastelir'

'Kaštelir' = 'Kastelir'
1

[DexterDee]

Dit zal je vast al zelf bedacht hebben, maar je zou een extra kolom in je plaatsnamen tabel kunnen maken die de plaatsnaam opslaat zonder diakritische karakters.

In de code moet je dan een functie hebben die de omzetting doet:
é,è,ë => e
á,à,ä => a
etc...

[NMe]

DexterDee schreef op donderdag 17 juni 2010 @ 15:26:
Dit zal je vast al zelf bedacht hebben, maar je zou een extra kolom in je plaatsnamen tabel kunnen maken die de plaatsnaam opslaat zonder diakritische karakters.

In de code moet je dan een functie hebben die de omzetting doet:
é,è,ë => e
á,à,ä => a
etc...

But why? Ik heb hier een tabelletje waarin ik de tekst uit de topicstart in een veld heb gestopt. Vervolgens:

SQL:

SELECT *
FROM `tabel`
WHERE `veld` LIKE 'kastel%'

Resultaat:

id 	veld
1 	Kaštelir

Dat is toch gewoon wat de topicstarter wil, zonder verder iets speciaals te hoeven doen?

Betreft "gewoon" een MyISAM-tabel met UTF-8 collatie trouwens.

[ Voor 4% gewijzigd door NMe op 17-06-2010 15:31 ]

[Verwijderd]

NMe schreef op donderdag 17 juni 2010 @ 15:30:
[...]

But why? Ik heb hier een tabelletje waarin ik de tekst uit de topicstart in een veld heb gestopt. Vervolgens:

SQL:

SELECT *
FROM `tabel`
WHERE `veld` LIKE 'kastel%'

Resultaat:

id 	veld
1 	Kaštelir

Dat is toch gewoon wat de topicstarter wil, zonder verder iets speciaals te hoeven doen?

NMe schreef op donderdag 17 juni 2010 @ 15:25:

SQL:

SELECT 'Kaštelir' =  'Kastelir'

'Kaštelir' = 'Kastelir'
1

Klopt, op onze live-server krijg ik wel resultaat, op de dev-server niet. Even uitzoeken welke instelling dit is (of als iemand me dit snel kan zeggen)?

[DexterDee]

Ik ben er al achter... Het ligt aan de MySQL client actieve karakterset

Voer deze query maar eens uit:

SQL:

SET NAMES 'latin1';
SELECT 'Kaštelir' =  'Kastelir'

'Kaštelir' = 'Kastelir'
0

Dat is dus anders als dit:

SQL:

SET NAMES 'utf8';
SELECT 'Kaštelir' =  'Kastelir'

'Kaštelir' = 'Kastelir'
1

[NMe]

Verwijderd schreef op donderdag 17 juni 2010 @ 15:32:
[...]

[...]

Klopt, op onze live-server krijg ik wel resultaat, op de dev-server niet. Even uitzoeken welke instelling dit is (of als iemand me dit snel kan zeggen)?

MySQL 5.0, utf8_general_ci als collatie op zowel database als tabel en MyISAM als storage engine. Da's alles dat relevant kan zijn volgens mij.

DexterDee schreef op donderdag 17 juni 2010 @ 15:34:
Ik ben er al achter... Het ligt aan de MySQL client actieve karakterset

Voer deze query maar eens uit:

SQL:

SET NAMES 'latin1';
SELECT 'Kaštelir' =  'Kastelir'

'Kaštelir' = 'Kastelir'
0

Dat is dus anders als dit:

SQL:

SET NAMES 'utf8';
SELECT 'Kaštelir' =  'Kastelir'

'Kaštelir' = 'Kastelir'
1

Mja, die set names is natuurlijk wel handig als je met UTF-8 werkt, ja.

[ Voor 38% gewijzigd door NMe op 17-06-2010 15:36 ]

[DexterDee]

Overigens kun je dit in de my.cnf aanpassen zodat clients default UTF8 pakken. Dan hoef je in je script niet elke keer een SET NAMES 'utf8' te doen, zonde van die extra query. Op de live server zal deze setting dus hoogstwaarschijnlijk verschillen van de dev server. Beter de configuratie gelijktrekken om dit soort problemen in de toekomst te voorkomen

[NMe]

DexterDee schreef op donderdag 17 juni 2010 @ 15:42:
Overigens kun je dit in de my.cnf aanpassen zodat clients default UTF8 pakken. Dan hoef je in je script niet elke keer een SET NAMES 'utf8' te doen, zonde van die extra query. Op de live server zal deze setting dus hoogstwaarschijnlijk verschillen van de dev server. Beter de configuratie gelijktrekken om dit soort problemen in de toekomst te voorkomen

Ik zou toch liever een "SET NAMES 'utf8'" draaien in je websiteinitialisatie. Ik ben niet graag settingafhankelijk. Dit soort dingen wordt gegarandeerd vergeten bij een eventuele websitemigratie.

[Verwijderd]

thx allemaal

[RobIII]

Het heeft dus te maken met de collation van je table / DB / connectie zoals inmiddels wel duidelijk was. Maar het zit 'm dan voornamelijk in het accent-sensitivity gedeelte van de gekozen collation. Kijk hier maar eens Alleen, voor zover ik begrijp ondersteunt MySQL enkel CI (case insensitivie) en dus geen expliciete AI (accent insensitivie). Die zal wel impliciet bij CI horen denk ik

[ Voor 5% gewijzigd door RobIII op 17-06-2010 16:28 ]

[NMe]

RobIII schreef op donderdag 17 juni 2010 @ 16:26:
Het heeft dus te maken met de collation van je table / DB / connectie zoals inmiddels wel duidelijk was. Maar het zit 'm dan voornamelijk in het accent-sensitivity gedeelte van de gekozen collation. Kijk hier maar eens Alleen, voor zover ik begrijp ondersteunt MySQL enkel CI (case insensitivie) en dus geen expliciete AI (accent insensitivie). Die zal wel impliciet bij CI horen denk ik

Nee, want het werkte ook bij een case sensitive collatie. Het hangt dus blijkbaar van de charset zelf af, wat ook de reden is dat Latin strikter is dan UTF-8, wat enigszins verrassend is in mijn ogen.

edit:

Hmm, toch niet:

quote: http://dev.mysql.com/doc/...charset-unicode-sets.html

For any Unicode character set, operations performed using the _general_ci collation are faster than those for the _unicode_ci collation. For example, comparisons for the utf8_general_ci collation are faster, but slightly less correct, than comparisons for utf8_unicode_ci. The reason for this is that utf8_unicode_ci supports mappings such as expansions; that is, when one character compares as equal to combinations of other characters. For example, in German and some other languages “ß” is equal to “ss”. utf8_unicode_ci also supports contractions and ignorable characters. utf8_general_ci is a legacy collation that does not support expansions, contractions, or ignorable characters. It can make only one-to-one comparisons between characters.

To further illustrate, the following equalities hold in both utf8_general_ci and utf8_unicode_ci (for the effect this has in comparisons or when doing searches, see Section 9.1.7.7, “Examples of the Effect of Collation”):

Ä = A
Ö = O
Ü = U

A difference between the collations is that this is true for utf8_general_ci:

ß = s

Whereas this is true for utf8_unicode_ci:

ß = ss

[ Voor 43% gewijzigd door NMe op 17-06-2010 17:13 ]