Re: encoding(UTF16-LE) on Windows

2011-02-02 Thread Erland Sommarskog
Michael Ludwig (mil...@gmx.de) writes: For instance, I use Windows exclusively, so Unicode in file names is no problem. Did a quick test: (v5.12.1) built for MSWin32-x86-multi-thread (so ActiveState) * a…b.txt * not correct * doesn't have anything with uni or utf in perl -V

Re: encoding(UTF16-LE) on Windows

2011-01-31 Thread Erland Sommarskog
Michael Ludwig (mil...@gmx.de) writes: Erland Sommarskog schrieb am 29.01.2011 um 14:02 (+0100): Yes, there certainly seems to be some more stuff to do in the Unicode support in Perl. For instance, support for Unicode filenames in open or opendir. I think there is no portable answer here,

Re: encoding(UTF16-LE) on Windows

2011-01-31 Thread Michael Ludwig
Erland Sommarskog schrieb am 31.01.2011 um 23:42 (+0100): Michael Ludwig (mil...@gmx.de) writes: Erland Sommarskog schrieb am 29.01.2011 um 14:02 (+0100): Yes, there certainly seems to be some more stuff to do in the Unicode support in Perl. For instance, support for Unicode filenames

Re: encoding(UTF16-LE) on Windows

2011-01-30 Thread Michael Ludwig
Erland Sommarskog schrieb am 29.01.2011 um 14:02 (+0100): Yes, there certainly seems to be some more stuff to do in the Unicode support in Perl. For instance, support for Unicode filenames in open or opendir. I think there is no portable answer here, as it depends on the filesystem's support

RE: encoding(UTF16-LE) on Windows

2011-01-23 Thread Erland Sommarskog
Jan Dubois (j...@activestate.com) writes: You need to stack the I/O layers in the right order. The :encoding() layer needs to come last (be at the bottom of the stack), *after* the :crlf layer adds the additional carriage returns. The way to pop the default :crlf layer is to start out with

RE: encoding(UTF16-LE) on Windows

2011-01-21 Thread Erland Sommarskog
Jan Dubois (j...@activestate.com) writes: Now when you print a string to the filehandle, then it will be passed to the top-most layer first (:crlf), which will s/\n/\r\n/g on the string, and then passes it on to the next lower layer :encoding, which will do the encoding, and when it reaches

RE: encoding(UTF16-LE) on Windows

2011-01-21 Thread Jan Dubois
On Fri, 21 Jan 2011, Erland Sommarskog wrote: There is still one thing that is not clear to me. The incorrect end-of-line was 0D 00 0A But the way you describe it, I would expect it to be 0D 0A 00 I went back to the very first message in the thread, where you write: | When I

RE: encoding(UTF16-LE) on Windows

2011-01-21 Thread Jan Dubois
I wrote: I saw some discussion today that the :raw pseudo-layer in the open() call will also remove the buffering layer (it doesn’t do that when you use it in a binmode() call). I’ll try to remember to send a followup once I actually understand what is going on. That seems indeed to be the

Re: encoding(UTF16-LE) on Windows

2011-01-20 Thread Michael Ludwig
Erland Sommarskog schrieb am 20.01.2011 um 08:29 (-): Jan Dubois (j...@activestate.com) writes: You need to stack the I/O layers in the right order. The :encoding() layer needs to come last (be at the bottom of the stack), *after* the :crlf layer adds the additional carriage returns.

RE: encoding(UTF16-LE) on Windows

2011-01-20 Thread Jan Dubois
On Thu, 20 Jan 2011, Erland Sommarskog wrote: One can sense some potential for improvements. Not the least in the documentation area. This is open source. Patches welcome! This is how things get better. Cheers, -Jan

Re: encoding(UTF16-LE) on Windows

2011-01-20 Thread 'Michael Ludwig'
[RE: encoding(UTF16-LE) on Windows] Jan Dubois schrieb am 20.01.2011 um 12:45 (-0800): On Thu, 20 Jan 2011, Michael Ludwig wrote: Erland Sommarskog schrieb am 20.01.2011 um 08:29 (-): Jan Dubois (j...@activestate.com) writes: You need to stack the I/O layers in the right order

Re: encoding(UTF16-LE) on Windows

2011-01-20 Thread Bob Hallissy
Jan Dubois wrote: Files opened on Windows already have the :crlf layer pushed by default, so you somehow need to get the :encoding layer*below* it. Is it possible to re-write the working statement open(my $fh, :raw:encoding(UTF-16LE):crlf, $filename) or die $!; in a way that works

Re: encoding(UTF16-LE) on Windows

2011-01-19 Thread Michael Ludwig
Erland Sommarskog schrieb am 17.01.2011 um 13:57 (-): I'm on Windows and I have this small script: use strict; open F, ':encoding(UTF-16LE)', slask2.txt; print F 1\n2\n3\n; close F; When I open the output in a hex editor I see 31 00 0D 0A 00 32 00 0D 0A 00 33 0D 0A

RE: encoding(UTF16-LE) on Windows

2011-01-19 Thread Jan Dubois
On Wed, 19 Jan 2011, Michael Ludwig wrote: Erland Sommarskog schrieb am 17.01.2011 um 13:57 (-): I'm on Windows and I have this small script: use strict; open F, ':encoding(UTF-16LE)', slask2.txt; print F 1\n2\n3\n; close F; When I open the output in a hex editor I

Re: encoding(UTF16-LE) on Windows

2011-01-19 Thread 'Michael Ludwig'
Jan Dubois schrieb am 19.01.2011 um 11:08 (-0800): You need to stack the I/O layers in the right order. The :encoding() layer needs to come last (be at the bottom of the stack), *after* the :crlf layer adds the additional carriage returns. The way to pop the default :crlf layer is to start