Nespravne interpretovanie UTF-8 zdrojaku stranky http://www.pspad.com/cz/

Problem: PSPad ma problem s identifikaciou/zobrazenim zdrojoveho textu homepage stranky www.pspad.com pomocou UTF-8.

Testovana verzia PSPad-u: 4.5.3 (2298).

Postup:
1) v Opere (9.63) otvorit stranku www.pspad.com
2) v Opere - File -> Save As... ulozit ako html
3) otvorit subor pomocou PSPad-u

Skusal som rozne nastavenia:
A) ZAPNUTA 'Automaticka detekce CP' + zaskrtnute 'Format -> UTF-8'
B) VYPNUTA 'Automaticka detekce CP' + zaskrtnute 'Format -> UTF-8'
C) VYPNUTA 'Automaticka detekce CP' + zaskrtnuty iny charset - napr. "(Latin II CP852)"

Takisto som skusal postup:
I) zmenit nastavenie 'Format -> <charset>' (napr. na UTF-8, UTF-16, Latin II',...)
II) pokusit sa o reload suboru pomocou Ctrl+R - na dotaz 'Pokracovat?' som odpovedal 'Ano'

Ziskane zobrazenia pre jednotlive charsety:

Pre cp1250:
- v status bare sa zobrazovalo "Kodovani: Windows (CP1250)"
- zobrazenie: "PSPad - free unicode vývojářský editor určený pro HTML, ..." (vyrez z title)

Pre 'Kamenickych (CP895)', rovnako ako aj 'Latin II (CP852)', rovnako aj 'ISO 8859-2', rovnako aj 'UTF-8':
- v status bare zostavalo STALE "Kodovanie: Windows (CP1250)"
- zobrazenie: rovnake ako pre cp1250

Pre 'UTF-16 LE' rovnako ako aj pre 'UTF-16 BE':
- v status bare bol spravne uvedeny zvoleny charset
- zobrazovali sa (spravne) stvorceky.

Pripominam, ze pocas testovania bola volba 'Automaticka detekce CP' VYPNUTA. Aj napriek tomu som pozoroval, ze po reload-e (Ctrl+R) sa v status bare zmenila nastavena hodnota na nespravnu 'CP1250'.

Chyba teda poukazuje na to, ze sa mozno nespravne zapaja nejaka 'heuristika' pri detekcii CP, hoci je tato volba aktualne vypnuta.

V suvislosti s tymto problemom ma napada jedna moznost: neslo by implementovat prikazy typu 'Reload using charset...' - uzivatel by si vybral charset, pomocou ktoreho chce subor interpretovat, a po potvrdeni by sa aktualny subor znovunacital pouzitim daneho charsetu (samozrejme by sa museli este korektne ponastavovat vsetky interne atributy/nastavenia, aby sa nadalej s danym dokumentom pracovalo zvolenym charsetom, ale potlacili by sa akekolvek validacie/kontroly, ci uzivatelom zvoleny charset je naozaj v subore pouzity). Myslim, ze castokrat by tato volba mohla byt velmi uzitocna.

falkon:

...
V suvislosti s tymto problemom ma napada jedna moznost: neslo by implementovat prikazy typu 'Reload using charset...'

Prace s kodovanimi cloveka nekdy vskutku prekvapi, ona funkce ale uz nastesti je dostupna:
V menu Format se vybere kodovani
nasledne Soubor :: Otevrit special :: Otevrit znovu (Ctrl+R) a odkliknout varovani, ze se ztrati neulozeny obsah.

vbr

Edited 1 time(s). Last edit at 01/10/2009 21:05 by vbr.

vbr:

V menu Format se vybere kodovani
nasledne Soubor :: Otevrit special :: Otevrit znovu (Ctrl+R) a odkliknout varovani, ze se ztrati neulozeny obsah.

Ano, rovnakym postupom som skusal 'otvorit' (reloadovat) dany dokument pre vsetky dostupne kodovania (ako je popisane v prvom poste), no vysledok bol negativny :(

Osobne (subjektivne) by som tipoval, ze pri normalnom otvoreni suboru sa vykonava nejaky test/heuristika na odhad/validovanie 'pozadovaneho' kodovania, kde to slovicko 'pozadovane' znamena "niekde aktualne nastavene aplikaciou PSPad". A reload pomocou spominanej volby (podla mna) v podstate len vyuziva rovnaku rutinu ako pri otvoreni suboru prvykrat - jednoducho sa pouzije uz hotovy (naprogramovany) mechanizmus.

Ono prave to 'nastavenie aplikacie PSPad', ake kodovanie ma pouzit pre otvorenie suboru je (podla mna) v aktualnej verzii dost 'zamlzene' - nie je uplne presne, jednoznacne a intuitivne definovane (teda aspon mne nie su podrobne pravidla zname). Je moznost mat akusi 'autodetekciu CP', je moznost v menu 'Format' zaskrtnut nejake kodovanie, ktore sa ale berie do uvahy (asi len) pre nove subory (a to este k tomu asi len za predpokladu, ze je vypnuta volba 'Autodetekcie CP'), a casto sa tato volba lisi od realneho stavu - toho zobrazovaneho v status bare. Navyse - ako ostatne popisuje tento bug report - existuju situacie, ked ani tymto postupom proste nie je mozne aplikaciu PSPad presvedcit (a donutit), aby otvorila subor v pozadovanom kodovani.

Preto som myslel zbrusu novu funkciu - nieco v tom zmysle, ako keby uzivatel povedal aplikacii "vyprdni sa na vsetky kontroly a otvor (interpretuj) mi tento dokument v MNOU pozadovanom kodovani!". Pretoze uzivatel by podla mna mal mat moznost byt 'panom situacie' (ked vie, co robi).

Tohle bych nesvadel na PSPad. Podivejte se d toho souboru, ktery je ulozen na disku. Opera si tam pridala na zacatek svou cast, ktera je kodovana v Base64

UTF-8 je matematicke kodovani a je dost haklive na to, jestli je dodrzena spravna posloupnost znaku.

Pri reloadovani se nedela zadna detekce. Pouze se po otevreni v prislusnem kodovani zkontroluje, zda po dekodovani nezustal prazdny soubor - napr. chyba v UTF-8 obsahu. Pokud je vysledek prazdny, PSPad to otevre primo bez jakehokoliv prekodovavani.

pspad:

Opera si tam pridala na zacatek svou cast, ktera je kodovana v Base64

Priznam sa, ze do suboru som sa dival, ale ziadnu cast v Base64 som nevidel. Subor sa mi zda (po letmej kontrole) ako korektne HTML. Tato chyba sa ale prejavuje aj pri prezerani zdrojoveho kodu stranky (pouzivam PSPad ako prehliadac zdrojoveho kodu nastaveneho v Opere), a tam si predpokladam Opera nevklada ziadne interne bloky. Konieckoncov, aj keby tam nejaky blok v Base64 bol, tak Base64 pouziva len ASCII znaky, a teda je 'podmnozinou' UTF-8 - kolidovat by s nim teda nemalo.

Kopiu suboru, ktory vykazuje chybu som zpristupnil na stoki.pasique.sk.

Zvlastne je, ze ked tento patricny subor otvorim napr. v prehliadaci Lister (interny prehliadac programu Total Commander), tak po zvoleni kodovania UTF-8 sa obsah javi byt zobrazeny spravne.

Tak ak este mate zaujem venovat chvilu casu tomuto problemu, tak prosim skuste Vy u Vas otvorit zmienovany subor, a postupovat podla popisanych krokov - ci dosiahnete spravneho zobrazenia pouzitim UTF-8. (len pripominam, ze ja mam verziu 4.5.3 (2298)).

Nuz a uplne na koniec - ak to naozaj nie je chybka v PSPad-e, tak mozno bude chybka niekde na zmienovanej webstranke. Asi nie je nijak fatalna, ale zaujimava by byt mohla.

"Kapitanov dennik, dodatok:"

Myslim, ze chybu som odhalil - zmienovany subor (stoki.pasique.sk) obsahuje totiz na riadku 61: "/* 468x60, vytvoøeno 28.7.08 */" a na riadku 72: "/* 468x60, vytvoøeno 28.7.08 */" - oba retazce obsahuju pismeno 'ř' v kodovani CP1250.

To ma privadza opat na otazku, preco dva nekorektne znaky v subore zabrania PSPad-u, aby pouzil kodovanie, ktore pozaduje uzivatel? A znovu privadza na myslienku, ake skvele by bolo mat prave nejaku moznost prikazu, ktora by PSPad donutila pouzit to, co uzivatel ziada. A keby nasiel nekorektne sekvencie (znaky/byte-y), tak by ich napr. vypustil (alebo konvertoval na '?', alebo nieco podobne). Tak by PSPad ziskal novu funkcionalitu, ze by sa pomocou neho dali filtrovat/opravovat/konvertovat subory, ktore maju v sebe pomiesane znaky roznych kodovani a mnoho dalsieho...

Protoze jak jsem psal, UTF-8 je matematicke kodovani a musi byt dodrzeny zasady.

S tim ulozenim souboru se omlouvam, ulozil jsem jej jako MHT, takze vcetne obrazku. Ty jsou pak skutecne zakodovane.