--- In [email protected], "brucexs" <[EMAIL PROTECTED]> wrote: > > > if a file name contains both single-byte ascii characters and > > double-byte CJK characters, then the ContextMenu item's commands are > > usually executed twice, as if two separate files were selected: the > > first one with the correct filepath, however, the second one with > > gabage characters, like ???(0x12), i.e., mostly unknown character > > symbols (0x3F) then FormFeed (0x12) as the last character. > > > > Sean > > > > I don't really understand how the system represents multi-byte > characters, but here is what is happening behind the scenes:
There is no magic here, it's just a 2-bytes in length which remains unchanged regardless of the codepages used. The thing which changes is just its mere appearance: it'll appear as 2 (strange looking) characters in (single-byte) codepages while it'll appear as 1 character in (double-byte character supporting) codepages. 한글 The above will appear as 4 single-byte characters cosisted of 4 bytes in non-Korean-support encodings. But it'll appear as 2 characters in Korean-support encodings, however, still/really 4 bytes in length under the hood. And, they will become 2 wide-chars in UTF16. So, there will be a problem if simply assuming 4 bytes in ANSI <-> 4 widechars in Unicode, which I'm wondering might be the culprit of the strange behavior of PP's context menu, although it doesn't explain then why there is no problem with filenames (excluding the extensions) wholly consisting of Korean characters. Sean
