in reply to Extra spaces in COM strings to stdout?

I'm guessing that the output text string is actually not ASCII data, but rather is encoded as UTF-16LE -- 2-byte unicode characters, in which all the characters happen to be in the ASCII range (U0000 - U007f), so the second (high) byte is always null. Meanwhile, your display window is (mercifully) interpreting null bytes as spaces (as opposed to doing something really nasty or stupid).

You should look at "Encode" man page (and probably "perlunicode" and even "perluniintro", for a well-rounded education). The thing you need to do is "decode" that text string from UTF-16LE into perl's native utf8. Assuming the string really is just ASCII characters, nothing else should be necessary -- it so happens that ASCII is now a proper subset (a very small subset) of utf8. Supposing you assign the string in question to a scalar, say $comstring, you could convert it for proper display with something like this:

use Encode; ... my $displayable = decode( 'UTF-16LE', $comstring ); print $displayable; ...

Replies are listed 'Best First'.
Re: Re: Extra spaces in COM strings to stdout?
by kal (Hermit) on Mar 20, 2004 at 15:39 UTC
    Surely it's the other way around? If it's the COM object that is actually doing the output, then the problem is that Perl is passing it UTF16 but it thinks it's receiving ASCII? Or perhaps Win32::OLE is translating to UTF16 before use, and the component isn't dealing with the character set correctly...
      Well to be honest, Win32 stuff is just not part of my world these days (hardly ever was), so I don't really have a clue what COM objects are or how they work. I just happened to recall that a number of MS-Win thingies do seem to use UTF-16LE natively for text data, and when their native data happens to go through some other process that normally doesn't use or expect UTF-16 encoding, you get strange behavior, including the sort of thing displayed in the OP.

      Maybe the module author(s) involved should be consulted or alerted about this -- or maybe a closer reading of the relevant module man pages would help...

      update: Having just looked at Win32::OLE, I would say (guessing again) that the solution lies in understanding what the "Logger" application really does, and making sense of the paragraph in the Win32::OLE man page that describes "Localization". It may be that there really is no problem at all with the perl app and module usage described in the OP -- the monk simply needs to use the appropriate (UTF-16-aware) methods for reading the Logger output.