Correction to my previous post: Not just the final CR+LF...
Change
EXAMPLE: Using UTF-32 for exaggeration (note also that 3 nul bytes are
missing in the final CR+LF):
to
EXAMPLE: Using UTF-32 for exaggeration (note also that 3 nul bytes are
missing in *each* CR+LF):
-- Jack Kelley
__
Thanks for looking into this.
A few notes regarding all the UTF encodings on Windows 10 ...
The default eol for write.csv (via write.table) is "\n" and always gives
as.raw (c (0x0d, 0x0a)), that is, as adjacent
bytes. This is fine for UTF-8 but wrong for UTF-16 and UTF-32.
EXAMPLE: Using UTF-3
On 30/04/2017 12:23 PM, Duncan Murdoch wrote:
No, I don't think anyone is working on this.
There's a fairly simple workaround for the UTF-16 and UTF-32 iconv
issues: don't attempt to produce character vectors, produce raw vectors
instead. (The "toRaw" argument to iconv() asks for this.) Raw vec
