Odpověď na názor

Odpovídáte na názor ke článku Čeština? Jdi mi k šípku!.

  • 13. 5. 2008 21:35

    Lael Ophir (neregistrovaný)

    [67] [69] Samozřejmě pokud jsou kvůli UTF-8 třeba úpravy funkcionality aplikace (hledání, zalamování), neřešil bych už jako problém to, že je nutné se poprat i se jmény souborů. Navíc cp a mv sice fungovat budou, ale už u ls správně konstatujete, že nastane problém. Gzip a tar sice budou zdánlivě fungovat, ale pokud archiv ze svého počítače jedoucího v UTF-8 rozbalíte u mě (a já pojedu 8859-2), názvy souborů se okamžitě zmrší. A i na jednom počítači se vám začnou na jednom FS míchat názvy souborů v různých CP, psané Unicode/ne-Unicode aplikacemi.

    Tvrdíte sice, že pojetí zpětné kompatibility ve Windows je příliš úzké, ale ve skutečnosti ty aplikace dělají přesně to, co uměly na starém systému. Souhlas, že to má omezení ohledně dopředné kompatibility. Ale je to strategické do budoucna (ne jako v případě těch překladů do a z UTF-8 před a po každém volání), a nemrší to znakové sady.

    Autoři Qt by vám nepoděkovali. Vedlo by to k tomu, že byste musel konverze dělat ručně. Získat list souborů v adresáři v jedné formě, převést do stringů, ty nacpat do GUI, až uživatel na něco klikne tak postavit ze stringu zase jméno souboru v UTF-8... Ušetřil byste převod pouze ve chvíli, kdy dostanete z libc název souboru v UTF-8, pak na něj už nijak nesaháte (ani ho nezobrazujete), a jen byste ho hned použil. Takových situací asi nebude moc. Všechny ostatní situace by dopadaly úděsně, a byly by na chyby (kódování) daleko náchylnější.
    Nepíšu v Qt, ale konstanty pro oddělovače adresářů, metoda pro path contatenation (@"můj adresář",@"můj soubor.ext") apod. minimálně v .NET Frameworku jsou. Samozřejmě pracují se stringy (podobně jako Qt, nebo libc), v případě .NETu jsou to UTF-16 stringy. Trochu problém je v tom, že na to autoři SW kašlou, takže Mono (nebo nějaká jeho nadstavba, už nevím) například automaticky překládá \ na / apod.
    Unicodová normalizace se řeší jinde. Vy GUI prvku vždy házíte string. Co s ním dělá GUI prvek, a jak ho případně cestou normalizuje, to je jeho věc. Pravda, v případě Linuxu propadne skrz Qt, kde se převede na UTF-8, na X11 libs, a pak se pošle přes síťovou vrstvu (nebo shared memory) X11 serveru. Děsně neefektivní, a pomalé. Ale já to nevymýšlel.
    Daleko horší alternativa ale je, abyste měl pa-string pro jména souborů, jiný pa-string pro normalizovaný Unicode, a mezi nimi jste převáděl ručně.

    [67] Ve Windows je nějaký font matching podle stylu apod., tabulky volitelně (vzhledem k množství fontů se nepoužívají).
    Typograf, ale i jakýkoliv jiný grafik, bude samozřejmě chtít GUI. Takže mu nezbude, než Inkscape nebo Scribus. NO a náhrada fontu v jakémkoliv DTP či grafickém programu je velmi špatně.