Dotaz: Oracle a UTF-8

[camel1cz]

Zdravím,

mám takový problém - vyvíjíme webovou aplikaci používající Oracle DB a celá aplikace je v UTF-8. Rovněž databázové kódování tedy používáme UTF-8. Dnes ale zákazník prohlásil, že máme používat "standardní" Oracle EEMSWIN-1250 kódování a že UTF-8 může a bude činit problémy i do budoucna.

Můžete se k tomuto někdo, kdo rozumíte Oracle vyjádřit? Je fakt nějaký problém používat Oracle s UTF-8? Dělá mi to dost problém - překládát aplikaci nechci.

Díky moc!

Odpovědi

[Tomáš]

Nejsem si 100% jist, ale myslím že Oracle DB (9,10,11) interně ukládá veškeré znaky jako UTF-16. A tady koukám , že se to dá snad i zvolit. V rámci připojení klientem si pak můžete zvolit v jakém kódování budete se serverem komunikovat. Tj klient komunikuje přes cp1250 a na serveru je uloženo jako UTF-16. Detaily třeba tady a tady.

[camel1cz]

Ano, žiju v podobném přesvědčení.

Fakt mi není jasné, proč jim dělá problém spustit SQL skript v UTF-8 nad jejich databází ve win1250. Uniká mi něco? Pochybuju, že mají Oracle, co neumí UTF-8, tak v čem mají problém? Napadá mě jen možnost chyb při překladu z UTF-8 do win1250 (neexistující ekvivalenty znaků).

Správně by měly vytvořit novou DB v unicode... ale to by si raději ukousli ruku :-/

[dustin]

Možná, kdybys tu o svém klientovi mluvil trochu uctivěji, mohl jsi jim ukázat tuto diskusi, argumenty zkušených a třeba by je to přesvědčilo, aby něco udělali jinak.

[camel1cz]

Uctivěji? ...to je holá realita - bohužel. Ukazovat jim to nebudu ne kvůli svému postu, ale proto, že mají své standardy a i kdybych měl 100 důvodů k jejich změně - stejně to tak nedopadne. Hledal sem jen argumenty k tomu, že sem nemohl předvídat, že UTF-8 bude problém (trochu alibi a trochu upevnění iluze vlastní bezchybnosti

FYI: vypadá to, že zaplatí překlad do win1250

[Ivan]

Jediny kodovani, ktery kdo delalo na Oracle problemy bylo EEMSWIN-1250. A to v pripade kdy server bezel na Unixu a chtel vyplivnout nejakou chybovou hlasku. Oracle rozlisuje vice druhu kodovani. Vnitrni, tzn. to kodovani ve kterem jsou data skutecne ulozena to muze byt ISO-LATIN(1/2) nebo UTF8. Druhy vnitrni kodovani je pro dat. typy zacinajici na "N" - NCHAR, NCLOB atd. Kdyz to zjednodusim, tak NCHAR je vzdy UTF16.

Pak je dokovani na strane klienta, Oracle ti poskytne data jakymkoliv kodovani i jaky si reknes. Taky ti bude tridit data podle libovolny abecedy - kdyz si o to reknes. Tohle plati pro OCI. Pripade ze se pripojuses z Javy pres JDBC, tak dostanes data vzdy v UTF16.

Pokud nekdo vyzaduje EEMSWIN-1250, tak nejspis spravuje jednu databazi bezici na woknach a asi nidky nevidel velkou DB bezici na Unixu.

Lokalizace na strane klienta se nastavuje nejcasteji pomoci env. promennych. Jejich jmena zacinaji NLS_.(NLS_LANG). U kodovani UTF8 je v Oracle trochu podpasovka, protoze prvni implementace byla "nekompletni" a tak prisel s "druhou" implementaci nazvanou AL32UTF8. Nastav si do environmentu NLS_LANG=CZECH_CZECH REPUBLIC.AL32UTF8 NLS_SORT=CZECH /nebo XCZECH.

[camel1cz]

Díky za vysvětlení... dává to smysl.

Oni (asi) jedou na Win a mají standard win1250 - nejdřív sem myslel, že mají nastavené fyzické ukládání dat ve win1250 (a celkem oprávněně očekávají problémy při ukládání UTF8 a znaků, které nemají obraz v 1250) - ale když píšete, že oracle umí jen ISO nebo UTF... tak sem z toho jelen - oni snad jedou fyzicky na ISO a ven preferují 1250 - no nechápu to...

Každopádně to vypadá, že aplikaci budu časem překládat do 1250 :-/

[Arnošt Málek]

Přesně jak píše Ivan, nastav si NLS a můžeš klidně spustit sql v takovém kódování, v jakém nastavíš. Pouštím běžně sql skripty na Win a Lin, přičemž na Win je kódování 1250, na lin 8859-2 ... a když chci pustit stejný soubor, tak ho nalinuxu buď překóduju, nebo bastavím NLS a je to. O změnu češtiny se postrará klient oracle.

[kuka]

Klienti mohou k Oracle databazi pristupovat v kodovani de facto jakem chteji, pokud to databze zvladne. Jina vec je interni kodovani databaze - napriklad do databaze s internim kodovanim 1250 nelze spravne ulozit znaky, ktere v nem neexistuji (lze pripadne jako NVARCHAR, ale to jsem zatim videl zcela minimalne, proc mit dva druhy retezcu a hlidat, zda se pouzivaji spravne). Z hlediska vykonu muze byt podstatne jedno/dvoubajtove kodovani, to ma vliv na objem dat, rychlost nekterych operaci (substr) apod - jde ale o detailni technikalie, ktere lze v naproste vetsine nasazeni ignorovat a pouzivat UTF-8.

Podle mne je to naopak, nez si mysli tvuj zakaznik. Dnes mu mozna staci jednobajtove kodovani 1250, nicmene toto omezeni mu muze pusobit potize do budoucna. Napr. rozsiri business do zahranici nebo bude integrovat datove zdoje v UTF (treba adresy), napr. specialni nemecka pismena maji vzdy prepis do latin1, ale kdo to realne pouziva?