Co presne myslite tim ASCII? Opravdu ASCII, tj. CP437, ci snad jeste i CP1252? Nebo single-byte kodove stranky? Nebo snad vsechny "lokalni" kodove stranky podporovane Windowsy? Pokud to posledni, pak to bohuzel neni pravda. CJK (Cinstiny/Japanstina/Korejstina - CP936/950/932/949) jsou multibyte a tam se snadno muze stat, ze nactete kus znaku. Smutnou pravdou je, ze timto neduhem trpi i Salamander (viz reporty na techto forech).zarevak wrote:PS: UNICODE je v současnosti moje nejpotřebnější chybějící featura, ale protože jsem sám vývojář, vím, jaké komplikace to přínáší:
- V ASCII je každý znak jeden byte. V UNICODE jeden znak může být kódován mnoha byty po sobě a některé znaky mohou být zapsané různou kombinací jinak dlouhých řetězců. V ASCII se tedy nestane, že bych načetl jen kus znaku.
Tot otazkou, jak moc je tohle podstatne. Pokud jde o file-system, tak se bavime o UCS-2 a UTF-16.zarevak wrote:V UNICODE můžete o kus znaku přijít a změnit tak význam textu! (např: háček nad písmenem)
Pokud jde o surrogates (tj. znaky mimo BMP0 a UCS-2): Nepocitam-li mrtve jazyky a ruzne symboly, tak se to muze stat jen u mene beznych znaku CJK. A tak IMHO neni nutne ihned resit symboly a mrtve jazyky. CJK Salamander stejne neumi poradne ani ted.
Pokud jde o decomposed characters (tj. napr. zminene rozdeleni pismene a hacku), pak Windowsy by default pracuji s composed textem. Neznam Windows-based SW, ktery by generoval decomposed sekvence. Naproti tomu je pravda, ze Mac OS ve file-systemu preferuje decomposed verzi. Takze pri praci v heterogenich prostredich by mohlo dochazet k problemum. Ale opet, Salamander neumi ani ted CJK, coz je velmi podobny problem (stran vyskytu chybovych stavu a jejich osetreni vsak horsi).
Cim se toto lisi od lokalnich stranek?zarevak wrote:- Dále tu je otázka řazení, která je závislá na jazyce a v každém jazyce se řadí jinak:
CZ: A, ... C, Č, D, ... G, H, Ch, I, ...
EN: A, ... Ca, Ce, Ch, Ci, Cz, D, ...
ES: A, ... Ca, Ce, Ci, Cz, Ch, D, ....
Pokud jde o filesystem, tak ma cenu resit pouze UCS-2 (WinNT4) a UTF-16 (Win2K+). Vsechna ostatni kodovani se tykaji *pouze* vieweru a zpracovani obsahu souboru (find, compare, File/Convert). At tak ci onak, viewer+find+file compare+convert absolutne nesouvisi s podporou Unicode ve file systemu, verzi prekladace ani verzi Windows, na kterych by takovy Salamander mel fungovat.zarevak wrote:- UNICODE existuje v různých kódováních: UTF-8, UTF-16, UTF-32, ...
IMHO v soucasne dobe je problem viewer+find+file compare+convert mnohem dulezitejsi nez Unicode ve filesystemu, jedna se o izolovany problem a (ciste teoreticky) to muze prinest drivejsi verze Salamandera nez to druhe.
"Dulezitost" rozsirencyh CJK znaku a fakt, ze bez nich "nelze zit", IMHO ilustruje i fakt, ze byly pridany az do Unicode 3.1 v breznu 2001.