PSPad UNICODE 4.5.0 (2134) beta Cesky

Diky, tohle je zatim nejuzitecnejsi informace, hlavne ten prvni chybovy vypis...
Problem bude nekde ve Win98 a praci s UNICODE seznamy

Ahoj,
vsiml jsem si ze pokud oteviram UTF-8 soubor ktery neobsahuje BOM tak PSPAD pokud si soubor otevru do HEXA na zacatku souboru zobrazi FFFE

Patrik

Tohle je neco jineho. Ty znaky jsou tam vzdy.
PSPad ted interne pracuje v UNICODE, takze v Editor -> HEX editor je vzdy Unicode, vcetne BOM

Ahoj,
to se mi ovsem zda byti k nicemu - protoze vetsinou potrebuju vedet jak soubor vypada ve skutecnosti. Dalo by se s tim neco udelat?

Patrik

Pokud si editor pred prepnutim do HEX modu provadi nejake interni upravy, pak prestava byt HEX mod pouzitelnym.
IMHO ma HEX mod slouzit k nahledu souboru tak, jak je fyzicky na disku a s tim nema zadne UNICODE nic spolecneho.

--
Vany
(PSPad 5.5.1.812 x32, W10h/p x64 en/cs)

A proto jsou v PSPadu 2 HEXa rezimy.
1. prime otevreni v HEXA editoru (Shift+Ctrl+O)
2. otevreni jako text, preneseni textu do HEXa editoru a preneseni obsahu zpet.

Podrobnosti v helpu

Otevrit soubor primo v HEXa editoru.
Proc je ten druhy zpusob udelanu, tak jak je je popsano v helpu.

No vsimol som ti taku malu chybku mozno zbytocnu, ale predsa...

Vsimol som si, ze vlavo dole ako je uvedene cislo riadka, cislo stlpca a pozicia a nakoniec v hranatej zatvorke je uvedeny pocet znakov a teda konecny pocet bajtov...

Lenze pri niektorych suboroch mi ukazuje odlisnu hodnotu ako ked si dam vlastnosti dokumentu a potom velkost {nie velkost na disku}...

A robi to len pri kodovani UTF-8, pri CP1250 je vsetko v poriadku...

Spravne. To cislo ukazuje pocet znaku v dokumentu, ne jeho fyzickou velikost.
Pri UTF-8 kodovani se nektere znaky koduji 2 a vice bajty, UNICODE soubory 2 nebo 4 bajty apod. Takze fyzicka velikost pak nemusi odpovidat poctu znaku

V dalsim buildu uz to bude opraveno.