Jak to vypadá s vývojem? (+Unicode debata)

Zde můžete volně diskutovat o programu Altap Salamander. Ptejte se, odpovídejte a vyjadřujte své názory. Prosíme, nevkládejte sem hlášení problémů či návrhy na nové funkce.
Jan Patera
Plugin Developer
Plugin Developer
Posts: 707
Joined: 08 Dec 2005, 14:33
Location: Prague, Czech Republic
Contact:

Post by Jan Patera »

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.
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:V UNICODE můžete o kus znaku přijít a změnit tak význam textu! (např: háček nad písmenem)
Tot otazkou, jak moc je tohle podstatne. Pokud jde o file-system, tak se bavime o UCS-2 a UTF-16.
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).
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, ....
Cim se toto lisi od lokalnich stranek?
zarevak wrote:- UNICODE existuje v různých kódováních: UTF-8, UTF-16, UTF-32, ...
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.
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.

Jan Rysavy
ALTAP Staff
ALTAP Staff
Posts: 5197
Joined: 08 Dec 2005, 06:34
Location: Novy Bor, Czech Republic
Contact:

Post by Jan Rysavy »

Jan Patera wrote: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.
To určitě není pravda, stačí projet toto fórum a emaily, které dostáváme od uživatelů. Většina žádá právě podporu pro Unicode na úrovni souborového systému. Nechci zlehčovat význam Unicode ve viewer+find+file compare+convert, ale určitě to (podle uživatelů Salamandera) není hlavní problém.

Unicode File Comparator je mimochodem téměř dokončen, bude součástí Salamandera 2.52. Ostatní později.
Jan Patera wrote:Pokud jde o filesystem, tak ma cenu resit pouze UCS-2 (WinNT4) a UTF-16 (Win2K+).
NT4 podporovat nebudeme vůbec, Unicode verze Salamandera tam nepoběží. W2K a UTF-16, tam pouze poznámka, že nejde o UTF-16, viz http://blogs.msdn.com/michkap/archive/2 ... 48699.aspx

Jan Patera
Plugin Developer
Plugin Developer
Posts: 707
Joined: 08 Dec 2005, 14:33
Location: Prague, Czech Republic
Contact:

Post by Jan Patera »

Jan Rysavy wrote:
Jan Patera wrote: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.
To určitě není pravda, stačí projet toto fórum a emaily, které dostáváme od uživatelů. Většina žádá právě podporu pro Unicode na úrovni souborového systému. Nechci zlehčovat význam Unicode ve viewer+find+file compare+convert, ale určitě to (podle uživatelů Salamandera) není hlavní problém.
Udelal jsem si malou statistiku vyhledanim slova Unicode na forech.
Nazory nekterych lidi se mohou od te doby lisit, mohl jsem neco v rychlosti prehlednout:

1) viewer a spol. vadi (15): Cincura.net, DavidGandi, Stepan, StepanD76, sodel, iX, Hawkwind, theRube, dprice, Raptor, Eric, bback, Celoush, Stefan, Jan Patera
2) file system vadi (19): JirkaV, JtMA, prkno, Mindaugas, aTraveller, troubled, Waffen MS, Shanyuen, Zealkane, Zarevak, fraktik, gryphon, mym, roman2, TOMAS, Viktorka, joeK, omega, Vincero
3) nefunkcni CJK vadi (4): anBug?, ksworks, theBat, unknown Guest
4) nespecifikovana podpora nebo oboje Unicode schazi (2): pasha, dbidlo

Rad bych pripomnel, ze radu "zadosti o podporu Unicode" se podarilo vyresit nastavenim spravne kodove stranky pro ne-Unicodove aplikace. Takove uzivatele jsem snazil vyse nezapocitavat.

Jan Rysavy
ALTAP Staff
ALTAP Staff
Posts: 5197
Joined: 08 Dec 2005, 06:34
Location: Novy Bor, Czech Republic
Contact:

Post by Jan Rysavy »

Docela se nám množí žádosti z firem, které obchodují (ať už nákup, prodej nebo realizace zakázek) například s Ruskem, Japonskem, atd. Jde o firemní zákazníky, kteří toto fórum nečtou a ani sem nepíší, obrátí se přímo na email.

U nich bohužel nastavení kódové stránky nic neřeší, protože potřebují kombinace, například čeština a ruština.

Mají ve svém vnitro firemním prostředí potřebu sdílet soubory obsahující v názvech znaky z různých kódových stránek.

Tyto emaily nemáte k dispozici, ale mohu vás ujistit, že jich je hodně.

Jan Rysavy
ALTAP Staff
ALTAP Staff
Posts: 5197
Joined: 08 Dec 2005, 06:34
Location: Novy Bor, Czech Republic
Contact:

Post by Jan Rysavy »

Jan Patera wrote: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.
Právě že míra podpory pro viewer+find+file compare+convert se bude buď lišit systém od systému nebo budeme muset sehnat obecnou Unicode knihovnu. Mrkněte na přiložený Unicode soubor. Otevřete ho v Notepadu pod Windows XP a Windows Vista.

Pokud budete pomocí Ctrl+F hledat retezec "fi" (dva znaky, ne slitek), Windows XP najdou jeden výskyt, zatímco Windows Vista najdou i slitek fi. Pokud hledáte pouze znak "f", Windows Vista nenajde žádný výskyt. Zkrátka rozdíly v implementaci Unicode v jednotlivých verzích Windows tu jsou a my je budeme muset nějak řešit.
Attachments
unicode_slitek.rar
(114 Bytes) Downloaded 363 times
slitek.png
slitek.png (17.07 KiB) Viewed 12326 times

cincura.net
Posts: 593
Joined: 09 Dec 2005, 17:30
Location: a step further
Contact:

Post by cincura.net »

Jan Rysavy wrote:Unicode File Comparator je mimochodem téměř dokončen, bude součástí Salamandera 2.52. Ostatní později.
To je ale urcite pozitivni zprava. :) V nouzi, mam timto i viewer. 8)
Jiri {x2} Cincura

Jan Patera
Plugin Developer
Plugin Developer
Posts: 707
Joined: 08 Dec 2005, 14:33
Location: Prague, Czech Republic
Contact:

Post by Jan Patera »

Jan Rysavy wrote:
Jan Patera wrote: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.
Právě že míra podpory pro viewer+find+file compare+convert se bude buď lišit systém od systému nebo budeme muset sehnat obecnou Unicode knihovnu. Mrkněte na přiložený Unicode soubor. Otevřete ho v Notepadu pod Windows XP a Windows Vista.

Pokud budete pomocí Ctrl+F hledat retezec "fi" (dva znaky, ne slitek), Windows XP najdou jeden výskyt, zatímco Windows Vista najdou i slitek fi. Pokud hledáte pouze znak "f", Windows Vista nenajde žádný výskyt. Zkrátka rozdíly v implementaci Unicode v jednotlivých verzích Windows tu jsou a my je budeme muset nějak řešit.
IMHO marginalni problem. Slitky se pouzivaji v DTP a podobnych softech. Nikoli v logach, .reg souborech, rucne psanych textech a jinych dokumentech, ktere lze rozumne prohlizet v internim prohlizeci. Prvni verze podpory Unicode ve vieweru tohle IMHO nemusi vubec resit. Navic tech slitku neni mnoho. Decomposed characters je jina kapitola, nicmene v ramci jednoduchosti by to mozna taky nemuselo byt v prvni verzi.

Jan Patera
Plugin Developer
Plugin Developer
Posts: 707
Joined: 08 Dec 2005, 14:33
Location: Prague, Czech Republic
Contact:

Post by Jan Patera »

Jan Rysavy wrote:
Jan Patera wrote:Pokud jde o filesystem, tak ma cenu resit pouze UCS-2 (WinNT4) a UTF-16 (Win2K+).
W2K a UTF-16, tam pouze poznámka, že nejde o UTF-16, viz http://blogs.msdn.com/michkap/archive/2 ... 48699.aspx
Dekuji za upresneni. Takze UTF-16 az od WinXP.
Jan Patera wrote:"Dulezitost" rozsirenych CJK znaku a fakt, ze bez nich "nelze zit", IMHO ilustruje i fakt, ze byly pridany az do Unicode 3.1 v breznu 2001.
Jeste bych pro ilustraci dulezitosti doplnil, ze wcsrev() v MSVC8.0 SP1 (aka 2005) z konce roku 2006 pracuje pouze s UCS-2, takze stringy v UTF-16 poskozuje. Naopak mbsrev() korektne pracuje s CJK uz nejmene v MSVC6, spise uz nekde kolem MSVC4 nebo i drive...
Last edited by Jan Patera on 31 Jul 2008, 10:34, edited 1 time in total.

Jan Patera
Plugin Developer
Plugin Developer
Posts: 707
Joined: 08 Dec 2005, 14:33
Location: Prague, Czech Republic
Contact:

Post by Jan Patera »

Jan Rysavy wrote:Docela se nám množí žádosti z firem, které obchodují (ať už nákup, prodej nebo realizace zakázek) například s Ruskem, Japonskem, atd. Jde o firemní zákazníky, kteří toto fórum nečtou a ani sem nepíší, obrátí se přímo na email.

Mají ve svém vnitro firemním prostředí potřebu sdílet soubory obsahující v názvech znaky z různých kódových stránek.
To je dobry argument. U nas ve firme mi tohle taky schazi.
Ja jsem se spise snazil poukazat na to, ze se jedna o 2 oddelene problemy, z nichz 1 je IMHO jednodussi na implementaci a Altap by mel zauvazovat, zda za nekolik let dokonci verzi X.Y, kde bude oboje predstaveno naraz, nebo zda to rozdeli do 2 kroku a 2 verzi.

Jan Rysavy
ALTAP Staff
ALTAP Staff
Posts: 5197
Joined: 08 Dec 2005, 06:34
Location: Novy Bor, Czech Republic
Contact:

Post by Jan Rysavy »

Jan Patera wrote:IMHO marginalni problem.
To že Notepad pod Windows Vista nenajde "f" v souboru, kde tento znak je (nemyslím teď slitek), to nepovažuji za marginální problém. Tento jednoduchý případ jsem uvedl pouze jako ilustraci v jakém stavu podpora pro Unicode ve Windows je, problémů samozřejmě bude celá řada.
Jan Patera wrote:Dekuji za upresneni. Takze UTF-16 az od WinXP.
Máš nějaké reference kde to Microsoft popisuje? Já mám silný dojem, že uvedené prohřešky proti Unicode v NTFS platí také pro Windows XP a Vista.
Jan Patera wrote:Jeste bych pro ilustraci dulezitosti doplnil, ze wcsrev() v MSVC8.0 SP1 (aka 2005) z konce roku 2006 pracuje pouze s UCS-2, takze stringy v UTF-16 poskozuje.
Je na tom MSVC 2008 lépe? Salamandera budeme překládat právě v MSVC 2008 a to samé bude počítám platit pro pluginy. Řešit podporu pro starší překladače asi nemá valný význam, když MSVC 2008 EE rozdává Microsoft zdarma.
Jan Patera wrote:Ja jsem se spise snazil poukazat na to, ze se jedna o 2 oddelene problemy, z nichz 1 je IMHO jednodussi na implementaci a Altap by mel zauvazovat, zda za nekolik let dokonci verzi X.Y, kde bude oboje predstaveno naraz, nebo zda to rozdeli do 2 kroku a 2 verzi.
Naprostý souhlas.

User avatar
zarevak
Plugin Developer
Plugin Developer
Posts: 789
Joined: 04 Feb 2006, 16:49
Location: Prague, Czech Republic

Post by zarevak »

Jan Patera wrote: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).
Ano, myslel jsem obecně single byte kódování. Nepřemýšlel jsem nad tím, zda někdo bude rozebírat význam tohoto tvrzení. Se Salamanderem a ne-unicode MBCS řešeními nemám zkušenosti.
Jan Patera wrote:
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)
Tot otazkou, jak moc je tohle podstatne. Pokud jde o file-system, tak se bavime o UCS-2 a UTF-16.
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).
Přesně tak, myslel jsem decomposed characters. Některé znaky v precomposed verzích neexistují, takže preference/nepreference, budou se vyskytovat
Jan Patera wrote:
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, ....
Cim se toto lisi od lokalnich stranek?
Toto (collation) se stránkami kódování vůbec nesouvisí. Toto souvisí s tím, jak uživatelé očekavájí, aby se jejich soubory v panelech řadili. Angličan nikdy nebude hledat Ch za H nebo před D! A to jsem nezmínil, že některé dvojznaky jsou v některých jazycích schodné s jednoznakovým vyjádřením a v jiných ne. (Globálně i případ "fi")
Jan Patera wrote:
zarevak wrote:- UNICODE existuje v různých kódováních: UTF-8, UTF-16, UTF-32, ...
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.
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.
Podpora UNICODE v Salamanderovi by se dala rozdělit na 3 části:
1) UI Salamandera (pro lokalizaci) - čistě v kontrole Altapu, takže skoro nulové problémy
2) Viewery
3) souborý systém:
- jak zmiňoval Jan Ryšavý, tak na NTFS jsou názvu uloženy v pseudo-UTF-16 - názvy souborů mohou obsahovat dosud neplatné znaky pro "budoucí kompatibilitu". Vzniká tak problém, co s takovými soubory. Například nelze takové řetězce řadit, protože není definováno, co je dříve. SiaO: CompareString prefers meaningful strings
- NTFS obsahuje soubor $UpCase, který pomáhá systému rozhodovat velikost písmen názvů souborů. Ve WinXP tato databáze obsahuje méně znaků než ve Vista a tak ve WinXP mohou legitimně vzniknout dva soubory lišící se jen ve velikosti písmen a ve Vistách vznikne problém..
- NTFS neví nic o precomposed a decomposed characters a lze tak vytvářet soubory stejných názvů. SiaO: Comparing Unicode file names the right way
Jan Patera wrote:"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.
Nevím, proč si spojujete UNICODE jen s CJK. Existuje mnoho jazyků, které bez UNICODE jednoduše nefungují. Osobně mám komplikace i s rozšířenými znaky západní evropy (konkrétně znak:"½", který se v Salamanderu zobrazí jako "1"), ruskými znaky, a protože se zajímám o Japonsko, tak s japonskými znaky.

EDIT 11:28: Odstraněna zmínka o vietnamštině, protože její znaky existují v precomposed verzi.

User avatar
zarevak
Plugin Developer
Plugin Developer
Posts: 789
Joined: 04 Feb 2006, 16:49
Location: Prague, Czech Republic

Post by zarevak »

Zapomněl jsem napsat jakýkoliv závěr mých myšlenek:
Salamander by měl umět pracovat s UNICODE, ale řešit všechny nedostatky systému je zbytečné. Kdo z uživatelů ví, že "fi" a "fi" jsou schodné? Větší problém bude s ekvivalitou "ss" a "ß", kterou něměčtí uživatelé budou očekávat, ale pokud však systém tuto ekvivalitu nepodporuje, tak jsou pravděpodobně zvyklí tento nedostatek obcházet a nebudou od Salamandera očekávat řešení.

:arrow: Takže Salamendera v UNICODE ano, ale (zatím?) s omezeními systému, na které jsme již zvyklí z ostatních programů.

Co se týká nečekaných řetězců, tak je důležité, aby Salamander zachoval možnost takové soubory mazat a přejmenovávat (jako teď), ale nemusi vědět, že za 10let UNICODE přijme klingonštinu, a podporovat tak její řazení již teď.

Jan Rysavy
ALTAP Staff
ALTAP Staff
Posts: 5197
Joined: 08 Dec 2005, 06:34
Location: Novy Bor, Czech Republic
Contact:

Post by Jan Rysavy »

Náš závěr je stejný. Na šikovnou knihovnu, která by nedostatky jednotlivých Windows přemostila jsme nenarazili (nebo šlo o hydry). Pokud někdo na něco zajímavého narazíte, dejte vědět.

Takže Salamander se zřejmě bude pod W2K, XP a Vista chovat různě.

Petr například narazil na některé podstatné Unicode API, které MS zveřejnili až ve Windows Vista (teď mi selhala paměť, o co šlo, něco kolem řazení?). Bude otázka, jak jejich absenci budeme pod W2K a XP řešit. To jsou právě ty kompromisy, které jsem zmiňoval na začátku vlákna, když se zvrhlo na tuto Unicode debatu :)

User avatar
zarevak
Plugin Developer
Plugin Developer
Posts: 789
Joined: 04 Feb 2006, 16:49
Location: Prague, Czech Republic

Post by zarevak »

Jan Rysavy wrote:Pokud budete pomocí Ctrl+F hledat retezec "fi" (dva znaky, ne slitek), Windows XP najdou jeden výskyt, zatímco Windows Vista najdou i slitek fi. Pokud hledáte pouze znak "f", Windows Vista nenajde žádný výskyt. Zkrátka rozdíly v implementaci Unicode v jednotlivých verzích Windows tu jsou a my je budeme muset nějak řešit.
Zkoušel jsem si tento příklad na testovacích Vistách (bez SP1), protože jsem se zděsil, že by nešlo najít F ve slově Filip!

Testovací sada:

Code: Select all

fi
filip
filipíny
floor
fi - slitek
fi
filip
filipíny
floor
Pokud hledám ve Windows XP, které slitek nepodporují, tak se chová, jak popisujete. Pokud hledám ve Vistách (v Notepadu), tak F se najde na prvních 4 řádcích. Za slitkem se nenalezne již žádné F - ani ve slově floor. :shock:
ss a ß trpí stejným problémem
Jan Rysavy wrote:... když se zvrhlo na tuto Unicode debatu
:oops:

Jan Patera
Plugin Developer
Plugin Developer
Posts: 707
Joined: 08 Dec 2005, 14:33
Location: Prague, Czech Republic
Contact:

Post by Jan Patera »

Jan Rysavy wrote:
Jan Patera wrote:Jeste bych pro ilustraci dulezitosti doplnil, ze wcsrev() v MSVC8.0 SP1 (aka 2005) z konce roku 2006 pracuje pouze s UCS-2, takze stringy v UTF-16 poskozuje.
Je na tom MSVC 2008 lépe?
Ja, na rozdil od tebe ;), VC9 nemam. Takze nevim.

Locked