ZTree.com  | ZEN  | About...  

 Index   Back

ZTW's NOT doing some weird stuff...   [Release]

By: Ian Binnie   Homepage   Sydney  
Date: May 13,2007 at 10:07
In Response to: ZTW's doing some weird stuff... (Martijn Coppoolse)

> I think I've finally figured it out; it would seem that, when using the /O
> option, instead of performing less character mappings, ZTreeWin does
> *more* of them!

Ben is almost certainly using different codepage 437 1250

See the following for discussion:-
http://www.ztwiki.com/tiki-index.php?page=h_oem_ansi_codepages

The small application displays codepages & charactersets:-
http://www.ztwiki.com/tiki-download_file.php?fileId=13

> I wrote a little tool to make all these code page conversions a tad easier
> to test, and here's what I had to do to get to the same file name
> ZTreeWin/O gives:

Just try US English.

> .u{font-family:'Arial Unicode MS'} So, when reading a file with a
> U+03B2 Greek Small Beta ' β ', Windows translates the file name to
> ZTreeWin's code page (OEM). In code page 850, this is mapped to character
> #225: ' ß ' (U+00DF LATIN SMALL LETTER SHARP S).

> Then, somehow, the file name gets converted to the ANSI code page, where
> our mapped character is known as character #223 (still ' ß ' U+00DF).
> (The only reason for this conversion I can think of, is to keep ZLog files
> consistent: always in ANSI charset).

> But now something weird happens: in the display, we see character U+2580
> UPPER HALF BLOCK: ' ▀ ', which is OEM character #223, not the
> ANSI one. We should have gotten to see OEM character #225 ' ß '
> (which is identical to ANSI #223 ' ß ').

> But the really messy part, is when a when a separate program gets called
> from F9 using %1: that character OEM #223 ▀ is converted from
> OEM to ANSI while it really already was an ANSI character (even though
> displayed as OEM)!

> The character in the ANSI code page which matches ▀ most closely
> is apparently ' ¯ ' (U+00AF MACRON), which is what the external
> application receives. Only this character has no relation whatsoever with
> the original character.

> In the case of +U03B2 ' β ', it's only a display issue, since
> neither ZTreeWin nor auxiliary programs will be able to access the file
> anyway (because of the conversion of U+03B2 to U+00DF in code page 850).
> It does become a problem in the /O mode for files with any characters that
> occur in both the OEM and ANSI code pages, but in different positions:
> those files can't be processed from the F9 menu. (F9 seem the only place
> affected, though: such files are still accessible for operations by
> ZTreeWin, and Open and eXecute properly as well).

> Anyway, I won't be filing this as a bug, since I'd much rather Kim spent
> his time making ZTreeWin Unicode-enabled... ;-)

862 views      
Thread locked
 

Messages in this Thread

 
96,637 Postings in 12,231 Threads, 350 registered users, 94 users online (1 registered, 93 guests)
Index | Admin contact |   Forum Time: Mar 28, 2024 - 11:13 pm UTC  |  Hits:62,383,818  (36,215 Today )
RSS Feed