Povzdech: Znaky s diakritikou v souborech v roce 2016

24.7.2016 13:08

Dnes jsem asi 2 hodiny zápasil s kompilací LLVM ze SVN, vždycky chyba při spuštění cmake. Nakonec jsem si všiml hlášky selhání příkazu svn info, že nemůže zkonvertovat cestu z nativního kódování do UTF-8 (které jsou mimochodem stejné). Samozřejmě jsem to spouštěl v adresáři "Stažené". Přesunul jsem jinam a najednou to funguje. Ach ty dnešní build systémy.        

Komentáře

[Ondrej Santiago Zajicek]

No, tohle je casto dusledek toho, ze nektere jazyky ci programy se snazi byt prilis chytre co se tyce kodovani a jmen souboru. Misto toho, aby je proste braly jen jako retezec bytu (a snazily se je konvertovat jen v pripade, kdy je to treba[*]), tak apriori jmena konvertuji do/z interni reprezentace na vstupu/vystupu. Takovy postup je nachylny na selhani (napr. kdyz je program spusten pod rootem a ma tedy typicky locale C, nebo kdyz pracuje se soubory jineho uzivatele, ktery pouziva jine kodovani).

[*] Pravda, build system casto pouziva ruzne substituce na jmenech souboru, tam to potreba byt muze.

[Bystroushaak]

Tohle je věčná bolest pythonu. Bylo by hezké, kdyby se to dalo nějak vypnout.

[chrono]

Ak nepotrebuješ s názvom pracovať ako s reťazcom, tak nebudeš mať problém ani v Python2 a ani v Python3 (inak logicky nemôžeš brať ten názov ako pole bajtov, pretože by nebolo zrejmé, ako sa to má napr. zobraziť).

[Jendа]

Jenže název nemůžeš brát jako pole bajtů, protože pak vznikají problémy s normalizací (jak už se píše níže).

[ST]

+1000

[R]

Vidim, ze Linux sa konecne dostava na uroven Windows...

[Tomáš]

Jak se kdysi zdálo, že UTF8 vyřeší problémy se zápisem jazyků jiných, než angličtina (jak obsah souboru, tak název/cesta souboru), tak se ukazuje, že to zase je těsně vedle.

Je několik způsobů, jak v UTF-8 zapsat například české znaky (myšleno posloupnost bytů). Takže pokud různé operační systémy a jejich filesystémy používají různý způsob (což používají), je na problém zaděláno. Pak si člověk rve vlasy nad tím, proč to tenhle soubor nenašlo, porovnává zadanou a skutečnou cestu a pořád nemůže na nic přijít.

Takže jsem se od květnatých českych názvů souborů zase vrátil ke kvetnatym_ceskym.

[Filip Jirsák]

Pro převod textu Unicode do kanonického tvaru existují jasná pravidla. Pokud nějaký program porovnává texty a ten převod neprovede, je to chyba toho programu.

[Ondrej Santiago Zajicek]

Otazka je, ktera vrstva by mela resit normalizace / prevod do kanonickeho tvaru:

1) low-level (uvnitr implementace file syscallu, tedy v jadre)

2) v programu

3) v uzivatelske I/O vrstve (tedy v terminalu / widget knihovne)

Varianty 1) i 2) jsou z ruznych duvodu v Linuxu nepouzitelne. Takze zbyva varianta 3), Ta by v zasade davala smysl a vicemene by fungovala, ale stale by zde byly problemy pri komunikaci s vnejsim svetem ci pri praci se soubory s nekanonickym jmenem. A navic existuje nekolik normalnich forem a nevim o tom, ze by bylo nekde specifikovano, ktera z nich je 'nejkanonictejsi'. Takze ruzne skupiny aplikaci by mohly byt nekompatibilni mezi sebou, nebot by pouzivaly jinou kanonickou formu.

[Filip Jirsák]

Původní problém byl, že ta aplikace sama neuměla porovnat dva názvy souborů. Je úplně jedno, kterou normalizaci by ta aplikace použila, úplně stačí, aby na oba názvy použila tu stejnou. Což se u jedné aplikace dá předpokládat a snadno zařídit. Problém by tedy byl jedině v případě, že by si dvě aplikace předávaly název souboru, a pak by se vstupem ta aplikace měla pracovat jako s jakýmkoli jiným vstupem názvu souboru a provést svou normalizaci. Problém by měla s tím, jak se od toho normalizovaného názvu dostat k nenormalizovanému názvu souboru na disku, což je ještě okořeněné tím, že že by teoreticky mohlo být na disku více různých souborů vedoucích na stejný normalizovaný název. Což by hrozilo spíš bezpečnostním průšvihem, než že by takové soubory někdo normálně vyrobil.

A jinak u názvů souborů snad nemá smysl dělat jinou normalizaci než Normalization Form Compatibility Composition, ne?

[Ondrej Santiago Zajicek]

Původní problém byl, že ta aplikace sama neuměla porovnat dva názvy souborů.

Nemyslim. IMHO puvodni problem byl v tom, ze uzivatel zadal do programu jmeno souboru, program to jmeno predal operacnimu systemu a OS ten soubor nenasel, protoze byl na FS v jine variante (nenormalizovan, s jinou normalizaci). Tedy porovnavani neprovadel program, ale OS, a ten se (v pripade Linuxu) o kodovani nestara, pro nej to jsou posloupnosti bytu.

což je ještě okořeněné tím, že že by teoreticky mohlo být na disku více různých souborů vedoucích na stejný normalizovaný název. Což by hrozilo spíš bezpečnostním průšvihem, než že by takové soubory někdo normálně vyrobil.

To se klidne muze stat, i kdyz to . Podobne jako pripady, kdy jsou na disku soubory se jmeny, ktere nejsou validni UTF-8 sekvence. Nebo treba jmena souboru obsahujici ridici znaky (< 32). Rozumny software by se s takovymi pripady mel rozumne vyrovnat.

A jinak u názvů souborů snad nemá smysl dělat jinou normalizaci než Normalization Form Compatibility Composition, ne?

V Linuxu asi jo, nicmene treba OS X udajne pouziva NFD.

[Jendа]

OS X udajne pouziva NFD

To by mohlo vysvětlovat, že Safari z OS X posílá v HTTP požadavcích dekomponované znaky a Apache si to neumí normalizovat, takže to pak nefunguje.

[Sten]

V jakém případě? HTTP nemá s NFD v souborovém systému moc společného, Safari s cestou v URL pracuje jako s textovým řetězcem a vůbec ji neinterpretuje. Nemá tak problém používat v cestách třeba i ve Windows-1252.

[Ondrej Santiago Zajicek]

Hadam, ze problem by mohl byt v pripade, kdy uzivatel zada URL s diakritikou do URL radku. Prohlizec vezme znaky od uzivatele, zakoduje je do utf-8 (NFC ci NFD) a pak je zakoduje do ASCII pomoci %XX notace. Takze vzniknou ruzna URL podle toho, jaka normalizace se pouzila.

[Filip Jirsák]

Proč by prohlížeč prováděl normalizaci? Od uživatele dostal posloupnost znaků v Unicode, takže je stačí zakódovat do UTF-8 a takto vzniklou posloupnost bajtů následně zakódovat pro URL. Klidně mohou existovat dvě různá URL https://www.example.com/%C3%81 a https://www.example.com/A%CC%81 s různým obsahem.

[Ondrej Santiago Zajicek]

Proč by prohlížeč prováděl normalizaci? Od uživatele dostal posloupnost znaků v Unicode

Uzivatel nezadal posloupnost znaku v Unicode, uzivatel stiskl fyzicke klavesy na klavesnici. Na jakou posloupnost znaku v Unicode se to prelozilo, to uz je zalezitost OS+toolkitu+programu.

[Filip Jirsák]

Uživatel mohl ty znaky zkopírovat přes schránku. Mohl je zadat přes speciální kódy (Alt+kód). Mohl jen kliknout na odkaz. Každopádně prohlížeč nějakým způsobem obdržel posloupnost znaků Unicode, a já nevidím žádný důvod, proč by tu posloupnost měl normalizovat nebo jakkoli měnit.

[Ondrej Santiago Zajicek]

Ono je vcelku jedno, na ktere softwarove vrstve k tomu doslo. Moje pointa je v tom, ze uzivatel pri zadavani URL stiskl klavesu 'č' a OS+toolkit+prohlizec podle sve implementace vygeneroval ruzna URL.

[Sten]

Klávesnice v MacOS X používá NFC, protože NFC je vhodnější pro obecné dokumenty (zabírá méně místa).

[Ondrej Santiago Zajicek]

Původní problém byl, že ta aplikace sama neuměla porovnat dva názvy souborů.

A jinak u názvů souborů snad nemá smysl dělat jinou normalizaci než Normalization Form Compatibility Composition, ne?

V Linuxu asi jo, nicmene treba OS X udajne pouziva NFD.

No, podival jsem se na rozdil mezi NFC a NFKC a IMHO pro ucely ukladani normalizovanych jmen souboru je NFKC nepouzitelne, tam je treba pouzit NFC (nebo NFD, pokud by cloveka nezajimala kompatibilita se stavajicim software).

[Sten]

NFD má lepší binární řazení (či řazení v ASCII), protože znaky s diakritikou jsou za stejnými znaky bez diakritiky (AÁB v NFC, ABÁ v NFC). Což je důvod, proč ho používá MacOS X. Kompatibilita je dobrá pro porovnávání, ale ne pro ukládání, protože může měnit význam v určitých kontextech.

[Sten]

Ta ukázka měla být AÁB v NFD, ABÁ v NFC

[Ondrej Santiago Zajicek]

NFD má lepší binární řazení (či řazení v ASCII), protože znaky s diakritikou jsou za stejnými znaky bez diakritiky

To me prijde jako zanedbatelna vyhoda, nebot vzhledem k odlisnemu poctu code pointu se takove porovnani stejne hned po prvnim znaku rozsype.

Kompatibilita je dobrá pro porovnávání, ale ne pro ukládání, protože může měnit význam v určitých kontextech.

Jo, to je pravda. V kontextu, ktery jsem resil, nema NFKD / NFKC smysl.

[Sten]

To me prijde jako zanedbatelna vyhoda, nebot vzhledem k odlisnemu poctu code pointu se takove porovnani stejne hned po prvnim znaku rozsype.

Proč by se mělo rozsypat? Znaky se při řazení porovnávají od začátku, a pokud se nějaké znaky nerovnají, další se už neporovnávají, bez ohledu na to, kolik jich následuje. Č se rozloží na Cˇ (kombinující znaky jsou za znaky, se kterými se kombinují, právě kvůli řazení), což se umístí za CZ (C == C, Z < ˇ), ale před DA (D > C, dál už se neporovnává).

V MacOS X to funguje poměrně dobře, třeba v Linuxu s českou lokalizací je ѓ až za я (protože česká lokalizace nemá pravidlo pro ѓ a code point je vyšší než я), ale v MacOS X je za poslední položkou začínající г a před д, což je velmi dobře umístěné.

[Sten]

Jinak NFD má pro řazení výhodu i při řazení českých znaků v české lokalizaci. V Linuxu jsou pravidla, že á=a, é=e, í=i a tak dále a že č je za c, ď za d a tak dále. V MacOS X stačí pravidlo, že se kombinující čárka při porovnávání přeskakuje a vyřeší to čárky i háčky.

[Martin Mareš]

To nefunguje, protože v obvyklém českém řazení se háčky zpracovávají jinak než čárky (háček řazení ovlivňuje už v 1. průchodu, čárka až ve 2.). Přehlédl jsem něco?

[Sten]

Přehlédl jste, že tak se to seřadí.

ER, ÉF, ĚC se normalizují na ER, E´F, EˇC.

Nejprve se řadí prvním znakem. Všechny jsou stejné, pokračuje se dále.

Poté se řadí druhým znakem. U E´F se (dle pravidla) čárka přeskočí a porovnává se místo ní další znak:
ER × E´F. R > F. E´F bude před ER.
ER × EˇC. ˇ > R, ER bude před EˇC.
Výsledek: ÉF, ER, ĚC.

[Filip Jirsák]

Výsledek: ÉF, ER, ĚC.

Což není správně podle českého abecedního řazení, mělo by to být ĚC, ÉF, ER – v prvním průchodu se diakritiky u E ignorují, ale už po prvním průchodu jsou tato slova seřazená, není tam žádná nejasnost, která by vyžadovala druhý průchod.

[Filip Jirsák]

Tak jednoduché to není. V prvním průchodu se za samostatné znaky považuje Č, Ř, Š a Ž, ostatní znaky s háčkem (Ď, Ň, Ť) se v prvním průchodu řadí stejně, jako znak bez diakritiky.

[Ondrej Santiago Zajicek]

Dalsi dobry duvod pro nastaveni LC_COLLATE na C.

[Ondrej Santiago Zajicek]

Znaky se při řazení porovnávají od začátku, a pokud se nějaké znaky nerovnají, další se už neporovnávají, bez ohledu na to, kolik jich následuje.

Jo, to je pravda (sice by se to rozsypalo, ale v tu chvili uz je rozhodnuto).

Tedy az do chvile, kdy to nekdo bude chtit kombinovat se znakama z dalsich bloku za compose symboly (napr. s rozsirenou interpunkci ci matematickymi symboly), pak NFD povede k horsimu binarnimu usporadani nez NFC (Č bude za CZ, ale pred C‡).

[Filip Jirsák]

Kompatibilita je dobrá pro porovnávání, ale ne pro ukládání, protože může měnit význam v určitých kontextech.

Psal jsem právě o porovnávání. Ukládat by se podle mne mělo přesně to, co dostanu na vstupu, tedy nenormalizovaný název. To má samozřejmě tu nevýhodu, že se to pak při zpracování obvykle musí normalizovat. Ale myslím, že o normalizaci se nedá rozhodnout obecně, že si o konkrétním použití musí rozhodnout aplikace.

[Ondrej Santiago Zajicek]

Pokud by se jmeno souboru neukladalo do filesystemu normalizovane, tak by to znamenalo, ze programy nemohou pouzit standardni funkce pro pristup k jednotlivym souborum, ale musi vylistovat vsechny soubory, provest unicode-match a pak teprve udelat prislusnou operaci na matchujicim souboru. To je nerealne, nebot by to znamenalo prepsat prakticky vsechny programy pracujici s uzivatelsky zadanymi soubory, rozbilo by to kompatibilitu s ISO C a POSIX a bylo by to podstatne pomalejsi. Nebo jak si to tedy predstavujes?

[Filip Jirsák]

To ale předpokládá, že program dostane textový obsah názvu souboru (uživatel by ho popsal „soubor pojmenovaný velké dlouhé á“), program ho následně převede do Unicode a pak jej na disku hledá. To ale není typické použití. Typicky program vypíše seznam souborů a uživatel si ze seznamu nějaký vybere. A i když uživatel zadává jméno souboru přímo, zadává Unicode znaky – takže pokud by měl uživatel soubor s názvem poskládaným ze znaku a znaménka, nebo soubor obsahující v názvu slitek, holt by to tak musel také napsat.

[Ondrej Santiago Zajicek]

To ale není typické použití. Typicky program vypíše seznam souborů a uživatel si ze seznamu nějaký vybere.

Jak kdy a jak kde. Rekl bych, ze na svem systemu mam nainstalovano radove vic tech programu, kde se jmeno zadava, nez tech, kde se soubor vybira.

A i když uživatel zadává jméno souboru přímo, zadává Unicode znaky

Jak jsem psal vyse, uzivatel macka klavesy a vidi jako odezvu grafemy. A typicky netusi, jake unicodove sekvence se vygeneruji.

takže pokud by měl uživatel soubor s názvem poskládaným ze znaku a znaménka, nebo soubor obsahující v názvu slitek, holt by to tak musel také napsat

Coz je koneckoncu to, na co si stezoval OP (Tomáš). IMHO v Unicode je to mysleno opacne - rozdily mezi kodovanim jsou imaterialni, pokud jsou vstupni unicodove sekvence kanonicky ekvivalentni, tak reprezentuji stejny retezec abstraktnich znaku a prislusna akce by mela dopadnout stejne.

[Filip Jirsák]

Rekl bych, ze na svem systemu mam nainstalovano radove vic tech programu, kde se jmeno zadava, nez tech, kde se soubor vybira.

To ty názvy souborů opravdu píšete od začátku do konce? Nepoužíváte doplňování shellu?

Jak jsem psal vyse, uzivatel macka klavesy a vidi jako odezvu grafemy. A typicky netusi, jake unicodove sekvence se vygeneruji.

Příčetný ovladač klávesnice generuje vždycky složený znak – skládání po částech ze základního znaku a znaménka je pokud vím vyhrazeno pro speciální případy. Setkal jsem se s jediným případem, kdy klávesnice generuje sekvenci znak + znaménko, a to je při použití mrtvých kláves v konzoli Archu. A je to tam špatně, protože to pak font mapper nedokáže správně zobrazit.

IMHO v Unicode je to mysleno opacne - rozdily mezi kodovanim jsou imaterialni, pokud jsou vstupni unicodove sekvence kanonicky ekvivalentni, tak reprezentuji stejny retezec abstraktnich znaku a prislusna akce by mela dopadnout stejne.

Kdyby to tak bylo, není přece potřeba mít v Unicode pro jednu kanonicky ekvivalentní sekvenci několik různých možností kódování.

[Sten]

To ty názvy souborů opravdu píšete od začátku do konce? Nepoužíváte doplňování shellu?

Jméno souboru může znakem s diakritikou i začínat.

Příčetný ovladač klávesnice generuje vždycky složený znak – skládání po částech ze základního znaku a znaménka je pokud vím vyhrazeno pro speciální případy. Setkal jsem se s jediným případem, kdy klávesnice generuje sekvenci znak + znaménko, a to je při použití mrtvých kláves v konzoli Archu. A je to tam špatně, protože to pak font mapper nedokáže správně zobrazit.

Ta chyba generuje znak a nekombinující diakritiku (dělal to občas třeba Skype, resp. vstupní systém ibus). Znak + kombinující diakritika je z definice kanonické kompatibility vykreslen totožně jako kombinovaný znak (a projde třeba i kontrolou pravopisu, pokud správně implementuje Unicode) a klávesnice takovou sekvenci klidně může generovat. Tento odstavec jsem napsal bez použití složených znaků a zobrazí se vám totožně, jako by složené znaky obsahoval

Kdyby to tak bylo, není přece potřeba mít v Unicode pro jednu kanonicky ekvivalentní sekvenci několik různých možností kódování.

Ten důvod je zpětná kompatibilita s dříve existujícími standardy (hlavně ISO 8859). U kanonické ekvivalence je z definice jedno, kterou formu použijete, všechny mají tentýž význam a vzhled.

[R]

Mne sa zobrazil inak (Konqueror 3.5.10) - diakritika je na niektorych pismenach trochu posunuta, takze je vidiet, ze su skutocne zlozene z dvoch casti.

[Gilhad]

dost casto taky ty nazvy "vybira" jiny program a treba i na zcela jinem pocitaci a OS, nez jaky je pote "nejak" zpracuje a mnohdy je tech zpracujicich vic, pricemz vetsina z nich ani netusi, ze by mohlo jit o nazvy existujicich souboru

[M]

Pokud si pojmenuješ adresář Stažené, proč si taky nevytvoříš symlink cudělej na cmake

[retroslava]

Ten adresář se vytváří sám v GNOME pokud máš při instalaci nastavenou češtinu.

[Antilinux]

Myslím, že už by Linux mohl bezproblémově zvládnout i jiné jazyky než angličtinu. Případně by si to mohl dát jako úkol do konce roku 3800.

Řetězec není pole pole bajtů - Python to dělá zcela správně. Chápu, že špatné návyky z C, kde řetězec de facto vůbec neexistuje, a tváří se, že pole integerových čísel je řetězec - to przní.

[R]

Aha, takze Python to robi spravne a preto je s nim najviac problemov?

[kyknos]

S Pythonem je nejvíc problémov? Já žádné nemám...

[R]

Ja tiez nie, lebo ho nepouzivam - robim len v C, C++ a PHP. Ale kolega mal s kodovaniami v Pythone problemy mnohokrat...

[kyknos]

toz to ja taky, ale zatim se vzdy ukazalo, ze to byla chyba moje a ne pythonu

[kyknos]

a s temi jmenovanymi jazyky bych to snad ani nesrovnaval, proti nim je python naprosto sladka a pritulna slecna :D

[R]

Nemam rad slecny :D

[kyknos]

To bych ani u někoho, kdo tráví život u c a php, nečekal :)

[pavlix]

Python 3.x. Problémy jsou s Pythonem 2.x, který naopak řešil textové řetězce ještě hůře než jiné jazyky včetně C.

[Ondrej Santiago Zajicek]

Řetězec není pole pole bajtů - Python to dělá zcela správně. Chápu, že špatné návyky z C, ...

Abstraktni 'retezec' mozna neni. Nicmene jsme na unixovem systemu, kde API dodrzuje C konvence, tak se s tim musi pocitat. A jmeno souboru je zde C-retezec, tedy zero terminated pole bytu. Pokud nejaky jazyk ma 'skutecne' retezce zalozene na 'skutecnych' znacich, tak pak musi pocitat s tim, ze funkce pro praci se soubory by nemely dostavat 'skutecne' retezce ale jine objekty (C-retezce). Pokud se jazyk snazi tento detail skryt, tak si zadelava na spoustu tezko resitelnych problemu.

V Linuxu neni kodovani nastaveno per-filesystem, ale per-user, takze zcela legitimne mohou byt na jednom filesystemu soubory se jmeny v ruznych kodovani (a bez informace o pouzitem kodovani). Rozumne programy by v takove situaci nemely selhat a mely by fungovat tak dobre, jak to jen jde.

[Filip Jirsák]

V Linuxu neni kodovani nastaveno per-filesystem, ale per-user, takze zcela legitimne mohou byt na jednom filesystemu soubory se jmeny v ruznych kodovani (a bez informace o pouzitem kodovani).

Což je jednoznačně chyba, a je dost smutné, že už to dávno nebylo vyřešeno. (Nijak nerozporuju, jak to historicky vzniklo – ale už to mělo být dávno vyřešeno. Ostatně stejně jako to, že u souborů normálně neukládáme ani jejich typ a případně kódování obsahu.) Mnoho souborů je viditelných pro více uživatelů, a dokonce ani kódování uživatele není persistentní, dává smysl, aby jeden uživatel spouštěl programy s různě nastaveným kódováním.

[R]

Preco by to mala byt chyba?

Kodovanie si riesi kazdy proces v userspace sam. Napriklad pomocou libc a premennych LANG, LC_xxx.

[Filip Jirsák]

Protože název souboru je chápán jako text, ale na disku je uložen jako pole bajtů – tedy ten text je pomocí nějakého kódování serializován do posloupnosti bajtů. Když ho chcete přečíst, musíte použít stejné kódování, jaké bylo použito pro uložení – což vůbec nesouvisí s tím, jaké kódování momentálně daný program používá pro vstup a výstup na konzoli.

[Jendа]

Což je jednoznačně chyba, a je dost smutné, že už to dávno nebylo vyřešeno.

Existuje vlastně ještě nějaký důvod, proč používat cokoli jiného než UTF-8?

[Filip Jirsák]

Na mnoha současných zařízeních mohou názvy souborů v jiném kódování. A ne-linuxové souborové systémy k jinému kódování ani nepřesvědčíte – FAT32 z českých Windows prostě bude mít vždy názvy ve Windows-1250. Asijští uživatelé by z toho asi také nebyli nadšení, protože UTF-8 jejich abecedu kóduje neefektivně.

Na druhou stranu, pevně dané kódování by bylo pořád mnohem lepší, než současný stav. A internet si na to už pomalu zvyká, že UTF-8 je povinné, a kdo chce použít něco jiného, ať si to užije (takhle je standardizovaný třeba JSON). Takže by se to asi mohlo zkusit i u souborových systémů.

[Josef Kufner]

A důvod jiný, než je zpětná kompatibilita?

[Ondrej Santiago Zajicek]

FAT32 z českých Windows prostě bude mít vždy názvy ve Windows-1250.

Naopak. AFAIK, FAT32 pouziva pro long filenames interne UCS-2, pri pristupu z Linuxu se ta jmena prekodovavaji do linuxoveho formatu ve zvolenem kodovani (mount option iocharset).

[R]

To plati pre NTFS.

[Filip Jirsák]

Aha, tak to platí pro NTFS.

[Ondrej Santiago Zajicek]

AFAIK, na NTFS je to stejne (UCS-2, resp. UTF-16).

[smazáno]

to je pravda a hezky popsano, no na 99.9% ma דניאל ten retezec "Stažené" v UTF-8

[Bernard]

Ano, při instalaci jsem si zvolil češtinu a je tam "Stažené" a je to UTF-8.

[Bystroushaak]

Řetězec není pole pole bajtů - Python to dělá zcela správně. Chápu, že špatné návyky z C, kde řetězec de facto vůbec neexistuje, a tváří se, že pole integerových čísel je řetězec - to przní.

Python to správně nedělá, byla tu o tom už nejedna diskuze. Správně to momentálně dělá třeba nový Perl, v pythonu je to docela zprasenina.

[Bystroushaak]

Crossreference: Grafémy

[Antilinux]

Python to samozřejmě dělá správně a nový Perl to dělá špatně.

Mám načtený standard Unicode zleva doprava a zpět tolikrát, až to hezké není. Programoval jsem kolem Unicode hodně věcí.

I když budete tisíckrát tvrdit a řvát, že nový Perl to dělá správně - pouze sázíte na to, že tisíckrát opakovaná lež se stane pravdou podle Goebbelsova hesla. Ale pravda to nikdy nebude.

To co dělá Perl žádnou podporu ve standardu Unicode nemá, a to zcela logicky, protože standardizátoři Unicode se nad tím zamýšleli do všech důsledků - ne jako autor Perlu, který rozšlehal Perl na maděru a z původně rozšířeného jazyka udělal jazyk, který prakticky používá už jen pár studentů historie. Teď se snaží na maděru rozšlehat i standard Unicode, ale naštěstí k tomu nemá moc a páky.

Autor Perlu se řídí stylem, že lepší drzé čelo než poplužní dvůr. Nicméně nedokáže svůj kreativní a hochštaplerský přístup k Unicode - k velkému štěstí celého světa - prosadit ani nabořit.

Možná ale že autor Perlu příště udělá inovativní přístup třeba k dalším věcem. Zmrvit jde spousta věcí, proč ne jenom Unicode? Stačí se jen vytentovat na zavedené, fungující a promyšlené standardy - a hrát si joudu záměrně standardy porušující, jak se to děje v Perlu.

Python to dělá správně.

[.]

Python to samozřejmě dělá správně a nový Perl to dělá špatně.

Doloz dukaz.

Mám načtený standard Unicode zleva doprava a zpět tolikrát, až to hezké není. Programoval jsem kolem Unicode hodně věcí.

To je velmi bidna a nedostatecna podpora tvych vyroku.

I když budete tisíckrát tvrdit a řvát, že nový Perl to dělá správně - pouze sázíte na to, že tisíckrát opakovaná lež se stane pravdou podle Goebbelsova hesla. Ale pravda to nikdy nebude.

Obsahove irelevantni.

To co dělá Perl žádnou podporu ve standardu Unicode nemá, a to zcela logicky, protože standardizátoři Unicode se nad tím zamýšleli do všech důsledků - ne jako autor Perlu, který rozšlehal Perl na maděru a z původně rozšířeného jazyka udělal jazyk, který prakticky používá už jen pár studentů historie. Teď se snaží na maděru rozšlehat i standard Unicode, ale naštěstí k tomu nemá moc a páky.

Osobni, nijak nepodlozeny nazor.

Autor Perlu se řídí stylem, že lepší drzé čelo než poplužní dvůr. Nicméně nedokáže svůj kreativní a hochštaplerský přístup k Unicode - k velkému štěstí celého světa - prosadit ani nabořit.

Osobni, utocny, nijak nepodlozeny nazor. V kazdem pripade irelevantni.

Možná ale že autor Perlu příště udělá inovativní přístup třeba k dalším věcem. Zmrvit jde spousta věcí, proč ne jenom Unicode? Stačí se jen vytentovat na zavedené, fungující a promyšlené standardy - a hrát si joudu záměrně standardy porušující, jak se to děje v Perlu.

Spekulace a osobni utoky. V kazdem pripade irelevantni.

Python to dělá správně.

Nulova argumentace.

---

Shrnuti: Autor prispevku napsal celkem 13 vet, z nichz 2 obsahuji nijak nedolozene vyroky a zbylych 11 obsahuje nerelevantni egoismus (2x), obsahove nerelevantni slovni vatu (2x) a utocne osobni nazory (7x).

Ohodnoceni:

Odborna hodnota: zcela nedostatecna
Kredibilita: zcela nedostatecna
Relevance: zanedbatelna

[Martin Mareš]

protože standardizátoři Unicode se nad tím zamýšleli do všech důsledků

[citation needed] :)

[nyan]

Skvela teorie, ktera by i mohla fungovat, kdyby cely svet vsude pouzival rekneme UTF-32. Cely svet ale pouziva trilion ruznych kodovani, a 98% programatoru na konverze kodovani bud sere, nebo ho minimalne na trech mistech zapomene. Takze nejjednodussi zpusob jak si clovek nenadela zbytecne problemy, je vyhnout se vsemu krom toho ascii... Jo a BTW ne, Python to nedela spravne.

[kyknos]

python just works :)

[Bystroushaak]

Python s tím má paradoxně asi nejvíc problémů ze všech možných jazyků, ve kterých jsem kdy dělal, právě proto, že se to snaží řešit a díky tomu vyhazuje výjimky všude možně. 2.x je prakticky nepoužitelná, aniž bys masivně nefiltroval (ztrátově normalizoval) všechno. Ve 3.x to mělo být vyřešené, ale pořád to je problém, i když pravda menší, a míň cthulhu.

Jako já mám python fakt rád, ale co člověk občas musí dělat, když má zpracovávat nesprávně uložená data, kdy třeba někdo do utf-8 stránek cpe ISO reklamu a scrappery se na tom rozpadají (klasika tady na abclinuxu), to jde daleko za pouhou bolest.

[kyknos]

Dvojku už dávno nepoužívám. Ve trojce s tím žádné problémy nemám. Naopak mi to usnadňuje práci, nemusím na to myslet. Ale může to být tím, že se nehrabu v žádných náhodných sračkách z webu.

[pavlix]

Python 3.x vidím jako dobré řešení. Maximálně striktně rozlišuje, kdy pracuješ s textem a kdy s bajtstringem. To, co popisuješ ty, je práce s bajtstringem a s tím můžeš v Pythonu dělat vše potřebné. Pro zobrazení to holt musíš konvertovat ke spokojenosti do znaků, aby se daly zobrazit.

[Bystroushaak]

Python 3 tě nutí mít znaky v jasně definovaném kódování, pokud to má být string. To bolí ve chvíli, kdy kódování neznáš, nebo to je soubor s mixovaným kódováním (na internetu běžné).

Problém s bytes je kdykoliv ho vrazíš do nějaké knihovny (html parser třeba), tak ho většinou bude má snahu převést na string a v tu chvíli se to celé rozpadne.

Ideální by bylo ideální mít nějakou možnost jak říct „mám na čůráku a je mi jedno, že z toho budou paznaky, teď to chci prostě zpracovat“, tak přestaň vyhazovat výjimky kdykoliv kdy nad tím dělám nějakou stringovou operaci. Což bytes trochu umožňuje, ale nejde to dost do hloubky.

[⧠ A = 0]

Jak se parsuje HTML bez (alespoň částečné) znalosti kódování?

[Filip Jirsák]

V lepším případě podle standardu.

[⧠ A = 0]

Takže, chápu-li to správně, v takové chvíli má HTML parser určit kódování dle standardu a podle toho si to převést na řetězec znaků. Nastane-li v takovém případě chyba, je to chyba parseru nebo stránky, nikoliv pythonu.

[pavlix]

Ano, přesně to platí.

[Bystroushaak]

Jak se parsuje HTML bez (alespoň částečné) znalosti kódování?

Naprostá většina kódování, kromě na internetu prakticky nepoužívaných výjimek používá fallback na ASCII. HTML je psané v ASCII rozsahu, takže tady není problém.

Častější příklad je že je to prostě špatně, nebo jsou tam zmixované různé věci dohromady. Jako příklad jsem uváděl třeba zdejší systém, kde máš HTML v UTF-8 a do toho je nacpaná reklama v nějakém jiném kódování, takže výsledek je nevalidní zprasenina.

[pavlix]

Pokud chceš parsovat zpraseniny, parsuj jako 1:1 8-bit kódování, jako je například ISO-8859-1.

[Bystroushaak]

Ukládám si, až s tím příště zase budu válčit.

[pavlix]

Používá se třeba UTF-16, a tipuju, že občas i na internetu. To kompatibilní s ASCII není ani náhodou, i když je čitelné.

[Bystroushaak]

Používá se třeba UTF-16, a tipuju, že občas i na internetu.

To jsem ještě neměl tu smůlu potkat.

[Filip Jirsák]

UTF-16 sice není kompatibilní S ASCII, ale snadno se pozná.

[pavlix]

No neříkejte. :) :D

[pavlix]

Chápu, co se snažíš říct, ale píšeš to úplně špatně. Python tě nenutí mít texty v žádném kódování, naopak abstrahuje textové řetězce obsahujíčí znaky Unicode. To, co ty chceš, je knihovna, která bude interpretovat bajtový řetězec v extended ASCII bez ohledu na konkrétní extenzi, k čemuž víceméňě poslouží interpretovat bajtstring třeba jako ISO-8859-1, jako to při určitém nastavení dělají některé céčkovské knihovny. A žádné výjimky to vyhazovat nebude.

[⧠ A = 0]

Jo, podpora unicode je ve věcech kolem Pythonu pořád na houby. Též cython je v tomto naprosto nepoužitelný; a posledně mě naštvala numba, kde JIT kompilátor selže, předpokládaje dementně, že kód je psán v latin-1.

/u/46/necadam1/unix/.local/lib/python3.4/site-packages/numba/dispatcher.py in _compile_for_args(self, *args, **kws)
    275             else:
    276                 real_args.append(self.typeof_pyval(a))
--> 277         return self.compile(tuple(real_args))
    278 
    279     def inspect_llvm(self, signature=None):

/u/46/necadam1/unix/.local/lib/python3.4/site-packages/numba/dispatcher.py in compile(self, sig)
    493 
    494             self._cache_misses[sig] += 1
--> 495             cres = self._compiler.compile(args, return_type)
    496             self.add_overload(cres)
    497             self._cache.save_overload(sig, cres)

/u/46/necadam1/unix/.local/lib/python3.4/site-packages/numba/dispatcher.py in compile(self, args, return_type)
     74                                       impl,
     75                                       args=args, return_type=return_type,
---> 76                                       flags=flags, locals=self.locals)
     77         # Check typing error if object mode is used
     78         if cres.typing_error is not None and not flags.enable_pyobject:

/u/46/necadam1/unix/.local/lib/python3.4/site-packages/numba/compiler.py in compile_extra(typingctx, targetctx, func, args, return_type, flags, locals, library)
    694     pipeline = Pipeline(typingctx, targetctx, library,
    695                         args, return_type, flags, locals)
--> 696     return pipeline.compile_extra(func)
    697 
    698 

/u/46/necadam1/unix/.local/lib/python3.4/site-packages/numba/compiler.py in compile_extra(self, func)
    367                 raise e
    368 
--> 369         return self.compile_bytecode(bc, func_attr=self.func_attr)
    370 
    371     def compile_bytecode(self, bc, lifted=(), lifted_from=None,

/u/46/necadam1/unix/.local/lib/python3.4/site-packages/numba/compiler.py in compile_bytecode(self, bc, lifted, lifted_from, func_attr)
    376         self.lifted_from = lifted_from
    377         self.func_attr = func_attr
--> 378         return self._compile_bytecode()
    379 
    380     def compile_internal(self, bc, func_attr=DEFAULT_FUNCTION_ATTRIBUTES):

/u/46/necadam1/unix/.local/lib/python3.4/site-packages/numba/compiler.py in _compile_bytecode(self)
    660 
    661         pm.finalize()
--> 662         res = pm.run(self.status)
    663         if res is not None:
    664             # Early pipeline completion

/u/46/necadam1/unix/.local/lib/python3.4/site-packages/numba/compiler.py in run(self, status)
    255                     # No more fallback pipelines?
    256                     if is_final_pipeline:
--> 257                         raise patched_exception
    258                     # Go to next fallback pipeline
    259                     else:

/u/46/necadam1/unix/.local/lib/python3.4/site-packages/numba/compiler.py in run(self, status)
    247                 try:
    248                     event(stage_name)
--> 249                     stage()
    250                 except _EarlyPipelineCompletion as e:
    251                     return e.result

/u/46/necadam1/unix/.local/lib/python3.4/site-packages/numba/compiler.py in stage_objectmode_backend(self)
    583         """
    584         lowerfn = self.backend_object_mode
--> 585         self._backend(lowerfn, objectmode=True)
    586 
    587         # Warn if compiled function in object mode and force_pyobject not set

/u/46/necadam1/unix/.local/lib/python3.4/site-packages/numba/compiler.py in _backend(self, lowerfn, objectmode)
    560             self.library.enable_object_caching()
    561 
--> 562         lowered = lowerfn()
    563         signature = typing.signature(self.return_type, *self.args)
    564         self.cr = compile_result(typing_context=self.typingctx,

/u/46/necadam1/unix/.local/lib/python3.4/site-packages/numba/compiler.py in backend_object_mode(self)
    534                                      self.library,
    535                                      self.interp,
--> 536                                      self.flags)
    537 
    538     def backend_nopython_mode(self):

/u/46/necadam1/unix/.local/lib/python3.4/site-packages/numba/compiler.py in py_lowering_stage(targetctx, library, interp, flags)
    846     fndesc = funcdesc.PythonFunctionDescriptor.from_object_mode_function(interp)
    847     lower = objmode.PyLower(targetctx, library, fndesc, interp)
--> 848     lower.lower()
    849     if not flags.no_cpython_wrapper:
    850         lower.create_cpython_wrapper()

/u/46/necadam1/unix/.local/lib/python3.4/site-packages/numba/lowering.py in lower(self)
    140 
    141         # Materialize LLVM Module
--> 142         self.library.add_ir_module(self.module)
    143 
    144     def extract_function_arguments(self):

/u/46/necadam1/unix/.local/lib/python3.4/site-packages/numba/targets/codegen.py in add_ir_module(self, ir_module)
    144         self._raise_if_finalized()
    145         assert isinstance(ir_module, llvmir.Module)
--> 146         ll_module = ll.parse_assembly(str(ir_module))
    147         ll_module.name = ir_module.name
    148         ll_module.verify()

/u/46/necadam1/unix/.local/lib/python3.4/site-packages/llvmlite/binding/module.py in parse_assembly(llvmir)
     14     """
     15     context = ffi.lib.LLVMPY_GetGlobalContext()
---> 16     llvmir = _encode_string(llvmir)
     17     strbuf = c_char_p(llvmir)
     18     with ffi.OutputString() as errmsg:

/u/46/necadam1/unix/.local/lib/python3.4/site-packages/llvmlite/binding/common.py in _encode_string(s)
     15 else:
     16     def _encode_string(s):
---> 17         encoded = s.encode('latin1')
     18         return encoded
     19 

UnicodeEncodeError: 'latin-1' codec can't encode character '\u03b8' in position 1927: ordinal not in range(256)

[Antilinux]

Ono hlavně jde o to, že princip mrvení je v jádru linuxu. Pokud je pro linux název souboru pouze posloupnost bajtů, a nikoli řetězec znaků - pak v linuxu nic jako "textový název souboru" neexistuje.

Vznikají proto problémy, když se pokoušíte pracovat s "názvem souboru", ale linux nic takového neumí ani nepředpokládá. Identifikace souboru skrze API linuxu probíhá skrze pole bajtů eufemisticky a z historických důvodů nazývaných "název souboru", ač to název není.

Ostatně unix, C a spol. se do toho začínají zamotávat. Stejně jako funkce strlen() nezjišťuje žádnou délku textového řetězce, ale pouze pracuje s polem bajtů. Což si snadno zjistíte, až mu předhodíte třeba UTF-8 nebo UCS-4 řetězec.

Proto jsem se výše ptal, abyste si uvědomili, že TEXTOVÝ NÁZEV SOUBORU linux nemá, a nikdy neměl. A pokud se něco nezmění, tak ani nikdy mít nebude. Proto jakákoli snaha považovat název souboru za řětězec bude neustálým zdrojem chyb, protože to řetězec v linuxu není (na rozdíl od třeba Windows).

Ještě jednou: linux nic takového jako textový název souboru nemá, nepracuje s ním, a neukládá ho. Emulace skrze bajtové pole označující soubor skrze linux api není, nebyl a nikdy nebude textovým řetězcem. Chyba proto je, když mluvíte o "názvu souboru" a snažíte se s ním pracovat jako s řetězcem. Což linux neumí, a linux je zde - ne sto, ale miliardu let - za opicemi.

[Sten]

Ve Windows to ale také není textový řetězec, alespoň z pohledu Unicode, protože můžete mít dva různé soubory s kanonicky ekvivalentním názvem a stejně tak můžete mít soubory s neplatným UTF-16 (pro Windows je to jen sekvence short intů). S wstrlen je stejný problém jako se strlen, surrogate pairs jsou počítané jako dva znaky (mimochodem v Unicode znaky ani nemají příliš význam, důležitější jsou grafémy, ale ty umí počítat máloco), a Windows neumí správně ani UTF-8, surrogate pairs při převodu nesloží a přeloží je jako dva code pointy.

[⧠ A = 0]

No to je hezké, ale můj problém s názvy souboru nesouvisí.

[Martin Mareš]

"A když to napíšu stokrát, bude to pak pravda?"

[⧠ A = 0]

Tak už to zjevně funguje. Musím pochválit vývojáře numba za aktivitu: zdá se, že to opravili během 24 hodin po nahlášení.

[Pavel Stárek]

Jsa poučen z Windows tak i v Linuxu vždy builduji cokoliv v adresáři kde v názvu a kompletní cestě k němu nejsou nábodeníčka a mezery.

[jozka]

Kdyby jen...

Nebo jsem jediny, komu jeste letos neprisel email se zmrsenymi nabodenicky v cestine?

[Antilinux]

Mně se to letos ještě nestalo. Je vidět, že dálnopisné doby už jsou za námi.

Někteří ovšem ještě nezvládli ani dikaritiku ve svých příspěvcích. Hlásím, že jozka má rozbitý příspěvek, něco po cestě mu sežralo háčky a čárky - zřejmě nějaká techniká chyba.

[.]

Text je s minimem cviku dobre srozumitelny i bez diakritiky a paklize se nejedna o profesionalni sazbu, neni potreba prepinat rozlozeni klavesnice. Ty jsi ale ocividne tomu tu praci venoval a tim mene je omluvitelne a pochopitelne pouziti znamenka minus ("-") namisto pomlcky. Zrejme neznalost.

[kyknos]

je to vubec minus? ja mam pocit ze minus ma ve spravne typografii take samostatny znak, tohle je proste spojovnik (nebo jak se tomu rika), proste znak pouzity napriklad v "je-li" nebo pri deleni slov

[Sten]

Je to spojovník, mínus je tohle: −

[Ondrej Santiago Zajicek]

Kdyz uz chceme byt puntickari, tak pouzil hyphen-minus, znak reprezentujici jak hyphen, tak minus. Samotny hyphen je 0x2010 (‐), samotny minus je 0x2212 (−).

[Marv-CZ]

A proč bys měl přepínat klávesnici? Já mám pořád zapnutou českou, na té napíšu vše co potřebuji. Stačí používat pravý Alt.

[:::]

proc by nekdo pouzival zprznenou ceskou klavesnici kdyz 99% veci pise anglicky ?

[kyknos]

protoze na ceske klavesnici lze napsat 100% anglictiny?

[pavlix]

Na us(cz_sk_de) taky a pro člověka odchovaného na us s občasným přepnutím čea daleko pohodlněji.

[kyknos]

Jak píšeš na us českou diakritiku?

[pavlix]

Reaguješ určitě na můj komentář?

[Jendа]

Strawman, moje česká klávesnice není zprzněná.

[pavlix]

To není strawman, jen předpoklad, že se českou klávesnicí myslí nejběžnější varianta.

[Jendа]

Nečekal jsem, že na linuxovém serveru bude někdo předpokládat rozložení z Windows.

[pavlix]

Nepředpokládám nutně rozložení z windows.

[Jendа]

To je to nejběžnější a je opravdu zmrvená. Ale ta originální v Xkách je docela povedená, mám tam jenom pár úprav a běžně s tím programuju:

!! nepamatuji si, kdy jsem naposledy použil ÚMYSLNĚ caps, akorát si ho vždycky omylem zapnu při netrefení se do TABu (nejpoužívanější klávesa  
clear lock

!! trojtečka … místo §
keycode 48 = ellipsis exclam NoSymbol NoSymbol apostrophe ssharp
!! § přesuneme o dvě klávesy doleva
keycode 46 = l L NoSymbol NoSymbol Lstroke section
!! spojovník – na klávese vedle backspace
keycode 51 = dead_diaeresis endash NoSymbol NoSymbol backslash bar
!! když už je na Q Ω, tak se hodí i μ
keycode 24 = q Q NoSymbol NoSymbol Greek_omega Greek_OMEGA
keycode 25 = w W NoSymbol NoSymbol Greek_mu Greek_MU

!! z capslocku uděláme „typo“ klávesu pro kůůl češtinu!
keycode 66 = doublelowquotemark leftdoublequotemark

!! keycode 135 = a

keycode 135 = Mode_switch

keycode 0xb = ecaron Ecaron 2 NoSymbol at dead_caron 
keycode 0xc = scaron Scaron 3 NoSymbol numbersign dead_circumflex
keycode 0xd = ccaron Ccaron 4 NoSymbol dollar dead_breve
keycode 0xe = rcaron Rcaron 5 NoSymbol percent dead_abovering
keycode 0xf = zcaron Zcaron 6 NoSymbol asciicircum dead_ogonek
keycode 0x10 = yacute Yacute 7 NoSymbol ampersand dead_grave
keycode 0x11 = aacute Aacute 8 NoSymbol asterisk dead_abovedot
keycode 0x12 = iacute Iacute 9 NoSymbol braceleft dead_acute
keycode 0x13 = eacute Eacute 0 NoSymbol braceright dead_doubleacute

!!keycode 107 = Next
!! tohle jsem přemapoval protože notebook má blbě funkční klávesy pro nastavení jasu. Nastavení jasu tady nevidíte, to se dělá jinde.
keycode 127 = F12
keycode 96 = Pause

!! iirc nějaká věc aby to psalo čísla i s omylem vypnutým numlockem
keycode 90 = 0
keycode 87 = 1
keycode 88 = 2
keycode 89 = 3
keycode 83 = 4
keycode 84 = 5
keycode 85 = 6
keycode 79 = 7
keycode 80 = 8
keycode 81 = 9

keycode 173 = Home
keycode 171 = End

[pavlix]

Vidím, že s úspěchem používáš xmodmap. http://unix.stackexchange.com/questions/249122/why-do-my-xmodmap-binds-involving-altgr-only-work-one-some-keys

[jozka]

Mne jo, nekolikrat. Asi tam jeste nekde maji telex...

A ano, nabodenicka mi neprosla filtrem mezi klavesnici a prsty. Delam to tak mozna dvacet let a asi uz to menit nebudu.

Ostatne soudim, ze mistr Jan byl upalen pozde.

[Antilinux]

Je zvláštní, že já builduji na Windows i jiných operačních systémech už desítku let v adresářích s diakritikou i mezerami - a něma problema.

Windows totiž má názvy souborů jako textové řetězce - tam se musím sakra snažit aby problém byl.

Linux je co se týká názvů souborů mnohem chatrnější a problémovější. Je třeba si uvědomit, že nic takového jako řetězcový název souboru v Linuxu neexistuje.

Jediný unixový systém, který toto vyřešil byl Plan9, a to prostým stanovením, že sekvence bajtů v identifikacích souborů budou brát bez výjimky jako UTF-8 řetězce a nikdy nic jiného.

Nevím co děláte, protože mě programátořina živí a dostanu se k leččemu, ale abych si nemohl užívat běžných znaků v souborech - to odmítám, protože jsme v 21. století a doby dálnopisů a 7-bitového ASCII jako jediných standardů a mainstreamu jsou už za námi. Pokud Linux nic jiného neumí spolehlivě, já nepotřebuji Linux.

[.]

Pokud zamitnes operacni system jen kvuli problemum s nabodenicky v nazvech souboru, tak jsi diletant a idiot, a po tom, kdo nebo co te zivi nam nic neni.

[R]

Dobry vecer, pan Ponkrac.

Vy s Windows mozno problemy nemate, ale mnoho ludi ano.

Napriklad staci vytvorit dostatocne hlboku strukturu adresarov (zvladne to bez problemov teta z kancelarie pri organizovani dokumentov) a zacnu sa diat veci... Medzeru v ceste adresara niektore programy nerozchodia. A co subory CON, PRN, NUL, PRN a pod.?

[/home/davkolponkrac_hunter.py]

Approximated author: Miloslav Ponkrac

Determined context: IT

Probability: q0=0.8865979381443299, q1=0.79996000000000004

Weak spots:

* unrecognized word "něma" (appears to be None)

* unrecognized word "řetězcový"

* unrecognized word "problema" (appears to be Spanish)

For reference:

* arbitrary text (lang=Czech, context=IT, authors=mixed) scores similarity of q0=0.287325479930192, q1=0.186539764321105 with author Miloslav Ponkrac

The following output was recorded during policies processing:

* Other posts of 'Antilinux' appears to be written by Miloslav Ponkrac as well.

* Honoring '1-blame-per-thread' policy. Terminating.

(Thread took 1 min 46 sec to process.)

[Bystroushaak]

Fakt? Ukaž zdroják. Já si s tímhle kdysi hrál a byl to docela fail, mělo to asi miliardu parametrů na nastavování.

[Ruža Becelin]

Hlavne mu tam chybi lomitko, jinak fajn pokus

[Michal Kubeček]

V první aproximaci by se dal zkusit bayesovský filtr ze spamassassinu nakrmený dostatečně velkou databází dosavadních příspěvků. Teprve pak by se to případně dalo rozšířit o zkoumání větné stavby, charakteristických frází atd.

[lol]

a byl jsi s tim u doktora?