Dotaz: enca a CP1250

[BillyThePilgrim]

Zdravim vsechny, zvlaste pak Yetiho (dotaz bude asi spis na nej

Mam mensi problem s jednim programkem jmenem "enca". Jde o to, ze mi nejak odmita rozpoznat cokoliv, co je kodovano v CP-1250. Chtel jsem ho pouzit na prekodovani nazvu nekolika souboru, ale uspel jsem jenom castecne (cca 50%).

Jednak nerozpoznal cokoliv v CP1250 (Unknown encoding, pri pokusu o enconv to hodi chybu: Cannot convert 'STDIN' from unknown encoding) a jednak u nekterych veci v ISO 8859-2 se mi snazil vnutit nejake pomerne jine (spatne) kodovani.

Divne na tom je hlavne to, ze treba iconv zminene texty v CP1250 prevede na ISO vcelku bez problemu.

Do zdrojaku enca jsem se nedival, ale docela by me zajimalo, odkud enca bere "vstupni" kodovani.

Dalsi info o systemu:
verze enca: puvodne 1.5 (gentoo), ted i 1.6
system: gentoo, 2.6.10-gentoo-r4, v jadre NLS jak CP-1250, tak ISO a UTF
locales:LC_ALL i LANG = cs_CZ (manualne udelane pomoci localedef -i cs_CZ -f ISO-8859-2 cs_CZ)
font konzole: setfont "lat2-16" Predem dik za kazdy novy napad, ty moje uz mi dosly

Odpovědi

[unchallenger]

Zavěs někam testovací soubor. Nebo mi ho pošli mailem. No, ale když už jsi začal ve fóru, tak pokračujme zde...

[BillyThePilgrim@seznam.cz]

http://jaja.kn.vutbr.cz/~hnilica2/CP1250.txt

Tohle je vystup z konstrukce ve stylu find ... -exec ... "... echo $name | enca" > file Ty soubory s diakritikou maji nazvy normalne v CP1250 Jeste na doplneni - nehledej chybu v ence. Na notebooku mi to jede normalne. Na co ale nemuzu prijit je to, kde je chyba. locale je stejny (cs_CZ s ISO8859-2), v kernelu sou zakompilovany stejny NLS, neni to zadna FATka (ty soubory sou normalne na ext3) aby tam mohla byt chyba v iocharset. Proto by me zajimalo podle ceho enca zjistuje to kodovani...

[Tomáš Hála]

Ty "ť" ve slově křesťan nevypadají zrovna na CP1250..

[BillyThePilgrim]

Jo, to je mozny... netvrdim, ze je to vsechno 100% CP1250... neco asi neni... ale jde mi o to, ze to nerozpoznalo ani to, co CP1250 je 100% (BTW nepoustel sem to na celej soubor, ale na jednotlivy polozky)

[unchallenger]

Tři věci.

1. Detekční chování enca by mělo záviset na locale jen do té míry, že určuje defaultní jazyk a výstupní kódování, tudíž s explicitním optionem -L (případně -x) by nemělo záviset vůbec na ničem kromě vstupního textu. (Konverze naopak závisí úplně na všem ;-) Závisí-li, je to samo o sobě bug, ať už závisí jakkoli, a prosím v tom případě o detaily. Zkusil bych ještě find ... >soubor, přenést soubor a porovnat.

2. Zdá se, že se snažíš detekovat kódování jmen jednotlivých skladeb. To moc dobře nefunguje, protože jsou velmi krátké a obsahují jen velmi málo písmen s diakritikou, takže statistické metody v enca nedávají spolehlivé výsledky.

3. Řádek ./Robert Křesťan a Druhá Tráva/Disk 2/03 - Vrs<9d> se.mp3 zjevně obsahuje ť ve dvou různých kódováních zároveň, tudíž není v žádném konkrétním kódování.

[unchallenger]

Tady je vidět, jak může špatná čeština úplně změnit smysl věty:

s/protože jsou velmi krátké/protože jsou velmi krátká/

(tj. jména skladeb, ne skladby).

[unchallenger]

Dneska mi ty formulace opravdu nejdou... Řádek samozřejmě neobsahuje ť ve dvou různých kódováních zároveň (jak by to asi vypadalo?), ale jednoduše obsahuje ť ve dvou různých kódováních.

[BillyThePilgrim@seznam.cz]

Ok, dik za odpoved... Zkusim to jeste porovnat s tim druhym kompem... napadlo me totiz, ze s nazvama adresaru na tom kompu kde mi to nejede jsem si uz predtim trochu hral (ISO <-> UTF), takze mozna by mohla byt zrada trochu v tom... Taky ty nemam uplne to samo na obou kompech (na tom kde to jede je jenom vyber - tzn. proto mozna ten rozdil v uspesnosti (cca 95% x cca 50%)). Zkusim to jeste projit trochu lip a jeste se ozvu (ale asi az behem zitrka)...
Kazdopadne pokud ses vyznavacem "free beer" licence, mas u me pivo Vzhledem k tomu, ze ses z MUNI, tak nekdy dej vedet, k nam na koleje do Alterny to mas kousek