Odpověď na názor

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.