Čeština? Jdi mi k šípku!

V práci máme na cca 100 počítačů tři velké síťové tiskárny. Jedna z nich není schopna vytisknout soubor, v jehož názvu (respektive v názvu úlohy) se vyskytují některé diakritické znaky - mám dojem že se jedná o č a ř. Namísto dokumentu vytiskne jenom nějakou stránku s chybou.

Mne osobne je vhodnejšie mať aj v súborovom systéme určitú kultúru. A keďže slovenčina sa bez diakritiky nezaobíde, chcem mať súbory s diakritikou a keď je možné, aj s medzerami v názve. IMHO viac lahodí oku Časový harmonogram migrácie pošty.odt ako casovy_harmono­gram_migracie_pos­ty.odt, ale to je skôr záležitosť môjho názoru a mojej chorobnej obsesie mať všetko pekne poporiadku zoradené, pomenované, otagované a pod.

Každopádne, odpoveď je podľa mňa dosť hrubá a arogantná, už len z prezentovaného pohľadu, že počítače v dnešnej dobe slúžia ľudom a nie naopak. A vôbec, načo máme Unicode? Myslím si, že jeho prvotným cieľom nie je implementácia klingónčiny, ale aj práve takáto príjemná práca s názvami súborov.

[2] +100

Unicode sice mame, ale jelikoz Bill 2000/XP (nevim jak vista) stale pouziva interne CP-xxxx a to v zavislosti na nejakem tvrdem defaultu podle regionalni verze OS, tak to neni tak svetle jak se muze zdat. Zrovna u nazvu souboru se projevuje ta interni reprezentace a zrovna tam jsou s tim nejvetsi problemy, aspon podle mych zkusenosti. Plus u CP-1250, coz jsou nase konciny, jsou asi dva az tri znaky (osobne vim o š) mezi kontrolnimi, coz unixove kompatibilite taky nepridava. (Kontrolni znaky nejsou jen 0-31 ale take 128-159.)

A konecne na diskusni fora pisu jak se mi zrovna chce. Vetsinou se mi ěščř psat nechce, protoze jsem zvykly rychleji psat takto.

Já diakritiku a mezery v názvech souborů zásadně nepoužívám, ale nikomu nebráním v tom, aby to dělal. Je to jen můj zvyk a znamená pro mě například méně problémů při práci se skripty a podobně.

V případě výše zmíněného problému se jednoznačně jedná o chybu, kterou je třeba opravit. Ta reakce je sama o sobě špatná a jako řešení je samozřejmě nesmyslná. Příčinou problémů není použití diakritiky jako takové, ačkoliv to pisatel tvrdí.

[4] Hm, ale tazatel píše, že se stejně blbě chová i v Linuxu... A tam by s tím asi problém být neměl, ne?

Ja mam z diakritiky v nazvech souboru strach, treba u nas v praci IT odbornici pojmanovali sitove disky a adresare na nich s diakritikou a mezerami a diky domu ted nelze posilat klikaci odkazy na soubory na nich ulozene... Outlook proste nazev s mezerou bere jako dva samostatne...

ja bych proti diakritice v nazvech souboru nebyl, kdyby microsoft nehazel vsem klacky pod nohy a nevymyslel si svoje vlastni kodovani.. kdyby to bylo vsude v utf-8, nevidim v tom problem

diakritiku ve vlastnim zajmu v nazvech nepouzivat

clovek totiz tezko muze dopredu rict, kdo vsechno soubor dostane do rukou a jakymi zarizenimi a filesystemy za svuj zivot projde

Já používám diakritiku v názvech dokumentů a multimediálních souborů. Prostě ty soubory, které třeba někdy někomu pošlu. Vše ostatní pro sebe píšu bez. Horší je právě to, že když pak takové soubory otevírám ve win, tak jsou názvy zmršené a ironičtí lidé říkají, že to Linux zmrvil... pak už je to jen o sebeovládání :)

Tak nějak mě přijde, že odpověď na legitimní požadavek je více než chybná. Toto není slušný programátorský ani lidský přístup ... To je arogance "sklepního programátora" nechápajícího požadavky Běžného Franty Uživatele :)

Nějak si, jakožto komerční programátor, neumím představit, že bych takto zákazníkovi odpověděl. Šéf by mě asi nepochválil a netroufnu si odhadnout reakci zákazníka do detailu, ale asi by nebyla příliš pozitivní .... Stejně jako moje měsíční hodnocení potom :)

Osobně používám diakritiku a mezery v názvech souboů jenom výjimečně, podle skvrn na slunci a měsíci, ale nevidím důvod k jejímu nepoužívání. Sice ve mě vždycky zatrne, když vidím takový název dokumentu, ale proč ne ... Vzpomínám si, že když přišla Windows 95 a na serverech sme měli NT 3.51, tak jsem musel z OS2 1.2 mazat/přejmenovávat ze síťových disků "Nová složka" ... Kde ty doby jsou:))

Já v tom mám naprosto jasno: dokud budou s diakritikou problémy (a i dnes v mnoha situacích jsou obrovské a pravděpodobně ještě hodně dlouho budou), nebudu diakritiku používat (v názv. soub.) a ty kteří ji používají nikdy nepochopím.
Konkrétně mám problémy při přenosu Windows Linux (přes ftp, dc++, flash disk, ...) a jak jsem slyšel, existuje tento problém i při přenosu Windows Windows. Problémem je samozřejmě nedostatečná snaha vývojářů vyřešit tyto problémy. Je zajímavé, že název souboru dokáže linuxový program správně zobrazit, ale po přenosu na lokální disk je nečitelný (neznámé znaky).

Já názvy s češtinou používám a pokud něco nefunguje, tak se hlásím bug a nebo se program rovnou snažím opravit (tady to bude nejspíš nějaký problém v předávání jména mezi Thunderbirdem a OpenOffice přes D-BUS nebo ekvivalent). Problémy jsou akorát s programy ve Windows, například Total Commander pořád nepodporuje UTF-8 na FTP.

Potíže s diakritikou ve jménu souboru/cestě se občas, s různou frekvencí, objevují napříč spektrem OS a aplikací. Souhlasím ale, že současný vývoj by měl směřovat k uspokojivému vyřešení tohoto důsledku "zmatení jazyků", namísto jeho popírání. Otázka je, zda právě obyčejní uživatelé (bez hanlivého podtextu), kteří by rádi využívali všech možností textu ve všech aspektech systému, mohou programátory "donutit" najít a plošně používat funkční řešení, nebo zda je (pro obě strany?) pohodlnější nechat to tak, jak je. Proč se namáhat, když přeci angličtinu diakritika netrápí a cestine_se_pre­ce_da_taky_ro­zumet...

Diakritiku do nazvu souboru necpu. Dela to jenom neplechu. Naprosto me vytaci, kdyz v nasem skolnim systemu na poskytovani informaci, souboru apod. pro studenty (STAG), se pro stazeni nachazi soubory s nazvem typu:

"Příklady použití korelačního koeficientu při předpokladu normálního rozdělení pravděpodobnosti-přednáška ze 4.5.2008.doc"

To bych blil :-) Navic po stazeni na disk, se mi vsechna diakritika premeni na necitelne znaky.To je ale zase chyba nekde jinde.

Nepouzivam diakritiku ani v linuxu ani pod WIN - zazil jsem ze pri nejakem problemu s diskem - NTFS problem a pouziti zachranych utilit neni vetsinou podpora pro narodni prostredi -> soubory s diakritikou nejdou obnovit - ostatni v pohode. Toto je pro me duvod nepouzivat diakritiku

co vím, tak problém byl v tom, že dřív se používalo ASCII, které diakritiku neumělo, tak byla pro různá prostředí různá kódování, ale systém pořád fungoval a pracoval jen a jen s ASCII...
V době, kdy se přechází na UNICODE to snad již nemá smysl.

Diakritiku v názvech souborů používají jen debilové s Windows mozkem.
Ať si problémy který to způsobí řeší sami.

Sice asi nejsem "profík", ale přidám svou trošku do mlýna:
Řekl bych, že problém lze přeformulovat na otázku, zda jsou názvy souborů záležitost spíše "programátorská" nebo, chcete-li, "systémová", nebo "uživatelská".
Zatímco "uživatelské" názvy by měly mít maximální pružnost, systémové raději maximální přenositelnost. A totéž platí třeba pro URL. Z podobných důvodů asi vzniklo třeba kódování base64 - zkrátka, když komunikuji s někým kdo má jiný slovník (abecedu, znakovou sadu), tak v zájmu hladké komunikace se omezím na průnik slovníků všech zúčastněných.
Na druhou stranu je mi jasné, že uživatelské hledisko je právě tak dobré, protože uživatel nechce být omezován v tom, jak si smí pojmenovávat soubory.
Osobně to dělám tak, že u sebe si pojmenovávám všechno jak chci, a když něco někomu posílám, snažím se diakritiku, mezery a podobně z názvů eliminovat.

Osobně diakritiku do názvů souborů nezanáším, jen občas stáhnu něco s českými čárkami a háčky, ale mám skript na zrušení dikaritiky (a poradí si i se situacemi, které zmiňují 4, 10, 12, 15).

Na druhou stranu musím říct, že v dnešní době (kdy i Debian Stable frčí na UTF-8) není důvod striktně vyžadovat jenom ASCII znaky v názvech souborů. Ten, kdo skriptuje v shellu, si to pohlídá (přejmenuje), a ten, kdo o shell v životě nezavadil, nepocítí problémy vzniklé z divokých názvů.

Jenom bych se přimlouval za to, aby i Wokýnkáři objevili UTF, zatím to je dost bída. Problémy při přenosu souborů jsou nemilé.

6> v linuxu se stejny problem neresi o nic lepe...

to [20]
nebylo by mozne ten skript zverejnit?

inak souhlasim s nepouzivanim diakritiky, dokud nebude utf, otazka zni prevyknu si pak?

[22] ve chvili, kdy to bude vsude utf8, nebude potreba si na nic zvykat, proste to budou znaky jako kazde jine

Problem neni, jak se s diakritikou vyporadaji pocitace a programy (to je starost programatoru), ale jak se s tim vyporadaji uzivatele.
Jelikoz casto komunikuji mimo CZ, tak pak napsat nazev souboru, kde jsou znaky treba DE,PL, ... je praktcky nemozne. Respekt k ostatnim uzivatelum by mel byt ten duvod proc nepouzivat diakritiku.

PS: Pokud by reagoval muj programator, jak bylo uvedeno v clanku, tak by se musel osobne omluvit, pokud by tohle nekolikrat zopakoval, tak by si hledal praci jinde.

Přístup [2] chápu a z uživatelského hlediska se s ním ztotožňuji. Bohužel připravenost všemožných SW v praxi je jiná, jak zde již mnozí poukazují.

Já osobně se diakritiku na filesystému snažím nepoužívat. Není to tak dávno, co jsem musel zachraňovat data z RAID diskového pole připojovaného přes smb. Zachránil jsem v podstatě vše včetně česky zapsaných názvů souborů ve dvou různých kódováních (podle toho kdo z jaké verze Win to tam zapisoval), vyjma azbukou pojmenovaných souborů. Navíc byla komplikace, že uživatel který si tu azbuku uložil měl nějak divně nastavené Windows a i ta azbuka na diskovém poli byla pomrvená. Přitom u něj na počítači (ale jen a jen u něj) se to zobrazovalo správně. Veškeré mě dostupné nástroje si na tom vylámaly zuby. Je krásné, že jsem mu zachránil data, ale názvy souborů a adresářů byly absolutně nesrozumitelné komukoli, jako bych mu je zlomyslně zakódoval. Ve finále jako kdyby to prostě nebylo.

Nemel by to byt problem a kupodivu ze strany linuxu jsem nikdy nenarazil na problem. Spise ze strany Windows ci Maca, pokud treba pouzijete flash disk. Jeste to bude nejaky patek trvat, nez se to doladi. Sam to nejak neresim, jsem zvykly pouzivat pouze anglicke znaky.

[4] Windows řady NT jedou samozřejmě odjakživa interně v Unicode. Ovšem pro zpětnou kompatibilitu je tam i API s ANSI code pages, které používají některé starší aplikace (konkrétně autoři, kteří ještě nepostřehli Windows řady NT). Pokud máte takové aplikace, nebo Windows 9x (o obojím již lze dnes úspěšně pochybovat), používejte pouze názvy v rámci code page, tedy bez ruštiny, hebrejštiny apod.
Kompatibilita s unixy vás nemusí moc trápit. Názvy na straně Windows máte v Unicode, a na straně unixu skončí nejspíš v UTF-8. Samba od nějaké verze konečně také umí Unicode. Problémem může být, pokud máte aplikaci bez podpory Unicode, která navíc neprovádí převody code pages, a ta vytváří soubory (třeba file transfer). Pak totiž opravdu proběhne "přetypování" ANSI 1250 stringu na ISO 8859-2 nebo UTF-8, tedy problém. Otázkou je, proč tak hrozné aplikace používat.

[7] Dlouhé názvy se obecně ve Windows zavírají do uvozovek. Takže v Outlooku pište "\\server\share\můj adresář\můj soubor.ext".

[8] viz výše odpověď na [4]. Jinak UTF-8 je původně specilitka pro unixy. Unicode měl původně 16-bit hodnoty, jenže unixy nebyly (a nejsou) schopny operovat se znaky o šíři 16 bitů (muselo by se předělávat API; ve Windows se Unicode API dělalo ve fázi návrhu, tak to nebyl problém). Proto byl vymyšlen překlad, který z 16-bit hodnot udělá řadu 8-bitových, se kterými si i unixy poradí.

[12] Flash disk není problém, protože VFAT má dlouhé názvy v Unicode. Jen musíte mít FS přimontované se správnými parametry. Problém při přenosu Windows-Windows neexistuje, protože ISO9660/Joliet, VFAT i NTFS mají názvy v Unicode. Ftp pravda nevím, tam možná bude problém.

[15] Přesně, problém je na straně vaší lokální aplikace. Překvapuje, že ještě v 21. století je taková věc možná.

[20] Viz výše odpověď na [4], [8]. Jinak problémy při přenosu textových souborů v UTF-8 můžete jednoduše eliminovat, když budete používat BOM na začátku souboru, jak se v Unicode doporučuje. Windows totiž nemají bez BOM možnost poznat, jestli je soubor v ANSI (1250) code page, nebo v UTF-8.

[24] Dobrá pointa. On když založíte share s azbukou nebo s diakritikou v názvu, tak většina světa nebude schopná tu diakritiku napsat. Ovšem tam, kde není nutné text zapsat z klávesnice (třeba jména adresářů a souborů), je to celkem jedno. Stejně když potřebujete někam napsat název souboru, tak na něm stisknete F2 a CTRL+C, protože GUI (a na konzoli případně použijete doplňování).

[25] To jste zřejmě zachraňoval data ze Samby bez podpory Unicode (na rozdíl od Windows NT serverů Samba dlouho Unicode neuměla), a/nebo byli klienti Windows 9x (i když pro business se zcela správně doporučovaly Windows NT). Samozřejmě i pak lze názvy souborů a adresářů převést zpět, nejspíš převodem z ANSI 1251 do UTF-8 (a možná díky nějaké konverzi na Sambě či FS mohlo být třeba před tím ještě název jinak převést či přetypovat - těch kombinací není tolik).

no ono to nie je problem iba medzi thunderbirdom a ooo ale skusal som ooo aj pod vistami a jednoducho neotvori subor s diakritikov. To aby som vsetko premenovaaval alebo ako si to chlapci zo sun-u predstavuju?

Názvy souborů s diakritikou používám běžně. Naivně si myslím, že v jednadvacátým století by se mně ty stroje mohli přizpůsobit. Jediná věc, co jsem nepřepral, je to, když se na windows zazipují soubory s názvy s diakritikou a potom je potřeba je rozbalit na linuxu. Stejně tak naopak. Vždy na tom druhém systému jsou ty názvy pokažené. Nejspíše je to věc těch archivních programů, ale nenarazil jsem na žádný (moc jsem to nezkoumal, těžko vynucovat po lidech, co mi to nosí, používání nějakého obskurního programu), který by měl v sobě i info o kódování názvů souborů.

Na českých webech píši s diakritikou, musím proto přepínat klávesnici (nechci si zvykat na speciálně upravenou klávesovou mapu), však systém (včetně GUI aplikací) mám v angličtině, a v souborech diakritiku nepoužívám, protože v naprosté většině tyto soubory mají anglická jména (stejně tak mé komentáře ve zdrojácích programů). Osobně proti tomu nic nemám, diakritika není špatná věc, ale jednak z důvodu zpětné kompatibility, srozumitelnosti chybových hlášek a jednak asi už ze zvyku na ní netrvám....
Co se týče přizpůsobování se počítači, v tom nevidím problém. Pokud bych měl proměnné, komentáře, soubory a bůh ví co ještě pojmenovávat česky, jak by k tomu přišli chudáci vývojáři ze zahraničí? Museli by hledat klávesovou mapu, kde jsou znaky s diakritikou, aby mohli se souborem operovat na příkazové řádce.....

[27] S tím že se ve Windows počítalo s Unicode ve fází návrhu a v Unixu to byl problém je to trochu složitější. Windows NT skutečně interně funguje v UCS-16LE (16-bit little endian). Jenže tohle kódování není zpětně kompatibilní s ASCII (kde znak 0 ukončuje řetězec). Takže veškeré API funkce pracující s řetězci musí být ve Windows zdvojené: pro UNICODE a ANSI kvůli kompatibilitě. A obě verze budou muset v Microsoftu udržovat ještě mnoho let...

Zatímco Unix prostě přešel na UTF-8, kde jsou řetězce pořád stejně ukončeny nulou, nemuselo se měnit vůbec nic v jádře ani většina knihoven, úpravy byly potřeba akorát u shellu, ncurses apod. A ty bohužel pořád nejsou hotové, Midnight Commander má stále s UTF-8 problémy, ale stejně tak Total Commander na Windows stále nepodporuje Unicode.

U UTF-8 se bere jako nevýhoda, že znaky mají různou délku, nedá se podle počtu bajtů určit počet znaků nebo odříznout prvních N znaků posunem pointeru. Jenže se ukázalo, že na Windows je úplně stejný problém: do 16 bitů se nevejdou všechny čínské znaky (těch jsou stovky tisíc), takže se musí používat tzv. 'Combining characters', kdy se písmeno skládá z více znaků. No a s tím jsou úplně stejné problémy jako v UTF-8.

nazvy s diakritikou nepouzivam zo zvyku. a slovensku klavesnicu mam nastavenu ako sekundarnu, takmer vobec nepouzivam

Asi budu mluvit jako člověk, který začal na Didaktiku a ZX Spectru a trochu na MS DOSu a Windows 3.1 a 3.11.

Já osobně nevidím důvod v tom používat pro názvy souborů omezený soubor znaků. Nejenom znaky s diakritickými znaménky dělají problémy. Zkuste třeba někdy dostat do názvu souboru znak "\", "/", uvozovky, hvězdičku nebo otazník. To je taky docela problém. I když to už je asi extrém. Druhý problém s národními znaky jsou fonty.
Unicode je sice hezká věc, ale také je nutné vzít v úvahu, že ne všechny znaky jsou obsaženy ve fontu, a ty pak musí být něčím nahrazeny (mám dojem, že obvykle jsou nahrazeny otazníkem, což likviduje přístupnost k souboru).
Bylo by sice hezké, pokud bych si mohl pojmenovat soubory pomocí znaků Hlaholice nebo Baybayinu (Unicode má rezervované místo i pro tyto znaky), když na počítači, kde pro tyto znaky nebudou fonty, se mi zobrazí znak, který soubor znepřístupní.

Je sice hezké, se počítače přizpůsobují lidem, ale na druhou stranu je počítač pořád jenom nástroj, který má svoje pravidla ovládání.

Jelikož jsem začínal na Didaktiku, tak nevidím problém v tom pro názvy souborů používat pouze omezenou množinu znaků, osobně používám názvy souborů bez diakritiky a bez mezer, pokud mám nějaké soubory, u kterých změna názvu není tak jednoduchá (např. uložené kompletní stránky, což by znamenalo přepsání HTML souborů), ukládám je do zvláštního adresáře.

Dokud nebude existovat souborový systém, který dokáže uchovávat název souboru jak v diakritické formě tak v bezdiakritické formě (podobně jako to má FAT32), nebo dokud všechny fonty v počítači nebudou obsahovat předlohy pro zobrazení úplně všech znaků, bude podle mě diakritika v názvu souboru přinášet problémy.

Da se na to divat ze dvou uhlu:

Mame rok 2k a naky drobny, podpora unicode (100% - tj. od jadra az po ovladace usb topinkovacu) samozrejme musi byt.

Na druhou stranu to clovek, ktery pojmenuje soubor "Výroční zpráva ze zasedání v prosinci roku 2007 o návrhu rozpočtu na příští kvartál připomínkovaná panem předsedou dne 24 února 2008.doc" (a to radsi neuvedu plnou cestu, protoze to by me pak modemisti - jsou-li jeste dnes vubec - ukamenovali) pro me navzdy zustane prasetem - a to bych mu treba odpustil i tu diakritiku ;-))))).

I kdyz uz nektere prog. jazyky (minimalne nektere implementace lispu a smalltalku pokud vim) podporuji unicode v symbolech (kdo nevi co to je predstavi si nazvy procedur a promennych), je prasarna psat to cesky i bez diakritiky, natozpak s diakritikou. K cestine se clovek uchyluje jen ve chvili kdy musi psat dokumentaci, dokonce i UI vetsinou prekladam az dodatecne, takze diakritika = nepritel ktery zpomaluje psani a zneprijemnuje zivot. I "pani predsedove a reditele" si zvykli, ze pisu "hezky cesky" ;-))))

Uzivatele sice podle vseho maji pravo ocekavat ze jim bude chodit _čeština_ vsude, nanestesti jsou ale tak tupi ze je nenapadne napriklad zkusit soubor ulozit pod jinym nazvem (aby tech deset ostatnich nemuseli zavirat), pred vytistenim prejmenovat (a nechat tak, dokud to nezacne fungovat ;-), ze mu to ten blbej vypalovaci soft nevypali kvuli ty diakritice/jinejm paznakum, cokoli.

Zrovna tak odmitaji pochopit, ze slova "nepouzivejte diakritiku v nazvech" jsou zkracenou a o hodne citlivejsi variantou:
"Jsi idiot. Nevis kdy to muze zpusobit problemy. Kdyz se problemy vyskytnou, pravdepodobne si ani neuvedomis, cim to je. Nejsi si ani schopny napsat skript, kterym si prejmenujes svych 10000 dokumentu jeste behem sveho zivota, prelozis mezi jinejma znakovejma sadama, neumis resit problemy, jen sedet a brecet/rvat na nekoho ze to nefunguje (a nejlepe mu tvrdit ze to fungovat musi, i kdyz je to posrana redmondi binarka kterou uz nikdy nikdo neopravi).

Ano, chapu ze bez 150 znakovych nazvu souboru s diakritikou pro tebe zivot nema cenu a dokonce ti bez legrace odsouhlasim ze ano, je trestuhodne ze to vzdycky jednou za cas nekde zaskripe. Pokud si chces byt na 100% jisty ze nebudes mit problemy *1), nepouzivej diakritiku (a jine paznaky) v nazvech, jinak s panem bohem, ale jsi neznale, a co je horsi, nepoucitelne pako, a ted byl jsi byl varovan."

Tim nechci rict, ze kazdy uzivatel je idiot *2), tim chci ricit, ze clovek ktery neumi plavat a byl varovan ze je tady reka hluboka a cas od casu i dobreho plavce stahne vir pod hladinu a prece do ni skace ...

*1) a nezpusobis je ani prijemcum tve prace - viz zipy, cdcka co se sice vypalily ale pri cteni maj deformovany nazvy = blbec to pretazenim nezkopiruje, ubozaci co neumi pouzit "save as" atd.

*2) zaplat panbuh jsou i rozumni uzivatele, a ta krasa je v tom ze uz si zacinaji byt vedomi toho, ze o tech pocitacich nevi uplne vsechno (pouze ten kdo vi velmi malo si mysli ze vi vsechno) a umi se zeptat i predem, misto toho aby arogantne tvrdili ze oni nic edelali tvari v tvar logum.

HOWG.

Diakritika a mezery v názvech souborů způsobují jen problémy, kupříkladu u těch mezer mě docela otravuje všechno pořád zavírat do uvozovek, proto jak mi přijde nějaký soubor, ihned ho předělávám dle své vlastní normy (konverze do rozumného formátu, kódování, přejmenování, popříp. vnitřní úpravy, jde-li o text) a ukládám na jeho příslušné místo. Navíc mám problémy i třeba s diakritikou u souborů na CDčkách a jiných médiích, které byly zapsány z win. Ano, bylo by dobré to vylepšit, o tom netřeba diskutovat, ať si diakritiku používá v názvech souborů kdo chce, ale ani to by mě pravděpodobně nepřimělo pustit se svého mustru.

Obsah dokumentů, resp. psaný text, je věc jiná.

2 webx> presne, u me to byl Commodore 64.

[34] > presne, u me to byl Commodore 64

sry za opakovani, zasrana proxy ;-)))

Ja bych jeste pridal zadne mezery v nazvech, misto nich podtrzitka!!!

[34]Didaktik šel mimo mě, ale zase PMD85/IQcko rulez:) A take CMP1.1 na PG675 a 685. DOS od 3+ a Winy od 3.0 všechny (teda až na Visty), NT od 3.51. K tomu OS2 1.x, zOS (na IMB mainframe), OS/400 (na IBM AS/400). Plus par robotickýh OS od firem GERLACH a KUKA, potazmo Siemens.

A na základě těchto zkušenosti říkám:
rozhodně dlouhe názvy. Přál bych vám mít k výpis objektů na OS/400 kdy název objektu začíná 2-3 znaky + N čísel do max. 10 alfanumerických znaků. Aktuálně se podílím na vývoji bankovního systému a mohu říci že se jedná o desetisícovky objektů. Číst takovýto seznam pouhýma očima je něco strašného, takže i když se mám při práci s objekty v číselné řadě posunout jenom o např. 5, radší použiji fci Position to...

Ad "Je sice hezké, se počítače přizpůsobují lidem, ale na druhou stranu je počítač pořád jenom nástroj, který má svoje pravidla ovládání."

Pokud pravidla OS na počítači umožňují použít diakritiku na file systému, proč ji nepoužít? To že už tu chybí "mezidruhová kompatibilta" je otázka jiná.

Ad "Jelikož jsem začínal na Didaktiku ..."

Ale to bohužel spousta lidí ne ... Uvědomte si, že oni pracují se svými Office, CAD, grafikou apod. a neřeší problém OS, oni jej chtějí používat, nepotřebují vědět, že na procesoru 8080A znamená instrukce C9 nepodmíněný návrat ... (trošku přháním :) )

Proti dlouhým názvům nic nemám, ty moc nezloběj.
To není jenom mezidruhová nekompatibilita. Mám jednu čerstvou zkušenost s Windows Vista a ani jsem k tomu nepotřeboval jinou platformu, stačil firemní Matlab.
Windows Vista, jak známo používá kódování CP-1250 (Win-1250), kdežto Matlab ISO-8859-2. Ve starších verzích Matlabu to nebyl problém, data Matlabu se ukládala do adresáře C:\Program Files\Matlab\work\. Od verze 7.1 se ovšem data ukládají standardně do adresáře C:\Users\"jméno uživatele"\Ma­tlab\work\. (na Windows Vista). Problém je že Matlab cpe ISO i do jím vytvářených adresářů, takže si asi dokážete představit, co to udělá, pokud se uživatel jmenuje Uživatel (správně - pro Matlab je nepřístupný původní C:\Users\"jméno uživatele"\Ma­tlab\work\ protože si neporadí se "ž" v CP-1250, ale vytvoří si nový, který už má "ž" v ISO-8859-2. Jenomže do takového adresáře se zase nedostatete z Win, protože si neporaděj se "ž" v ISO-8859-2 .

S těmi pravidly ... ono je to podobné autům. Auto taky dokáže jet 250 km/h i v místech, kde je dovolená rychlost 50 km/h.

Navíc, co když si uživatel opravdu bude chtít přidat do názvu souboru zpětné nebo dopředné lomítko, hvězdičku, dvojtečku, otazník nebo uvozovky?

Reakce v té diskusi byla pochopitelně nepřiměřená, ale opravdu není rozumné používat v názvech souborů diakritiku. Situací, kdy to může někoho přivést do problémů je stále ještě dost, nikdy nevíte, co běží na počítači adresáta (pokud posíláte mail), nikdy nevíte, zda s tím počítají všechny aplikace, které na soubor v souborovém systému narazí.
Diakritika v názvech souborů je zlozvyk (souborové systémy a mnohé aplikace na něco takového původně nebyly navrženy a stále ještě se jen přizpůsobují). Bohužel zlozvyk takový, že již neexistuje naděje na to se ho zbavit. A těžko lze čekat, že přesvědčíte uživatele, tupě klikající (tak je mnohde a mnozí vychovali) a žijící v domění, že pro práci s počítačem není třeba vůbec nic vědět. Takže bohužel - pokud aplikace či něco jiného neumí pracovat s diakritikou v názvech souborů, je nutné to považovat za chybu a nereagovat podrážděně jako člověk v té diskusi.

Budete se tomu divit, ale můj systém Windows XP čte i soubory s názvy psané azbukou. O diakritice vůbec nemluvím; ta je samozřejmá. Problém je asi v Linuxu, jehož všechny verze jsou původně anglické a programátorům nestojí za to, aby je přizpůsobili běžným uživatelům, protože Linux používají pouze fajnšmekři, kteří diakritiku nepoužívají z principu, aby byli světoví.

Kdo v tomto svete pouziva diakritiku ve jmenech souboru, pridelava praci sobe a druhym. Pokud si to neuvedomuje, tak ma zrejme nedostatecne zkusenosti, pokud si to uvedomuje, tak je nadmerne tvrdohlavy nebo bezohledny.

Pouzivani diakritiky ve jmenech souboru si uzivatele koliduji o sirokou skalu problemu. Zatimco cetne problemy jsou proste bugy, ktere jde relativne snadno odstranit, cetne z nich jsou koncepcni problemy, ktere se odstrani velice tezko. Napriklad mnoho prenosovych protokolu (treba FTP) nespecifikuje kodovani souboru, takze presun souboru mezi ruznymi platformami to jmeno dost casto rozbije, a programatori jednotlivych programu s tim tezko neco nadelaji.

Mimochodem, mutt spatne dekoduje diakritiku prilohy poslane z Outlooku express, nezkoumal jste nekdo, na ci strane je chyba?

Osobně diakritiku v názvech souborů víceméně nepoužívám, ale osobně bych byl pro plnou podporu UTF-8 všude. Mj. nevím, jaký máme důvod nutit araby, japonce, číňany, rusy, ... k transkripci jejich jazyka do latinky která proto mnohdy není vhodná. V češtině problém není, to jsou jenom háčky a čárky a již jsme si zvykli je nepoužívat, ale jaké opodstatnění nutit třeba japonce aby si soubor 風の谷のナウシカ.mkv pojmenoval Kaze_no_Tani_no_Nau­shika.mkv (případně s mezerami místo podtržítek, to celkem funguje všude)... Moje osobní zkušenost je, že pokud se všude použije UTF-8 a správně se vše nastaví, tak to na linuxu funguje na všech tradičně *nixových aplikacích (včetně gnome-terminalu a v něm otevřeným mc)...

[45]
Milý Kartone. U tebe to tak nějak funguje, spousta lidí má problémy a je úplně jedno na jakém to je OS.
Já osobně zažil a byl nucen řešit tolik problémů v tomto směru (a to i u lidí, kteří používali výhradně Windows), že se musím nad tvoji naivitou jen pousmát.
Naposled jestli si dobře pamatuji: Problém v názvech souborů s diakritikou, které jsou jako přílohy E-mailů, které si uživatel čte pomocí Webového rozhraní MS-Exchange. Administrátoři serveru jsou kdesi v zahraničí a Čechy jsou pro ně čímsi jako pro nás "Papua nová Guinea"... A tak uživatelé na vlastní kůži občas poznají, jaký je diskritika v názvech souborů nerozum - je vidět, že je to pro ně dobrá léčba a sami už to pak nedělají.
Souhlasím s názorem, že cpát do názvů souborů diakritiku je prasárna, ale bohužel uživatelům už to takto dnes říci nelze. Tedy pokud neprodělají léčbu např. v podobě výšezmíněného webového rozhraní.

> Osobně diakritiku v názvech souborů víceméně nepoužívám, ale osobně bych byl pro plnou podporu UTF-8 všude.

Vsude bude mozna Unicode, ale urcite ne UTF-8. Nekde se pouzije UTF-8, jinde UTF-16/UCS-2, jinde UTF-32/UCS-4. A prenosy mezi nima budou problematicke stale ...

Ještě takový dodatek... OpenOffice nepoužívám od doby, co jsem si padl do oka s TeXem, akorát si občas poklábosím s Abiwordem (když dostanu něco v .doc nebo .odt) nebo Gnumericem a ty s ne-ascii znaky v názvech souborů problém nemají.

Nicméně, dle mého názoru by bylo řešením prostě přejít na UTF-8 (a do té doby diakritiku pokud možno nepoužívat v názvech souborů). Má to jistě i své nevýhody, ale použití jednotného kódování je zřejmé - odpadá problém se zjišťováním, v jakémže to kódování daný soubor (třeba textový) nebo jeho název (to bývá problém třeba u ftp, kde klienti většinou jedou na ISO-8859-1 a kódování se tím protokolem nepřenáší). UTF-8 jako takové pak má tu výhodu (z jistého hlediska je to i nevýhoda), že základní latinka se vejde do 8 (resp. 7) bitů, díky čemuž si drtivá většina anglicky psaných textů zachová svojí velikost, ale zároveň se tu otvírá možnost použití všech Unicode znaků.

S fonty problém již tolik není, každá slušná linuxová distribuce distribuuje základní sadu fontů, která plně pokrývá nejrozšířenější znakové sady (od latinky, přes arabštinu až po korejské či čínské znaky) a jsou dobře nastavená fallback pravidla pro pro substituce chybějících znaků (čili ač DejaVu nemá Japonské znaky, díky nainstalovanému VLGothic můžu japonštinu bez problémů používat a nemusím kvůli tomu přepínat na jiný font - systém to udělá za mě). Je fakt, že v tengwaru nebo hlaholice si asi člověk moc nepopíše, ale i to se časem zlepší...

Diskusi jsem necetl, jen pridavam nazor:
az budou existovat pouze univerzalni kodove stranky, pak znak s a bez diakritiky bude stejnym znakem jakym je dnes ascii znak. Pak nema smysl nicit cestinu nejakym obecnym zakazem (protlacovanym doporucenim) diakritiky.
Dnes jeste situace ani z daleka neni perfektni. Dukazem je, ze se clovek nekdy opravdu setka s problemem ohledne diakritiky. Kdyz se to stane cloveku znalemu veci, tak to problem neni - poradi si. Kdyz se to stane normalnimu userovi, pak je vetsinou v haji a travi na tom cas a obtezuje svoje znalejsi kamarady. Prave takovy clovek bezhlave tlaci diakritiku tam, kde se prave jemu vymsti.
Perfektni je, ze uz ve vetsine umime s diakritikou pracovat aby neboha lama nenarazila, ale stale to neumime zarucit na 100%.
Umime napr. na webu zobrazovat diakritiku zasadne vzdy spravne, takze i tento prispevek zcela zbytecne pisu bez diakritiky, ale u mne je to jen zvyk, ktery jen tezko vykorenim. Nicmene pokud tomu tvrzeni uverime (jsme-li lama pak uverime a pak prave zase my ztracime cas a obtezujeme okoli at hleda reseni), pak muzeme klidne i na ten 100%-ni web strkat fajly s diakritikou a zase se jen budeme (my lamy) divit, ze neco nejde a zase budeme utracet cizi clovekohodiny pro vlastni tvrdohlavost.
Z tohoto titulu vidim spravne reseni v obchazeni diakritiky. Kdyby to ale delali vsichni, tak se zrejme nehneme z mista a proto je potreba aby nam ten vyvoj "nekdo zaplatil" tim, ze bude tuhle blbost dokolecka opakovat, vyzadovat a opakovane narazet vlastnim cenichem na tvrdou vodu :-)

> Vsude bude mozna Unicode, ale urcite ne UTF-8. Nekde se pouzije UTF-8, jinde UTF-16/UCS-2, jinde UTF-32/UCS-4. A prenosy mezi nima budou problematicke stale ...

Pokud by se zavedlo pouze Unicode, tak pak jistě, spousta jeho výhod tím padá, a protože nejsem odborník nejsem schopen posoudit, nakolik by bylo problematické zavést *pouze* UTF-8. Osobně se domnívám že výhody použití jednotného kódování s variabilní délkou znaku převažují, ale je pravdou, že ta variabilita délky znaku má poměrně velké nevýhody zase v jiných směrech...

[32] Samozřejmě Windows nepoužívají 8-bitový char, ale 16-bitový wchar_t. Řetězce z wcharů jsou ukončeny 16-bitovou nulou, podobně jako řetězce z charů jsou ukončeny 8-bitovou nulou.
To pochopitelně vyžaduje API pro zpětnou kompatibilitu s apikacemi používajícími codepages. Takové API ale není problém. Funkci CreateFile máte ve verzi CreateFileW (wide), a CreateFileA (ANSI). Unicodové aplikace používají CreateFileW. Pravěké aplikace používají CreateFileA. Ta funkce převede chary na widechary, a případně při návratu přeloží výsledek zpět. Sice to stojí nějaké prostředky, ale týká se to jen starých aplikací bez podpory Unicode.

Jak jsem psal i v původním příspěvku, protože unixy se už ze zásady nerady mění (viz například absence řady API), nebylo zřejmě realistické mít Unicode API, jako ve Windows. Proto se skrz původní char API tlačí UTF-8. Úpravy jsou přesto potřeba úplně všude. Například unixové FS ukládají chary. Jenže v jaké code page? FS to neví, kernel také ne. Pokud aplikace A píše názvy v UTF-8, a aplikace B je píše v 8859-2 (aplikace je totiž potřeba pro podporu UTF-8 předělat), vznikne na disku chaos v názvech souborů. Aby to bylo zajímavější, některé aplikace se dodávají například s nápovědou v souborech jejichž jména obsahují UTF-8 znaky, i pokud provedete instalaci na disk, kam běžně píšete názvy v 8859-2. To je pak pravý, nefalšovaný chaos. No a řadu problémů má i libc. Pár funkcí (NLS) jede s 32-bit wide charactery, zbytek jen v charech (a krmí se UTF-8). Ovšem například standardní funkce strchr, která hledá znak ve stringu, nemůže v UTF-8 fungovat, protože znak Unicode v UTF-8 (třeba ruské JA) může mít více bytů. Autoři glibc to vyřešili "rafinovaně" tak, že změnili dokumentaci funkce, takže už nehledá *znak*, ale *char*, přičemž problém zůstává nevyřešen.
Další lahůdkou jsou toolkity. Qt běží kompletně v Unicode UTF-16. Pokud přečtete název souboru z adresáře, tento je považován za UTF-8 (když je to náhodou 8859-2, máte asi smůlu). To UTF-8 se převede na UTF-16, a aplikace má název souboru. Když pak ten soubor chcete otevřít, zavoláte Qt s UTF-16 stringem, Qt ho převede na UTF-8, a zavolá glibc. Případný vrácený string by se opět překládal, pořád dokola. Ve Windows se překládá dost podobně, ale pouze pro *ne-Unicode* aplikace, které postupně vymírají. MS možná bude muset udržovat ANSI API ještě řadu let, ale unixy budou překládat chary na widechary při každém volání asi navždy, při každém jednom volání. Abych nezapomněl, GTK používá 32-bit wide char, to aby v tom nebyl zmatek.

Ano, do 16 bitů se některé znaky nevejdou. To se řeší pomocí surrogate pairs. Jejich podpora je za běžných okolností vypnutá, a ani asiaté je nemají rádi (mají k tomu dobrý důvod, kterému se říká CJK multibyte code page). Pokud je podpora surrogatepairs zapnutá, je ve Windows stejný problém, jako v Qt. V případě .NETu je to ale celkem jedno.

Autor Total Commanderu je bohužel idiot. Ten člověk například ukládal dlouhá léta konfiguraci TC do ini souboru, umístěného v adresáři aplikace spolu s binárkou. Fuj! A jaké bylo jeho překvapení, když ne-admin uživatel ve Windows 2000 do toho adresáře nezapsal, a TC zhavaroval. Podpora Unicode se samozřejmě nekoná. Resp. podle autora TC6 umí přistupovat k souborům s názvy v Unicode pomocí generovaných 8.3 názvů pro MS-DOS (fuj!), a podporu Unicode hodlá dopsat v TC 7.5 nebo 8. Možná už v roce 2009-2010 bude mít TV podporu Unicode, asi 16-17 ket po uvedení první verze Windows NT!

Diakritika mi nepřijde jako vhodná věc pro názvy v čemkoli, co se portuje mezi různými programy (Web->Mail; Linux->Windows ap.) z důvodu časté nekompatibility.
Pokud se navíc takový soubor nahraje na web, jeho URL diakritické znaky zakóduje a adresa je nečitelná (viz Wikimedia). Diakritika je sice příjemná pro národní uživatele, ale jak by se vám líbilo třeba místo "ni_hao_ma.odt?" zapisovat do URL čínský rozsypaný čaj, když ty znaky nenajdete na klávesnici?
Základní dorozumívací jazyk je dnes angličtina. Nechť je základní dorozumívací písmo ASCII: kdo se má učit všechny ty japonské, české, rumunské, arabské, tibetské, starogermánské, klingonské a kdovíjakéještě archaické znaky.

> Diakritika je sice příjemná pro národní uživatele, ale jak by se vám líbilo třeba místo "ni_hao_ma.odt?" zapisovat do URL čínský rozsypaný čaj, když ty znaky nenajdete na klávesnici?

O SCIMu jste neslyšel? Krom toho, netuším, jaký užitek byste měl z dokumentu にはおま.odt pokud nejste schopen přečíst kanji a kana (obsah takového dokumentu totiž na 99% bude právě znaky z těchto "abeced" používat)... Najeďte si třeba na http://ja.wikipedia.org/もののけ姫 (pokud to Váš prohlížeč dokáže zpracovat, pokud ne, tak http://ja.wikipedia.org/wiki/%E3%82%82%E3%81%AE%E3%81%AE%E3%81%91%E5%A7%AB). Kolik procent obsahu této stránký Vám k něčemu je? Pokud skoro nic, pak nevidím jediný důvod, proč byste chtěl její název datlovat do prohlížeče...

> Proto se skrz původní char API tlačí UTF-8. Úpravy jsou přesto potřeba úplně všude. Například unixové FS ukládají chary. Jenže v jaké code page?

Ale kdeze - pokud slo o konzolovy nefullscreenovy program (treba jako cp, gzip, ... ) kterych je v Unixu vetsina, tak ty jsou zcela kodovani-agnosticke a pro jejich UTF-8 podporu nebylo treba prakticky zadne upravy. Proste dostaly posloupnost bytu a tu predavali dal (ostatnim syscallum, nebo na konzoli). A pokud byly treba nejake upravy (kdyz treba formatovali vypis na obrazovku podle poctu znaku), tak problemy maximalne zpusobily rozhazenost vystupu, a ne nefunkcnost primarni funkce programu.

> To UTF-8 se převede na UTF-16, a aplikace má název souboru. Když pak ten soubor chcete otevřít, zavoláte Qt s UTF-16 stringem, Qt ho převede na UTF-8, a zavolá glibc.

Pokud to takhle Qt dela, tak to je znacna prasarna. Spravne reseni je mit v pameti tu posloupnost bytu, kterou dostanu od OS, a konvertovat do jine jen kdyz je to nutne (napr. v GUI), pro dalsi praci se souborem pouzit ale zas puvodni posloupnost bytu, nikoliv konvertovat zpet z interniho kodovani.

Nevim, co dela GTK v kodu, ale API pouziva UTF-8.

> Ve Windows se překládá dost podobně, ale pouze pro *ne-Unicode* aplikace, které postupně vymírají.

A co se stane, pokud jmeno souboru obsahuje znak, ktery nelze prevest do codepage, ktere v danou chvili pouziva ANSI API? Pokud to jmeno ziskam pomoci ANSI API a pak ho predam treba fopen v ANSI API, otevre se ten spravny soubor?

[34] Mícháte dvě věci. Pokud nemáte font pro zobrazení Unicode znaků v názvu, uvidíte tam typicky obdélníček (ve Windows). To ale není na závadu funkci - aplikace jméno "uvidí", soubor otevřou, jměno lze zkopírovat do clipboardu atp.
Pokud vidíte místo Unicode znaku otazník, a soubor je nepřístupný, tak používáte prehistorickou ne-Unicodovou aplikaci, a na otazníky se převádí znaky mimo aktuální code page (opět na Windows). Potom nezbývá, než zahodit tu ne-Unicode aplikaci, nebo soubor přejmenovat ve Windows Exploreru.
Znaky \ / : * ? " | nejsou v názvech souborů povoleny (opět na Windows).
FAT32, VFAT, ISO9660 i NTFS ukládají názvy souborů v Unicode, a k tomu ve formě 8.3 pro kompatibilitu s MS-DOSem (možná tomu říkáte bezdiaktirická forma?). "C:\Program Files" lze tedy zapsat "C:\Progra~1", viz dir /x.

[42] To je ovšem chyba Matlabu. Typicky se to stává u špatně portovaných unixových aplikací, které například cpou UTF-8 názvy do ANSI API, které pak ty znaky převede na Unicode, takže na disku pak skončí naprostá příšernost. No a pokud autor ještě inteligentně použije někde převod mezi code pages, a někde ne, v některých případech ani sám po sobě nepřečte soubor.
Uživatel do názvu souboru nevloží znaky \ / : * ? " | protože to nejde (ve Windows).

[51] Problém je v tom, že je tu hromada historických textů v různých code pages, hromada aplikací které neumí UTF-8, a navíc je většina textů v UCS2/UTF-16 (protože Windows používají původní kanonický Unicode, jak byl definován konzorciem Unicode).
Fonty řeší WGL4, použitý ve Windows. Pokrývá latinku, azbuku, řečtinu. Pokud chce jiné znakové sady, je třeba instalovat fonty pro nějakou nadmnožinu WGL4. Jinak vzhledem k velikosti slušných Unicode fontů se to už moc lepšit nebude. Jenom kvalitní font obsahující WGL4 se základním hintingem, a dobře optimalizovanou tradiční čínštinou, má 30MB. S ostatními jazyky řekněme 50MB, a fontů mám 400. To bychom měli 20GB diskového prostoru jen na fontech, nemluvě o paměťové náročnosti.
http://en.wikipedia.org/wiki/WGL4

57> Pokud vidíte místo Unicode znaku otazník, a soubor je nepřístupný, tak používáte prehistorickou ne-Unicodovou aplikaci, a na otazníky se převádí znaky mimo aktuální code page (opět na Windows). Potom nezbývá, než zahodit tu ne-Unicode aplikaci,

Aha, takze zatimco v Unixu (s pouzitim UTF-8) stare (pre-unicode) korektne napsane programy obvykle funguji i po prepnuti do UTF-8 (maximalne s nejakymi problemy s formatovanim vystupu) na vsechny soubory ve filesystemu, tak ve Windows s jejich metodou prechodu na Unicode stare programy prestaly fungovat na ty soubory, ktere obsahuji znaky mimo kompatibilni codepage? Tak to je opravdu ten spravny inzenyrsky pristup :-) .

54> Co jsem mel zkusenosti tak Windows krome Unicode API (v UCS2) a ANSI API (v Cesku CP 1250) pouzivala na konzoli CP 852, takze v tu dobu ruzne programy ve Windows (v ramci Cestiny) pouzivaly az tri ruzne kodovani, a to nemam na mysli jejich interni kodovani (tam at si uzivaji, co je programatorum libo), ale ktere pouzivaly externe - jak chapaly plaintextove soubory.

58: Velký počet fontů s dostatečně otevřenou licencí na možnost použití v oficiálních repozitářích Fedory má pokrytou latinku, řečtinu a azbuku. Ale to je jen nutný základ. Podpora čínštiny, japonštiny, korejštiny, arabštiny, ... je u dobře lokalizovaných distribucí nutnost těž.

Jen tak pro srovnání... LiveCD spin Fedory obsahuje něco kolem 50 fontů. Základní, obsahující onu latinku, řečtinu a azbuku zabírá něco kolem 15 MB (diskového místa), o japonštinu se stará několik fontů, dohromady asi 50 MB, korejské kolem 35 MB... dohromady mám na počítači circa 290 MB fontů. Pravda není to málo, ale i tak se to vejde spolu s plnohodnotným desktopovým systémem a ne zrovna zanedbatelnou sadou aplikací na jedno Live CD. To je v porovnání s 9 GB téměř holé instalace Windows Vist skutečně zanedbatelná "částka", navíc dostačující k přečtení téměř všech jazyků, které mají na wiki 100+ článků. Jediné, které z těchto nepřečtu jsou jazyky jako Dhivehi, Kannada nebo Phéasa Khmér (pro 1000+) a dalších pět jazyku se 100+ článku. Čili ve fontech bych opravdu problém neviděl.

Nevím jak ve Windows, ale v linuxu (při správném nastavení, o které se starají správci balíčků s fonty, či sami vývojáři fontů) skutečně existují tabulky se substitucemi, které říkají, který font použít, pokud daný znak v daném fontu chybí, a tyto tabulky jsou pak skutečně systémem pro renderování textu použity. Čili není nutno mít na počítači jeden megafont, který obsahuje celé Unicode...

[56] Samozřejmě se mýlíte. I poměrně tupý filtr more musí umět zalamovat na danou šíři, což bude těžko dělat bez znalosti UTF-8. O GUI apikacích nemluvě. Úpravy prostě jsou třeba. To, že program zřejmě nespadne, je sice pěkné, ale většině lidí to nestačí (stejně jako jim třeba nestačí, že program kompiluje).

Qt to tak samozřejmě dělá. Podívejte se na QDir::entryList(), vrací QStringList (tedy list stringů). Jsou to samozřejmě QStringy, tedy UTF-16. Jinými slovy na Linuxu to propadne na glibc, nějaký opendir(), poté asi readdir(), budeme parsovat, a výsledky strkat do QStringListu, samozřejmě s převodem z aktuální code page na UTF-16 (a budeme se modlit, aby název na disku opravdu byl v code page, ve které aplikace jede, jinak konverzi zmršíme). No a když budeme otevírat soubor, konstruktoru QFile předáte QString. Jak byste to chtěl řešit vy? Mít platformně závislý datový typ, do kterého ukládáte názvy souborů (na unixech 8-bit string, na Windows UTF-16 string, na jiných platformách jiný), a zavádět do Qt takovou příšernost? Asi ne.

[59] Jak je psáno výše, command line utility po přepnutí do UTF-8 vyžadují úpravy, a GUI aplikace je vyžadují ještě daleko drsněji. Podpora ANSI API je ve Windows z důvodu zpětné kompatibility. A připadne mi to daleko lepší, než před a po každém volání překládat všechny stringy do/z UTF-8 - podotýkám i u nových aplikací, a to zřejmě až do totálního vymření unixů.

[54] Konzole samozřejmě používala a používá Unicode, od první verze NT. Jinou věcí je font, který konzole používá (v některých verzích Windows uměl právě tak jednu code page). Nepleťte si Win32 konzoli a MS-DOS. Aplikace pro DOS používaly OEM code page, což je pro češtinu CP 852. Jejich volání se opět překládala (minulý čas je snad na místě) do Unicode. Názvů souborů se to ale netýkalo, protože 8.3 názvy si s češtinou moc nerozuměly.

Plain textové soubory chápaly aplikace pro DOS pochopitelně v OEM code page, tedy pro čšetinu CP852. Ne-Unicode aplikace pak pro češtinu ANSI 1250, s tím že zpravidla uměly v menu File/Open manuálně vybrat kódovou stránku ANSI/OEM. Unicode aplikace používaly při ukládání plain textu BOM, aby při otevírání bylo jasné, že jde o Unicode soubor. Vše přesně dle pravidel zpětné kompatibility: ANSI aplikace otevře text v OEM CP, Unicode aplikace otevře text v ANSI a OEM CP. Dopředná kompatibilita (aby třeba aplikace pro DOS otevíraly Unicode soubory) nebyla nikdy cílem.

Ještě nutno dodat, že designérům obvylke stačí omezená znaková sada, ale naopak potřebují víc stylů fontů, tiskaři pak mají k disposici fonty, které jsou dodávány s TeXem, v případě Evropských jazyků většinou Computer Modern. Čili myšlenka, že budu mít na počítači 200 megafontů s kompletní unicode podporou je zcestná a neefektivní. Fonty s omezeným pokrytím v kombinaci se substitučními tabulkami jsou plně dostačující a IMHO nejefektivnější způsob jak je na počítači použít...

56> Krom toho, netuším, jaký užitek byste měl z dokumentu にはおま.odt pokud ...

Zadny, proto bych takovy dokument chtel smazat. Coz se me ale jen tezko povede (pomoci rm) ...

64> povede... zapnu input japonštinu (třeba pomocí SCIMu), napíšu "ni" (bez uvozovek) a zmáčku tabelátor... Případně si pomůžu ls a copy&paste... Nechme ovšem stranou otázku, jak by se mi ten soubor dostal na disk, pokud o něj nemám zájem... Je ovšem pravda, že takhle hezky to funguje v gnome-terminalu, u klasického VT si holt člověk musí vypomoct třeba mc, nebo regulárními výrazy...

[61] Ve fontech začne být problém, když budete chtít komplet Unicode. Samozřejmě běžně stačí WGL4, plus fonty podle výběru podpory jazyků (já mám ještě hebrejštinu, arabštinu a univerzální fonty).

Automatická substituce fontů je velmi špatný nápad. Nemůžete vzít Arial bez českých znaků, a ty znaky doplňovat z Courier New Roman. Tenhle příklad bije do očí, ale obecně to nemůžete dělat u žádného fontu. Typograf by za takové věci zvracel, dlouho a intenzivně. Má to opodstatnění v některých aplikacích, ale obecně je to špatně.

[64] Takový dokument samozřejmě smažete z GUI. Vždyť se většina věcí dělá z GUI.

62> [56] Samozřejmě se mýlíte. I poměrně tupý filtr more musí umět zalamovat na danou šíři, což bude těžko dělat bez znalosti UTF-8.

To byla asi reakce na me - [57]? Zde resime jmena souboru. Pokud program pracoval s textem (more, sed, grep ...), pak samozrejme potreboval vetsi ci mensi upravy na UTF-8, nicmene to je off-topic. Pokud beru ciste zpracovani jmen souboru, tak upravy nebyly treba, nebo byly minimalni. Nejenom, ze program nespadl, ale cp kopiroval, rm mazal, mv presouval, gzip gzipoval, tar taroval, ls mozna pri listovani spatne vystup zarovnal do sloupcu, ale zobrazil spravny znak ... To se o metode prechodu, ktera se pouzila ve Windows, rici neda.

62> Jak byste to chtěl řešit vy? Mít platformně závislý datový typ, do kterého ukládáte názvy souborů (na unixech 8-bit string, na Windows UTF-16 string, na jiných platformách jiný), a zavádět do Qt takovou příšernost? Asi ne.

Presne takhle. Mit k danemu typu funkce pro praci (rozklad na casti cesty, prevod z/do textove reprezentace (QString)) abstrahujici i dalsi detaily (napr / vs \ pro oddeleni adresaru).

V takovem pripade by se jmeno konvertovalo jen jednou. Vzhledem k tomu, ze s QStringem se jmenem souboru pro ucely GUI muze byt treba provadet i dalsi transformace (treba unicodove normalizace), je tak jako tak rozumne mit oddelene puvodni jmeno souboru od OS a retezec pouzivany v GUI.

Proste pokud dostanu od systemu (pri vylistovani adresare) jmeno souboru a ja ho pred jeho otevrenim zcela zbytecne prevedu dvakrat mezi ruznymi kodovanimi, tak takove reseni je spatne a nachylne na chyby a zmeny podminek. Pouzit presne tu samou sekvenci bytu je robustni reseni.

[66] ta substituce není zcela automatická, protože ty tabulky pro substituce vytvářejí normální lidi. Je blbost nahrazovat bezpatkové písmo patkovým, a pokud jde o diakritiku, tak to má nejlépe řešeno asi TeX (kde se vezme "a" a nad něj se napíše "´")... Nicméně, pokud jde o kombinace třeba oné japonštiny s latinkou, tak je substituce plně dostačující (viz mé japonsky psané příklady). Čili ještě jednou, pro písmena s akcenty (čárky, háčky, stříšky, ...) je substituce špatná, pro celé rodiny znaků dostatečná (za předpokladu, že někoho nenapadne bezpatkovou latinku doplňovat mincho [obdoba našeho patkového písma] stylovanou hiraganou).

A typograf samozřejmě použije TeX, u kterého zvracet nemusí, protože má vše řešeno typograficky korektně.

62> [59] Jak je psáno výše, command line utility po přepnutí do UTF-8 vyžadují úpravy, a GUI aplikace je vyžadují ještě daleko drsněji. Podpora ANSI API je ve Windows z důvodu zpětné kompatibility.

Obavam se, ze to je prilis uzke vnimani zpetne kompatibility. Proste treba takova implementace tar pro Windows, ktera byla predtim korektni (po zadani jmena adresare ztarovala vsechno v danem adresari, at tam bylo cokoliv) po danych upravach korektni byt prestala. Tomu bych zpetna kompatibilita nerikal.

Podľa mňa je to celkom jednoduché: z programátorského hľadiska je to zlá odpoveď, z užívateľského hľadiska je to dobrá odpoveď. Prečo by som mal niečo robiť nejakým spôsobom, keď viem, že to môže spôsobovať problémy. Áno - malo by sa to vyriešiť a nemal by to byť problém. Ale zatiaľ to vyriešené k úplnej spokojnosti všetkých nie je, tak nevidím problém s tým počítať a písať názvy súborov bez diakritiky a bez medzier.

62> Podpora ANSI API je ve Windows z důvodu zpětné kompatibility.

A co kompatibilita s ISO standardem pro C99? Predpokladam, ze Microsoft ma C kompilator, ktery podporuje ISO C99. Kdyz vezmu nejaky program ktery je striktne podle C99 (napriklad vedecky program, ktery cte ze souboru cisla a neco s nima pocita) a prelozim ho takto pro Windows, ktere API se pouzije pro implementaci fopen()? Tipuji, ze ANSI API a tedy ten program nebude fungovat na nektere soubory.

Je-li tomu tak, pak jde o ultimativni argument proti pouzivani diakritiky ve jmenech souboru:

V nejrozsirenejsim desktopovem operacnim systemu multiplatformni (podle normy ISO C99) programy nemohou otevrit nektere soubory s diakritikou. A je to by design, takze se to nejspis nezmeni.

Psaní bez háčků a čárek patří do počítačového pravěku. Pokud program diakritiku špatně zobrazuje, nebo kvůli ní dokonce nefunguje, měl by propadnout při akceptačních testech a vůbec by se neměl dostat do produkce. Pokud už se tam dostane, měly by se takové chyby řešit (a ne je banalizovat). Počítače mají totiž sloužit člověku, ne naopak!

[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ě.

73> 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)

Coz je ovsem plne v souladu se specifikaci a formatem taru. Vzhledem k tomu, ze format taru je dany normou POSIX, tak se s tim moc delat neda, leda pouzivat jiny format ci nestandardni rozsireni.

73> 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.

Navrhovany postup take nemel za cil usetrit prevod, ale zajistit robustnost programu. Pokud do syscallu operacniho systemu budu davat ten objekt, ktery jsem od operacniho systemu predtim dostal, tak to proste bude fungovat, at je ten objekt cokoliv (a nejsem ve Windows :–) ). Pokud ho mezitim zkonvertuji tam a zpatky, tak se to muze snadno rozbit, protoze zobrazeni UCS2_to_UTF(UT­F_to_UCS2(X)) neni identita pro vsechny posloupnosti bytu na vstupu a asi ta zobrazeni nepujde dodefinovat tak, aby to identita byla. Pokud uz bych mermomoci chtel mit nejakou jednotnou vnitrni reprezentaci a na ni vsechno prevadet tam a zpatky, tak z tohoto hlediska je lepsi UTF8, nebot UTF_to_UCS2(UC­S2_to_UTF(X)) uz identita je pro vsechny posloupnosti dvoubajtu, ale ani to neni idealni, nebot UTF_to_UCS4(UC­S4_to_UTF(X)) uz identita neni pro vsechny posloupnosti ctyrbajtu (i kdyz snad by to slo dodefinovat).

Hmm, zapis tech zobrazeni je trochu matouci - meziformat je ten na kraji, ne ten uprostred.

73> Všechny ostatní situace by dopadaly úděsně, a byly by na chyby (kódování) daleko náchylnější.

Nebyly, protoze spravne konverze by byly vyzadovany typovym systemem jazyka.

BTW, opravdu plati to, co tipuji v [71]?

[71] MSVC není plně kompatibilní s ISO C99 (což nakonec gcc také ne), a plná kompatibilita MSVC s C99 není plánována. Je to proto, že MS používá C++, a C je mu tedy celkem volné. MSVC je kompatibilní s ANSI/ISO C++ International Standard (ISO/IEC FDIS 14882), případné odchylky jsou dokumentované. Obecně byste měl používat funkce daného frameworku (MFC, ATL), případně Win32 API (ve všech případech budete používat Unicode stringy). Dnes se samozřejmě preferuje C#, nebo C++/CLI (aka ECMA-372).
http://msdn.microsoft.com/en-us/library/45aft37a.aspx
http://msdn.microsoft.com/en-us/library/3bstk3k5.aspx
http://en.wikipedia.org/wiki/C%2B%2B/CLI
http://en.wikipedia.org/wiki/Active_Template_Library
http://gcc.gnu.org/c99status.html

[74] Ten tar je sice pěkně v souladu s POSIXem, ale nefunkční, že.

Já v Qt nepíšu, ale z toho, že obsah adresáře dostanu jako Unicode string, soubor otevírám s reference na Unicode string, a glibc (coby vrstva skrz kterou musí volání propadnout) používá char-based string, je to zjevné. Konverze zobrazení well-formed UTF-8 code unit sequence na UTF-32 je identita. Problémem je samozřejmě ill-formed UTF-8 code unit sequence. Nejsem uživatelem Linuxu, ale mám za to, že pokud máte název souboru v 8859-2, tak Qt aplikace zobrazí otazníky místo ill-formed sequence, a se souborem pak neumí pracovat (jestli chcete, zkuste si to, a podělte se o výsledek).

Jak jsem už psal, kdybyste měl třídu pro jména souborů, tu konvertoval na Unicode string, a ten nedej bože zase převáděl na nějakou třídu pro normalizovaný Unicode, tak byste zbytečně framework komplikoval. Qt, glibc, .NET, Win32 a další běžně skladují jména souborů ve stringu. Qt by přišlo ke specialitce, která by znamenala třeba při krmení GUI jmény souborů držet zvlášť původní objekty jmen souborů, zvlášť stringy, a (jak jste navrhoval) ještě zvlášť normalizované Unicode stringy. To je přece značný overhead, a příšerný opruz pro autora aplikace.

[57] Tvrdil jste mi, že GTK používá UTF-8. To je pravda, ale má to háček. String Utility Functions v řadě případů nejsou funkční pro UTF-8 znaky, a pro jistotu ignorují locale. Musíte tedy používat Unicode stringy, typ gunichar, UTF-32. Ono zrovna UTF-8 je na jakékoliv zacházení poněkud nešťastné.

Hlasuji proti češtině ve filenamech, ale když vím, že to nikde neuškodí, klidně ji použiji...
Ono to má i své výhody... třeba když to přetáhnu někam na web, tak se mi pak nazakóduje url, ale zůstane pěkně čitelná...

Pokud jde třeba o posty v diskuzích nebo jinou el. komunikaci, tak u mě záleží na formálnosti komunikace a mojí lenosti...

Jak bych to rekl, ehm. Rozdil mezi chlapci a skutecnymi muzi je v podstate ten, ze skutecni muzi pisou jmena souboru vyhradne malyma pismenama ASCII, bez mezer, a maximalne pouzivaji pomlcky a tecky na oddelovani casti. Diakritika je pro voly, mezery jsou pro lidi, co nikdy nedelali v bashi a nevi, jak moc to dokaze potrapit skript, ktery s tim nepocita. Takze asi tak.

[72] >>Psaní bez háčků a čárek patří do počítačového pravěku. Pokud program diakritiku špatně zobrazuje, nebo kvůli ní dokonce nefunguje, měl by propadnout při akceptačních testech a vůbec by se neměl dostat do produkce. Pokud už se tam dostane, měly by se takové chyby řešit (a ne je banalizovat). Počítače mají totiž sloužit člověku, ne naopak!

Prosím vás, strašně moc vás prosím, pokud toto navrhujete, zařaďte si prosím do svého seznamu programů, které by se neměly dostat do produkce, Matlab. Ten má s češtinou problémů až dost. A jestli Vás ještě mohu poprosit, začnětě prosím s nějakou aktivitou za jeho stažení. :-)

Jména souborů bez diakritiky a bez mezer obvykle nezpůsobují problémy. Jako to, že něco má nějakou vlastnost, ještě neznamená, že se tato vlastnost musí používat. Já k tomu přistupuji trochu podobně jako k noži. Nůž se taky nechá použít na otevírání lahví nebo šroubování šroubů, ale i přesto s ním tyto aktivity neprovádím.

Ačkoliv celá situace vypadá jednoduše, jedná se o několik nepříliš provázaných problémů:

1. V tomto konkrétním případě existuje postup, kterým to lze obejít - tedy je evidentní, že se jedná o chybu v programu a o nic systémového.
2. V dnešní době, kdy podpora univerzálního kódování vázne, je nerozum používat národní znaky, protože se to obvykle pokazí. Na druhou stranu pokud jsou to mé dokumenty a jen pro mně, pak mám právo požadovat aby mi tuhle "vylomeninu" počítač povolil. Ovšem v tomto konkrétním případě se řeší otevření přílohy z emailu - takže argument "co já si sám pro sebe dělám" neuspěje.
3. I kdyby do budoucna existovala 100% podpora univerzálního kódování, nebude to správně fungovat. Jde totiž nejen o to, jak informaci zpracuje počítač, ale také o to, jak ji zpracuje člověk. Pokud nebude každé zařízení a každý font obsahovat kompletní znakovou sadu (včetně kdesi zmíněných stovek tisíc čínských znaků), nebude uživatel schopen porozumnět všem textům. Takže nedej bože aby vám pak někdo poslal odkaz na soubor jako text a nikoliv jako hot link (R:\\Shared\U­sers\Ali-Ibn-Ali\?????????? ?????\???????­?\????? ? ?? ????.doc)

Jinak příklad ze života - máme tu informační systém, který pracuje v Unicode a používá ho i při exportu souborů. Bohužel jeden zákazník (tuším z Tchaiwanu?) kdysi do názvu souboru vložil nějaký jejich znak. Takže jsme několik měsíců měli na sdíleném serveru nesmazatelný adresář, protože v něm byl nesmazatelný soubor. Vylámalo si na tom zuby několik administrátorů, protože každý ten znak viděl jako něco jiného, než čím skutečně byl. Řešení pak bylo vskutku triviální - napsal se program, který procházel adresářovou strukturu toho disku a jakmile našel onen soubor, smazal ho podle jeho file handle. Takže je tu důkaz, že filesystém si s tím znakem naprosto bez problémů poradí (spíš je mu ukradený), ale běžné programy ne. Nefungovalo mazání přes průzkumníka MS Windows, nefungovalo mazání přes příkazovou řádku, nefungovalo mazání přes Total Commander. Nefungovalo ani namountování disku do RedHatu a mazání z MC nebo přes shell. Dodnes nevíme kde vlastně ke konverzi znaku docházelo a nepodařilo se nám zjistit ani jeho kód. Tedy podařilo - ale každý jsme viděl kód jiný.

Když něco posílám na FTP nebo tak nějak, tak je z 99 % bez diakritiky (e-mailové přílohy posílám občas s diakritikou, když vím, že to protistrana otevře), malým a bez mezer.
A u sebe na počítači mám všechno pojmenované podle pravidel pravopisu :) (kromě souborů souvisejících s programováním, jestli se tomu tak dá říkat).

(Teď se jenom děsím, kolik jsem tady nasekal chyb.)

Diakritice v názvech souborů se vyhýbám. Ono to při různých jazycích a kódováních vede jen k problémům, viz [81].

"Problém OOo a TB" nehodnlám řešit. Obecně je ale používání pojmenování souborů jinými než [a-z], [A-Z], [0-9] a znaky ".-_" špatné a to nejen v češtině ;-) ... a jestli s tím nesouhlasíte tak se zkuste zamyslet nad tím na co je vlastně takový název souboru dobrý :-D

Uf, nečetl jsem všechny komentáře. Ale musím se přiznat, že diakritiku v názvech souborů zásadně nepoužívám a každému radím to samé. Proč? Je s tím víc problémů než užitku.

Neříkám, že to není problém a že by se neměl řešit. Ale strkat hlavu do písku a tvářit se, že prece máme ten unicode a tak to musí všude fungovat je velmi nezodpovědný přístup. Když vám to funguje na vašem počítači s vaším nastavením, je to cool, ale posílat někomu takové soubory je zvěrstvo.

Osobně mně absence diakritiky vadí třeba při chatu, v diskusních fórech apod. V názvech souborů ji vážné nepotřebuju.

Podle mě se musí svět počítačů přizpůsobit - navíc není problém, že by to nešlo, ale že se s tím často prostě nepočítalo: hodně aplikací i protokolů pochází z anglofonního prostředí. Takže řešení je rozhodně postupně opravovat všechny tyto chyby (neboť to *jsou* chyby) a nenutit uživatele psát "cesky".

[77] Děláte jako kdyby UTF-16 byla na manipulaci nějaká obzvláštní lahůdka. :-) Smiřme se s tím, že od příchodu Unicode je spousta operací s textem složitá nezávisle na reprezentaci. *Ne*použití UTF-8 *nic nezachrání*.

Argument PROTI:
No já nevím, jestli náhodou nebude problém v tom, že s názvem souboru se nepřenáší informace o použitém kódování. A chudák počítač (programátor), to pak musí věštit z "křišťálové koule"(zkoušet nejčastější).
Jirka

[86] Počítač je pouze nástroj a lidi se musej s ním naučit zacházet
[84] Název souboru není nic víc, než jeho jednoznačný identifikátor.

Osobně víc než Unicode zápis se mi líbí zápis znaků v HTML pomocí entit. Sice to na první pohled vypadá příšerně, když zkoumáte zdrojový kód, ale na druhou k takovémuto zápisu stačí pouze sekvence základních 195 Ascii znaků (bez řídicích kódů) a pak by se klidně mohly do jména dávat i hvězdičky, zpětná lomítka a podobně. Že by to protáhlo jméno souboru? No ... já myslím, že za odstranění problémů by to stálo. A zas o tolik delší než Unicode sekvence to není. Kdo by měl podporu diakritiky, případně jiných znakových sad, tomu by se příslušné znaky zobrazily, kdo by ji neměl, tomu by se zobrazily znaky tvořící entitu.

V názvech souborů je nejlépe používat jen znaky, které lidé na celém světě dokáží bez problémů napsat, a které nedělají problémy shellům a skriptům. A to jsou [1-9a-zA-Z_\.] V opačném případě se zadělává na problém.

zasadnenesouhla­simsjakymikoliz­bytecnymiznakyk­terenemajivypo­vidacihodnotu­ajejichpouzitim­kdekoli
:)

[89] [84] Název souboru není nic víc, než jeho jednoznačný identifikátor.
nemohu si pomoct, ale musím si rýpnout. Nebylo by tedy lepší místo lidského jazyka použít nějaký vhodnější jednoznačný identifikátor? (hint. například md5 sumu obsahu souboru) Tím by přestal být problém s Unicode :-D

Ale teď trochu vážněji, pokud si uživatel všude konzistentně používá jednotné kódování, tak pak ať si klidně používá v názvech souborů co chce a programy by mu to měly umožnit. Za předpokladu, že ten program ví, jaké kódování má dostat a také takové dostane! Pokud se ovšem začne sdílet, tak je lepší zůstat pěkně u ascii...

Komentář 77 mi stále čeká na schválení. Skvělý systém :). Takže ještě jednou, bez hyperlinků:
[71] MSVC není plně kompatibilní s ISO C99 (což nakonec gcc také ne), a plná kompatibilita MSVC s C99 není plánována. Je to proto, že MS používá C++, a C je mu tedy celkem volné. MSVC je kompatibilní s ANSI/ISO C++ International Standard (ISO/IEC FDIS 14882), případné odchylky jsou dokumentované. Obecně byste měl používat funkce daného frameworku (MFC, ATL), případně Win32 API (ve všech případech budete používat Unicode stringy). Dnes se samozřejmě preferuje C#, nebo C++/CLI (aka ECMA-372).

[74] Ten tar je sice pěkně v souladu s POSIXem, ale nefunkční, že.

Já v Qt nepíšu, ale z toho, že obsah adresáře dostanu jako Unicode string, soubor otevírám s reference na Unicode string, a glibc (coby vrstva skrz kterou musí volání propadnout) používá char-based string, je to zjevné. Konverze zobrazení well-formed UTF-8 code unit sequence na UTF-32 je identita. Problémem je samozřejmě ill-formed UTF-8 code unit sequence. Nejsem uživatelem Linuxu, ale mám za to, že pokud máte název souboru v 8859-2, tak Qt aplikace zobrazí otazníky místo ill-formed sequence, a se souborem pak neumí pracovat (jestli chcete, zkuste si to, a podělte se o výsledek).

Jak jsem už psal, kdybyste měl třídu pro jména souborů, tu konvertoval na Unicode string, a ten nedej bože zase převáděl na nějakou třídu pro normalizovaný Unicode, tak byste zbytečně framework komplikoval. Qt, glibc, .NET, Win32 a další běžně skladují jména souborů ve stringu. Qt by přišlo ke specialitce, která by znamenala třeba při krmení GUI jmény souborů držet zvlášť původní objekty jmen souborů, zvlášť stringy, a (jak jste navrhoval) ještě zvlášť normalizované Unicode stringy. To je přece značný overhead, a příšerný opruz pro autora aplikace.

A teď zkusím ty linky:
http://msdn.microsoft.com/en-us/library/45aft37a.aspx
http://msdn.microsoft.com/en-us/library/3bstk3k5.aspx
http://en.wikipedia.org/wiki/C%2B%2B/CLI
http://en.wikipedia.org/wiki/Active_Template_Library
http://gcc.gnu.org/c99status.html

[82] Popsaný problém s "mrtvým" adresářem zřejmě vznikl úplně jinak. NTFS umožňuje mimo jiné case sensitivity, jména souborů s mezerami na začátku či na konci apod. Taková jména ale nedovoluje Win32. Pokud například na disku vytvoříte soubory "můj dopis.doc" a "Můj Dopis.doc" (což Win32 nedovolí), máte problém. Podobně "a.txt " skončí problémem. A jak takové soubory vytvořit? Třeba pomocí Services for UNIX.
Obecně název v Unicode nemůže vést k tomu, že by aplikace používající Unicode API na tento soubor nemohly přistoupit.
Smutné ale je, že když výše uvedené nevíte, budete zřejmě do smrti žít v bludu, že názve souboru v Unicode může způsobit situaci, kdy na soubor nelze přistoupit. Mimochodem podobným způsobem vzniklo náboženství :)

[89] To je ale problém implementace Unicode na unixech (na který opakovaně upozorňuji).

Jsem ještě ze starých dob vycvičený, abych neukládal soubory s diakritikou a mezerami v názvu, ale tudy samozřejmě cesta nevede.

Thunderbird pro linux má ještě další problém s diakritikou a to, že není schopen připojit k mailu přílohu, která je zadaná jako parametr z příkazové řádky a obsahuje v názvu znaky národní abecedy. Respektive ji připojí, ale název je pokažený, a tak si při pokusu o odeslání takového mailu stěžuje, že soubor nemůže najít.

93> Problémem je samozřejmě ill-formed UTF-8 code unit sequence.

No prave. Psat programy tak, ze pracuji jen s podmnozinu moznych souboru na filesystemu je chyba.

diakritika, spec znaky, mezery, veskera interpunkcni znamenka .. to vse nema v nazvech souboru/adresaru co delat.

nicmene na vychovu neverim ..

[98] Ona je hlavně chyba, že se na FS míchají názvy v různých kódováních. Tohle je pak už jen důsledek kompromisů, ke kterým to nutně vede.

[80] Myslel jsem to primárně na programy, které si člověk nechá vyvinou na zakázku (dnes, v ČR), tam bych problémy s diakritikou v názvech souborů netoleroval a kdyby mi dodavatel řekl: "tak si to pojmenovávejte bez háčků, né.", tak bych ho asi něčím umlátil :-)

U historických nebo zahraničních programů, kde autor nemá v ČR ani pořádně zastoupení (a možná o náš trh ani nestojí) je to samozřejmě problematičtější. Pokud takový program nemá konkurenci, musí se bohužel dělat kompromisy a ústupky. Ale obecně dávám přednost používání češtiny (a mezer a dalších znaků) a když něco nefunguje, tak hlásit chyby a pořád "otravovat" autory programů. Protože to je jediná cesta, jak zlepšit situaci. (BTW: jsem vývojář, ne nějaký zmlsaný uživatel :-) ). Když tu někdo píše, jak nepoužíváním diakritiky předchází problémům, tak je to celkem úsměvné - nejvíce našim problémům by se předešlo, kdybychom vůbec nepoužívali počítače :-)

"Jako to, že něco má nějakou vlastnost, ještě neznamená, že se tato vlastnost musí používat."

Tohle mi přijde jako dost mizerný stav, když něco naoko funguje, ale lidi mají strach to používat, protože to vlastně zas tak moc nefunguje...

Takže: češtinu používám a nemám s ní téměř problémy, taky díky UTF-8. A když se náhodou problémy objeví, je lepší nestrkat hlavu do písku (odsouvat problém), ale chyby hlásit, případně se je pokusit sám řešit.

[2] klingoncina sa pise s kratkym o

Řekl bych, že poděkujme Robertu Vojtovi za jeho konstruktivní přístup v http://cs.openoffice.org/servlets/ReadMsg?list=users&msgNo=7399

Já osobně pokud možno neprogramuji a když už nedej bože ano, tak už jen a pouze v sebeobraně. Názvy souborů a adresářů si vytvářím zásadně bez diakririky už jen kvůli tomu, že když chci soubor poslat jako přílohu někomu do míst, kde by bylo možno očekávat s diakritikou problémy, tak mi připadne rozumnější se jim již předem vyhnout. Také se můžete snažit vnutit datový soubor programu, který vznikl bůh ví kdy a ještě uznává jen DOSové konvence pro název souboru jako byla 8.3 a pod. Zkrátka chce-li někdo užívát diakritiku v názvech souborů, tak by zatím pořád ještě měl brát v potaz, zda s tím nemůže vzniknout problém. Většina z nás ale bohužel nechce nic moc vědět a tudíž není ani schopna ani ochotna přemýšlet o něčem předem.
Doufám ale, že je jaksi mimo diskusi postulát, že další vývoj operačních systémů a aplikací by měl směřovat k tomu, že použití diakritiky jakkoliv, kdekoliv a kdekoliv by mělo přestat být problémem.
Člověku, který se dotazoval na chybu při práci s přílohami, jejichž název obsahuje diakritiku, bych do doby nežli bude opraven OpenOffice tak aby tyto potíže nenastávaly aby zkusil využít volbu menu a přílohu si uložil s názvem bez diakritiky na pohodlně přístupné místo a pak na ní klikl. Jako provizorní řešení do doby nežli bude problém odstraněn by to mělo postačit a být rychlejší nežli zavírání všech oken a znovu spouštění.

necetl jsem celou diskuzi, tak doufam ze uz to tu nebylo...
Diakritiku nepouzivam hlavne kvuli problemum pri prenosu a pri pouziti treba v mp3 prehravacich.
Pro pripad ze se ke me dostanou soubory s diakritikou pouzivam programek na jeji odstraneni:
http://www.pspad.com/cz/remdiak.htm

Tohle je pro wokna, v linuxu jsem to resil scriptikem pomoci recode. Dokonce se me tak povedlo spravit uz rozsypany kodovani, musel jsem pouzit 2 konverze za sebou.

diakritiku v názvech nepoužívám a to proto, že své soubory posílám kolegům ve Francii, USA, Indii a Číně. Nevím, jak by číňané válčily s českými znaky. Nicméně pokud chce diakritiku používat, ať ji používá a toto je jednoznačně chyba, která by se měla v OO opravit.

Čína, Francie, USA... no a?

http://disk.jabbim.cz/xkucf03@jabber.cz/diakritika.png

;-)

Zasadne jsem proti, diakritiku radeji nepouzivam, protoze s tim jsou nekdy problemy, a nechci je pak resit. Pravda je, ze v tuto chvili slouzim opravdu ja pocitaci a nedokonalostem jeho systemu, na vyber vsak nemam, protoze nekdy to opravdu nejde jinak, takze vitezi mensi zlo. A hlavne jsem se i kvuli komunikacnim programum, mailum, kodovani atd. naucil psat bez diakritiky, pokud se nejedna o formalni komunikaci, takze by me ani nenapadlo pojmenovavat soubory s diakritikou.

[107] No to je jako demonstrace z dob Windows NT 3.1 ;). Ano, tak to má vypadat.