Egy érdekes problémába futottam, leszűkítettem amennyire tudtam, a végeredményt írom, amire nem tudok magyarázatot.
select search_betu,lower(title) from lexikon WHERE LOWER(lexikon.title) REGEXP '^ő'; --megtalálja az űrsíklót.
pl.:
+-------------+-------------------------------------------------------------------------------------------------------------------+
| search_betu | lower(title) |
+-------------+-------------------------------------------------------------------------------------------------------------------+
...
| o | őszibarackfa |
| o | ősz |
| u | űrsikló (space shuttle) |
| o | őszapó |
...
+-------------+-------------------------------------------------------------------------------------------------------------------+
select search_betu,lower(title) from lexikon WHERE LOWER(lexikon.title) REGEXP '^ű'; --ez csak az ű söket találja mEG!!!
+-------------+---------------------------+
| search_betu | lower(title) |
+-------------+---------------------------+
| u | űrbél |
| u | űrlap |
| u | űrsikló (space shuttle) |
+-------------+---------------------------+
tehát: az ő -re megtalálja az ű-t, de fordítva nem!!!!!!!!!
Tisztában vagyok vele, hogy a mysql regexp byteokon működik:
Warning
The REGEXP and RLIKE operators work in byte-wise fashion, so they are not multi-byte safe and may produce unexpected results with multi-byte character sets. In addition, these operators compare characters by their byte values and accented characters may not compare as equal even if a given collation treats them as equal.
De itt nem ez a probléma, [ő] esetén lehetne mondjuk, mert 2 byteos.
A title oszlop, és maga a table is utf-8 hungarian_ci collation.
Konstansra jó minden kombináció:
mysql> select 'űrsikló (space shuttle)' regexp '^ő';
+------------------------------------------+
| 'űrsikló (space shuttle)' regexp '^ő' |
+------------------------------------------+
| 0 |
+------------------------------------------+
1 row in set (0.00 sec)
minden utf-8, a konzol, a mysql kliens kódolása, a szerver default kódolása...
Gentoo mysql:
[ebuild R ] dev-db/mysql-5.1.56 USE="cluster community ssl -big-tables -debug -embedded -extraengine -latin1 -max-idx-128 -minimal -pbxt -perl -profiling (-selinux) -static -test -xtradb" 0 kB
--------------------------------------------
szerk: utf8_general_ci esetén a hiba nem jelentkezik! találomra pl. utf8_lithuanian_ci nél is hibás :D
- 2229 megtekintés
Hozzászólások
"utf8_general_ci esetén a hiba nem jelentkezik!"
Csak megerősíteni tudom.
Megkérdezhetem hogy minek erőlködsz ezzel az "utf8_hungarian_ci"-vel?
Vagy csak nagyon ráérsz.
Tudok átadni munkát, nekem van bőven. :)
- A hozzászóláshoz be kell jelentkezni
Az order by ra is szükségem van, és ez kell a helyes magyar rendezéshez. Más baj is van vele?
Mindig minden hungarian_ci, ami utf-8, mert magyar szövegeket tárolok. Nem unalmamban próbáltam ki ezt az "extrém" kombinációt :D
- A hozzászóláshoz be kell jelentkezni
Elvileg query-szinten is tudod allitani a collationt. Szoval megnezed, hogy rendezett vagy regexpes lekerdezest csinalsz-e tobbet, a masiknal meg megadod azt, amit szeret.
--
Always remember you’re unique, just like everyone else.
- A hozzászóláshoz be kell jelentkezni
vagy vard meg azt a mysql verziot ahol utf8_hungarian2_ci (vagy mi) lesz, elvileg az jobb leszesz őű kezelésben, de sorsat nem ismerem; vagy utf8_general_*, mint mondták előttem is.
- A hozzászóláshoz be kell jelentkezni
Ha general_ci-vel működik, akkor próbáld meg:
REGEXP '^ő' COLLATE utf8_general_ci
- A hozzászóláshoz be kell jelentkezni
Valóban, ez segített, így megmaradt az oszlop hungarian collationje a rendezéshez, ebben az esetben meg general a helyes lekérdezéshez.
Azon viszont ez nem változtat, hogy ez egy bug szerintem... Pláne, hogy oda-vissza máshogy működik! Ez nem lokál hiányosság, hanem konkrét bug szvsz. Ha lesz időm még jobban letisztítom, és egy példával (ha máshol is elő tudom idézni) beküldöm bug reportba.
- A hozzászóláshoz be kell jelentkezni