http://qs1969.pair.com?node_id=11142514


in reply to Win32::OLE with non-ANSI data

It gets weirder. The CP_UTF8 option seems to work for data input to the OLE object, but not for returned data. It appears that data is returned in CP_ACP if possible, and only returned as a Perl string if conversion to CP_ACP fails. Nothing seems to be returned to indicate to the caller how the returned data is encoded. Please check whether I'm missing something or whether this is a bug. In test1.mp3, the 'artist' tag is "The Crüxshadows" and in test2.mp3 it's the Cyrillic text "Издатель." Is there a way for me to supply the files I'm using for testing? Thanks.

use strict; use warnings; use Encode qw( is_utf8 ); use Win32::OLE (); Win32::OLE->Option ( CP => Win32::OLE::CP_UTF8 ); binmode( STDOUT, ':raw' ); my $filename = shift or die "No file specified\n"; my $dmcconverter = Win32::OLE->new('dMCScripting.Converter') or die "Can't create dMCScripting.Converter object: $!\n"; my $data = $dmcconverter->AudioProperties($filename); printf( STDERR "The UTF-8 flag for converter output is %d\n", is_utf8( +$data) // 0 ); print "$data"; d:\Mp3\Encode>perl -S test-ole-out.pl D:\Mp3\Encode\test1.mp3 >test1.t +xt The UTF-8 flag for converter output is 0 d:\Mp3\Encode>perl -S test-ole-out.pl D:\Mp3\Encode\test2.mp3 >test2.t +xt The UTF-8 flag for converter output is 1 Wide character in print at D:\Batch/test-ole-out.pl line 15.

UPDATE: I just realized that part of the weirdness is in how Perl represents strings internally. I had been led to believe that it was (almost) UTF-8, but that doesn't seem to be the case. If I read the string "The Crüxshadows" from a file in raw mode, the string data is UTF-8 octets, with the UTF-8 flag off. If I read the same data with an ":encoding(UTF-8)" layer specified, the string data is cp1252 octets with the UTF-8 flag on.