[MYSQL] e = é, Mysql maakt geen onderscheid

[Verwijderd]

Hallo,

alweer een post hier vandaag, bleh, alles zit ook tegen
Ik heb een zoekquery op mijn website, deze zoekt in mijn mysql database (utf8_general_ci), en nu is het probleem, dat mysql geen onderscheid maakt tussen een "e" en een "é", SELECT 'e' = 'é' geeft zelfs true terug. Is dit een bekend probleem van mysql of doe ik wat fout? Is dit op te lossen d.m.v. een database instelling of een aanpassing aan mijn query, of is het gewoon niet te verhelpen hierdoor.
Ik kan het wel verhelpen door zelf een script te maken in mijn zoekpagina, maar dan zou ik nogmaals alle zoekresultaten moeten doorlopen en dit vind ik geen nette oplossing aangezien ik mysql vraag gewoon de juiste records te geven

owjah, is ook leuk zoeken op GoT, hoe omschrijf je dit probleem

[Mr. Bondt]

Opslaan als HTML entities?
Of gewoon zo laten, natuurlijk!
Zo krijg je de meeste resultaten, en de mensen hoeven dan niet per se é in te toetsen

[kenneth]

Binary searches doen?

SQL:

SELECT BINARY 'e' = 'é' 

geeft false.

[Verwijderd]

In MS_SQL server moet je even checken of de collation goed staat (volgens jou), daarin geef je onder andere op of je case-sensitive en/of accent-senetive wil. Ik kan me voorstellen dat in MySQL het ook zo iets moet zijn:

utf8_general_ci -> utf8_general_ci_as

[ Voor 11% gewijzigd door Verwijderd op 13-02-2006 17:01 ]

[Verwijderd]

kenneth schreef op maandag 13 februari 2006 @ 16:49:
Binary searches doen?

SQL:

SELECT BINARY 'e' = 'é' 

geeft false.

Thnx, dr gaat een wereld voor me open met mysql nu haha, ik neem aan dat die BINARY alles op binair niveau vergelijkt, maarja, achtergrond maakt niet uit, het werkt in ieder geval. Scheeld weer wat load, was toch best grote query met 30.000 results

Verwijderd schreef op maandag 13 februari 2006 @ 16:55:
In MS_SQL server moet je even checken of de collation goed staat (volgens jou), daarin geef je onder andere op of je case-sensitive en/of accent-senetive wil. Ik kan me voorstellen dat in MySQL het ook zo iets moet zijn

Dat over collation klopt, maar case-sensitive is in MySql zo niets te vinden dacht ik, de collation kan je zelfs tot op kolom niveau instellen

[ Voor 37% gewijzigd door Verwijderd op 13-02-2006 16:57 ]

[Verwijderd]

utf8_general_ci -> utf8_general_ci_as

sorry, was even in de war

cs/ci : case
as/ai : accent

[Verwijderd]

Verwijderd schreef op maandag 13 februari 2006 @ 16:59:
utf8_general_ci -> utf8_general_ci_as

sorry, was even in de war

cs/ci : case
as/ai : accent

De cs/as/ai mogelijkheden kan ik niet selecteren bij de instellingen van mijn database, omdat ze er niet tussen staan. Alleen ci collatie typ'e staan ertussen

[Verwijderd]

Verwijderd schreef op maandag 13 februari 2006 @ 17:25:
[...]


De cs/as/ai mogelijkheden kan ik niet selecteren bij de instellingen van mijn database, omdat ze er niet tussen staan. Alleen ci collatie typ'e staan ertussen

Ik lees inderdaad net op een forum, dat de mensen achter mysql (http://forums.mysql.com/read.php?103,22014) het blijkbaar niet zo belangrijk vinden...

Ik weet dat mysql niet zo uitgebreid is, maar dit is gewoon slecht. Toch maar eens gaan kijken naar postgres, wellicht dat die wel fatsoenlijk in elkaar steekt.

In de forums waarover mensen klagen over het accent-insensitive gedrag, kun je trouwens ook lezen dat een binaire collation blijkbaar ook geen goed idee is in verband met het ORDER BY statement

[ Voor 15% gewijzigd door Verwijderd op 13-02-2006 17:33 ]

[Gwaihir]

Hmm.. ik zit hier met het omgekeerde probleem: als ik zoek met LIKE 'o', dan komt 'ö' niet mee bij de gevonden records, wat ik wel graag zou zien.

[Verwijderd]

Birdie schreef op maandag 13 februari 2006 @ 19:58:
Hmm.. ik zit hier met het omgekeerde probleem: als ik zoek met LIKE 'o', dan komt 'ö' niet mee bij de gevonden records, wat ik wel graag zou zien.

Met MySQL of een andere database?

[Gwaihir]

MySQL 4.1, tabellen in latin_1.

Nog niet bewust instellingen hiervoor gezocht; mijn geval zal waarschijnlijk wel makkelijk te veranderen zijn, als ik bovenstaande zo lees.

Edit: latin1_swedish_ci om precies te zijn. Zit hier te neuzen door een tamelijk oude phpMyAdmin. Die houdt zich er verder in elk geval NIET mee bezig (ik kan tekenset kiezen, maar geen ci/cs, etc.)

Edit 2: Afijn die forum post is 9 maand oud nu.. geen idee of ze 't gefixd hebben of al op hun "TODO" gezet, maar ik kwam wel dit commando tegen: http://dev.mysql.com/doc/refman/4.1/en/show-collation.html . Verteld je precies wat er op dit moment in je db beschikbaar is.

Edit 3: En dat geeft een keurig lijstje met NUL info over de accent-gevoeligheid. 'e' en 'é' ziet hij in latin_1_swedish_ci dus ook als identiek, maar 'o' en 'ö' niet. Zou toch op z'n minst handig zijn als deze merkwaardigheden ergens gedocumenteerd zijn, maar ik heb 't nog niet gevonden.

[ Voor 100% gewijzigd door Gwaihir op 13-02-2006 21:46 ]

[Verwijderd]

Wel apart dat het dus niet helemaal accent insensitive is, nogal verwarrend. Heeft iemand hier enig idee of dit in postgres wel goed geregeld is?

[MSalters]

Net op het werk weer mee lopen stoeien. In Unicode (en dus in alle UTF-x varianten) is ö representeerbaar als o+" (Combining diacriticals, U+0301 en verder). De string "ö" bevat dan dus wel degelijk de 'substring' "o" ! Nu is er dus ook een precombined ö, wat een enkel karakter is, dus je kunt niet simpel zeggen of ö en o matchen. Unicode definieert behoorlijk ingewikkelde regels.

Gelukkig is het in jouw geval redelijk makkelijk. Je wilt het bij een search gebruiken? In dat geval sla je alle keywords op, zowel in de originele vorm, normalized als ook ontdaan van diacrieten. (in totaal dus 3 vormen). Bij een search probeer je eerst de originele vorm (copy-paste searches vinden dan altijd het orgineel), vervolgens de normalized form (vindt ook het origineel, soms wat meer) en tenslotte de gestripte versie (vindt een heleboel, voor onderaan de resultaten).

[MSalters]

"Accent insensitive" werkt niet, omdat je de zaak te ver simplificeert. ñ is geen accent, tenminste niet volgens de Spanjaarden. æ is geen accent, maar wel gelijk aan ae in het Deens. Ik beschrijf dit soort benaderingen zelf altijd als het "it's almost English" syndroom.

De Unicode site is verassend goed en informatief. Ik meen me te herinneren dat ze zelfs ergens het IJmuiden probleem goed uitleggen.

[ Voor 22% gewijzigd door MSalters op 14-02-2006 00:22 ]

[Verwijderd]

Het rare is, eerst was mijn query NIET case sensitive, nu heb ik de query in een stored procedure gezet (zoals te lezen in [rml][ Mysql 5.0.18] Stored procedure, delimiter probleem?[/rml]) en nu is hij plots WEL case sensitive, hoezo willekeurig bezig zijn van mysql

edit:

Mijn conclusie was te voorbarig, dit komt door de BINARY oplossing die ik gebruik.... het ligt dus niet aan MySql maar aan mijn query Waarom kan t nu nooit eens meewerken haha

[ Voor 26% gewijzigd door Verwijderd op 14-02-2006 11:50 . Reden: typo ]

[Verwijderd]

MSalters schreef op dinsdag 14 februari 2006 @ 00:21:
"Accent insensitive" werkt niet, omdat je de zaak te ver simplificeert. ñ is geen accent, tenminste niet volgens de Spanjaarden. æ is geen accent, maar wel gelijk aan ae in het Deens. Ik beschrijf dit soort benaderingen zelf altijd als het "it's almost English" syndroom.

De Unicode site is verassend goed en informatief. Ik meen me te herinneren dat ze zelfs ergens het IJmuiden probleem goed uitleggen.

Hoewel de ~ wellicht geen accent is in Spaans en Portugees, weet ik dat veel mensen hier (= Brazilië) als ze willen zoeken op iets dat eindigd op "ção" dat ze het gewoon als "cao" schrijven in google en dat geld ook voor de rest van de accenten e.d. Dat hoeft overigens niet, want google negeert blijkbaar alle frutsels zoals tildes,accenten en de rest van het priegelwerk.
Hier op mijn werk willen ze de algemene zoekvelden ook altijd zo hebben, zodat het niet uitmaakt of je met of zonder frutsels schrijft. Het spul staat echter wel netjes geschreven in de database omdat de accenten van belang zijn voor de betekenis.

Overigens staat de boel bij op Accent Sensitive (MS-SQL Server)

Ik ga die Unicode site maar eens bekijken, dat klinkt best wel interessant!

[MSalters]

Eh - ik was vrij voorzichtig met de term "Spanjaarden" en ñ want voor zover ik weet is de ~ in ã in het Portugees wel een diacriet. Maar in jouw geval heb je dus gelukkig een simpel zoekmodel. Normaliseer alles naar Normalization Form NFD (zie Unicode TR15) en gooi alle combining diacriticals eruit, klaar.

[ Voor 3% gewijzigd door MSalters op 14-02-2006 23:31 ]

[Gwaihir]

MSalters schreef op dinsdag 14 februari 2006 @ 00:17:
Nu is er dus ook een precombined ö, wat een enkel karakter is, dus je kunt niet simpel zeggen of ö en o matchen. Unicode definieert behoorlijk ingewikkelde regels.

Latin_1 heeft dus kennelijk een ö als losse letter (geen accent), volgens MySQL's default collation althans. Maar waar vind je de specs voor zoiets - in mijn geval dus voor latin1? Bedoel je met "de unicode site" www.unicode.org? (MySQL biedt nog een aantal collations voor latin1, maar die zijn niet compiled in op mijn server. Even uitproberen is er dus niet bij, doch als het mijn probleem oplost, dan is het wel zelf compileren waard.)

[ Voor 23% gewijzigd door Gwaihir op 15-02-2006 10:01 ]

[MSalters]

Ja, dat is inderdaad de unicode site. De precombined ö is inderdaad Latin1. (Latin-1 is een single-byte encoding en heeft dus geen combining diacriticals - dat zou 2 bytes kosten, letter+accent) "Precombined" betekent overigens dat er geen los accent volgt, maar er staat natuurlijk wel een accent op.

Specs voor Latin1 zijn ISO8859-1. Dat is makkelijk genoeg te vinden, helemaal als je weet dat het samenvalt met U+0080 tot U+0100. Het staat dus ook op de Unicode site.

Collation is overigens iets anders als substring matching, maar gaat over sorteren. Dan heb je natuurlijk ook de vraag of 'o' en 'ö' samen sorteren (antwoord: hangt van de taal af, en in het Duits heb je bovendien telefoonboek- en woordenboekvolgorde) maar is net een andere vraag.

[ Voor 11% gewijzigd door MSalters op 16-02-2006 00:23 ]