Napovídání při hledání

15.10.2006 16:58 | Přečteno: 1459× | Abíčko | poslední úprava: 16.10.2006 09:35

Kuriozně teď oznamuji něco, co vlastně nefunguje. Ale třeba mi to pomůžete rozchodit .

Na seznamu se mi líbi hledání ve slovníku. Zadám pár písmen a objeví se mi seznam možných výrazů. Vím, nápad pochází od google, ale ten to v praxi nepoužívá na svých hlavních stránkách. Chtěl jsem tedy napsat něco podobného.

Vytvořil jsem si tabulku se seznamem hledaných řetězců včetně počtu hledání a naplnil jsem ji z logů. Našel jsem knihovnu suggest, která za mně udělá JS hrátky. Napsal jsem si krátký servlet, který vrací data začínající stejným textem seřazená dle počtu hledání. Doma mi to funguje slušně (knihovna má pár chyb, například tlačítko za vstupním políčkem se posune na nový řádek nebo formulář nejde odeslat klávesou enter). To vše bych do beta provozu překousl, jenže na serveru to nejede. Každé hledání (i ascii textu) skončí chybou:

Illegal mix of collations (latin2_general_ci,IMPLICIT) and (utf8_ge neral_ci,COERCIBLE) for operation 'like'

Doma mi to nedělá, jen pro utf znaky v souborech s latin2 kodování. Na serveru mi to lítá pokaždé. Už bych to rád vyřešil, podobný problém bývá občas i ve variantách softwaru pro znaky s diakritikou. Zkoumal jsem pochopitelně dokumentaci k MySQL, ale nevyznám se v tom. Nějak nepočítají s nožností, že neporovnávám dvě tabulky, ale tabulku s příkazem přes JDBC ovladač.

Update: dostal jsem odpověď od autora Suggest, že jej přestal podporovat. Takže teď se musím rozhodnout, že buď jej zkusím opravit sám (nesnáším JS), nebo budu hledat jinou knihovnu. Je to pech, ta knihovnička je sympaticky malá a jednoduchá, narozdíl třeba od Yahoo UI Library.

       

Komentáře

[Filip Jirsák]

V MySQL se pokoušíš porovnat UTF-8 a Latin2 stringy. Jestli se nepletu, tak databáze Abíčka je v Latin2, ale v parametrech JDBC spojení je useUnicode=true, takže tam se řetězec pravděpodobně předává v UTF-8.

Problém bude zřejmě v tom, na jakém charset se server s JDBC ovladačem "dohodnou" - asi to není Latin2, ale UTF-8. Možná by pomohlo jako parametr JDBC URL nastavit characterEncoding=ISO8859_2.

[Leoš Literák]

Na tohle uz nemam moc odvahu. Prvni zkusenost s Mysql 4.1 byla tragicka, bez meho vedomi byl kdysi upgradovan mysql server na tuto radu a ja to rano resil, meli jsme i poskozeni dat. Pri prechodu na novy server jsem to nastesti neresil na zivem serveru, ale take mi to dalo zabrat a to jsem mel po ruce zalohy. Ted bych to musel opet menit nazivo a toho se moc bojim.

Ale jedna varianta tu je - napisu si do abicka rezim read-only pro udrzbu a kdyz jej zapnu, nikdo nebude moci vlozit nic noveho a tudiz obnovou zalohy nikdo neprijde o data. Jdu to napsat do bugzilly. Treba pristi vikend bude pokracovani.

[Filip Jirsák]

Aha, ono to s těmi parametry zas nebude tak jednoduché, tak snad takhle:

jdbc:mysql://…/devel?characterEncoding=ISO8859_2&mysqlEncoding=latin2

[Leoš Literák]

Az budu mit nekdy odvahu experimentovat, zde jsou nejake linky: mysql 4.1 a cestina minifaq

SHOW VARIABLES;
| character_set_client            | latin1                      |
| character_set_connection        | latin1                      |
| character_set_database          | latin2                      |
| character_set_results           | latin1                      |
| character_set_server            | utf8                        |
| character_set_system            | utf8                        |
| character_sets_dir              | /usr/share/mysql/charsets/  |
| collation_connection            | latin1_swedish_ci           |
| collation_database              | latin2_bin                  |
| collation_server                | utf8_general_ci             |
SHOW CHARACTER SET;

[hele]

nepisete jakou mate verze mysql 4.1.? ty prvotni meli s timhle dost potizi, ktere se vyresili az pozdeji, dalsi vec jak pise tu nekdo drive mit dobre nastaveno kodovani spojeni bud skrz set names latin2; ci set names utf8; apod. taky se presvedcit zda je v databazi opravdu utf8, ci je to utf8 placnute do latin2 kodovani. Pozna se to dle toho ze kdyz se tam pripojite a napisete set names utf8; leze utf8 spravne, a kdyz set names latin2 pak leze spravne latin2;

[Leoš Literák]

4.1.15

Jak je to vlastne s UTF v databazi a konzoli? Kdyz budu mit databazi v UTF a konzoli v latin2, budou se znaky v diakritice zobrazovat spravne? Nebo musi i konzole (shell) bezet v UTF?

[Věroš]

Když máš konzoli v UTF a nějaký program ti píše v ISO-8859-2, tak je to rozsypané.

Probatum est.

[Leoš Literák]

Spise obracene. Konzoli mam v Latin2, jak bude mysql vypisovat data, ktera ma interne ulozene v UTF?

[Ladicek]

Je třeba dát MySQL na vědomí, aby s vámi komunikovala v daném kódování. To vůbec nesouvisí s tím, v jakém kódování jsou data v databázi uložena. Asi nejsnazší je do /etc/mysql/my.cnf přidat něco jako

[client]
default-character-encoding=latin2

Jeden drobný háček zrovna tohoto řešení je: všechny klientské programy MySQL by měly načítat konfiguraci ze sekce client (kromě toho samozřejmě i ze sekce určené jenom pro ně, třeba pro řádkového klienta mysql je to sekce mysql) a když najdou volbu, kterou neznají, považovat to za chybu. A takový mysqlbinlog si zrovna s default-character-encoding neporadí Více třeba na http://dev.mysql.com/doc/refman/4.1/en/charset-connection.html.

[Ladicek]

Nebo samozřejmě jde, jak napsáno výše, použít (zdráhám se tvrdit, že SQL) příkaz set names latin2, ten dělá totéž. Pro aktuální spojení.

[Ladicek]

Jsem pako, odkazuju na dokumentaci a sám to napíšu blbě. Má pochopitelně být default-character-set=latin2…

[Josef Kufner]

Základem úspěchu je mít všude stejné kódování. Jak v tabulkách, tak dotazech, tak kódu okolo. Jakmile je někde něco jiného, tak jsou s tím jen problémy.

Překlop celé Abíčko i všechno s ním související do UTF-8 a budeš to mít navždy vyřešené

Převod dat v MySQL je jen o exportu, přenastavení kódování v databázi a importu zpět. A to jak tabulky, tak data &bdash; vymažeš celou DB, nastavíš ji na UTF8 a při importu tohle nastavení všecko zdědí. Ve zbytku už by to neměl být problém. Ještě to chce vyházet veškeré zmínky o kódování v CREATE dotazech.

[Leoš Literák]

Pri prvni instalaci na 4.1 jsem zkousel nastavit UTF a nefungovalo mi to. Tak jsem uz vice neexperimentoval a nehledal, kde je chyba. Zdrojaky abicka jsou k dispozici, treba nekdo doma rozjedete abicko plne v UTF a pak mi napisete, jak to udelat spravne. Ja mezitim napisu prepinani abicka do read-only modu.

[panda]

Ahoj v MySql musi byt oba porovnavane retezce ve stejnem kodovani, pokud nejsou tak se da explicitne pretipovat pomoci _JMENOKODOVANI pred retezcem. Takze kdyz porovnavas UTF8 a latin2 tak staci pretipovat retezec v latin2 na UTF8. Vic manual MySQL http://dev.mysql.com/doc/refman/4.1/en/charset-collation-charset.html

Jinak predelat DB do UTF8 je vic nez dobry napad, uz jen kvuli tomu, ze MySql opravdu spravne cesky radi, jen pro UTF8 (o fulltextovem prohledav ani nemluvim )

[trekker.dk]

Zrovna dneska jsem něco podobnýho potřeboval - věděl jsem, co hledám, ale nevěděl jsem, jak to najít. I když takhle asi ta nápověda fungovat nebude, co?

[Věroš]

Nehledáš Autocompleter na script.aculo.us?

--Věroš

[Yin]

No ja a JS sme celkom kamarati (vie to byt rozumny jazyk, ak mu clovek rozumie do hlbky). Teoreticky by som sa na ten Suggest mohol pozriet zo zabavy, ale az si splnim iste povinnosti ;)