Perl's open can't be used for opening UTF-16-encoded filenames under Windows. To be clear, all filenames are encoded in UTF-16 under the covers in Windows, but the string (of bytes) passed to Perl's open is (eventually) interpretted as a string of 8-bit characters in the current "code page". Passing a UTF-16 string to Perl's open would result in a file with a one-byte name being opened (until this crazy behavior is fixed, at which point it would die).
In some future version of Perl, it would be nice if open (and lots of other things) could handle out-of-current-code-page characters in filenames (on Win32). That would surely be provided by allowing a Perl-Unicode string to be used as a filename. Internally, perl would notice the "is UTF-8" bit on the string and then translate that string into UTF-16 and then call the alternate underlying API that expects UTF-16 strings. I've actually written code that does this as updates to Win32API::File that I really need to finish merging and testing. /:
- tye
In reply to Re^3: Why do poisoned null attacks still work ? (UTF-16)
by tye
in thread Why do poisoned null attacks still work ?
by pubnoop
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |