Ok. Thanks for the feedback. This gives me some pointers to where I
should start looking.
I looks like that unless I can find a way to call UTF-8 aware file
methods the plugins are doomed to run into bugs and malfunction.
I’ll dig into Windows’ Unicode capable API and query the Sketchup
scripting and plugin community and see if we can find a solution. Maybe
Google Sketchup devs can provide some assistance as well.
Bill K. wrote:
From: “Thomas T.” [email protected]
James G. wrote:
That’s a good question. I’m not sure what it does on Windows.
Any clues what I does on OSX? The scripts will run on macs as well.Unlike that other OS, both OS X and Linux have taken an approach
I like to refer to as, NOT MIND-NUMBINGLY STUPID.In OS X and Linux, one can use the same API calls one has always
used, as they are now UTF-8 savvy.
I found from the Windows API that you actually are meant to call the
same API calls. But there’s a unicode switch you have to declare. If
that switch is true it calls the W (wide - unicode) versions, if not it
calls the A (ASCII) versions.
From: “Bill K.” [email protected]
From: “Thomas T.” [email protected]
Andd, I also don’t know what would happen for an eastern user. I’m
wondering if the IO functions would assume a different 8bit encoding…For best 8-bit compatibility you’ll want to encode to Windows1252.
Hmm, I take it back; even for 8-bit it appears slightly more complicated
on windows…
Apparently depending on AreFileApisANSI() one would encode to
GetACP() vs. GetOEMCP()
Ruby 1.9.1 is smart enough to handle this automatically (see:
rb_filesystem_encoding() in encoding.c)
But anyway this is all still referring to 8-bit code pages and still
won’t
help for chinese (etc.) characters anyway…
So, again, if you absolutely need to handle unicode paths on
windows prior to ruby 1.9.2, and you don’t have the option of
writing your own ruby C extension, the I think trying to call
wide-character functions like _wopen() via ruby’s Win32API
module may be the only option. 
Regards,
Bill