similar to: Trouble reading a UTF-16LE file

Dear R-help, I am having trouble reading a UTF-16LE formatted file. The issue appears to be a byte order mark at the beginning of the file. I have tried readLines(file, encoding='utf-16LE') but that got me [1]"\xff\xfe1" "" "" "" "" "" This is a tab delimited text file, despite the ANA extension. It is created by a custom

Try this: > x <- file("C:\\Users\\Jim\\Downloads\\PV2-ch2 - R_Help.ANA",+ encoding = "UTF-16")> y <- readLines(x)> head(y)[1] "1\t36,74\t0" "2\t269,02\t-44" "1\t326,62\t29" "2\t354,52\t24" [5] "8\t390,75\t1838" "2\t395,11\t-1053"> > Thanks Jim Holtman *Data Munger Guru*

The earlier post had an attached text file that did not go through. I hope this link works. I tested it with a coworker, but that is no guarantee. https://uflorida-my.sharepoint.com/:u:/g/personal/tebert_ufl_edu/EXf5u_CtTwJCrhdfTBIPr7wBefZHx4P_suj4wAWb8i8HFA?e=iQawhh Regards, Tim

I'v encountered what seems to be a bug in PHP Markdown v1.0.1k. Given a UTF-8 with a BOM, the first line is not parsed. A brief search revealed a bug report for a similar issue in python- markdown: > I'm using the markdown.py command to generate HTML from Markdown > documentation and I've found that if a utf-8 file starts with a BOM > a paragraph is generated

Currently when converting a Windows guest we do a minimum installation of the viostor driver, configure the RHEV guest agent and leave RHEV to properly install viostor and all remaining drivers. This works well if RHEV is properly configured and the installation is not interrupted on first boot. However, if the target of the conversion is not RHEV, RHEV is not properly configured, or the first

If I execute the code from the "?write.table" examples section x <- data.frame(a = I("a \" quote"), b = pi) # (ommited code) write.csv(x, file = "foo.csv", fileEncoding = "UTF-16LE") the resulting CSV file has a size of 6 bytes which is too short (truncated): """,3 The problem seems to be the iconv function:

On 2024-09-07 7:37 p.m., Jeff Newmiller wrote: > I tried it on R 4.4.1 on Linux Mint 21.3 just before I posted it, and I just tried it on R 3.4.2 on Ubuntu 16.04 and R 4.3.2 on Windows 11 just now and it works on all of them. > > I don't have a big-endian machine to test on, but the Unicode spec says to honor the BOM and if there isn't one to assume that it is big-endian data.

On 2024-09-07 4:52 p.m., Jeff Newmiller via R-help wrote: > When you specify LE in the encoding type, you are logically telling the decoder that you know the two-byte pairs are in little-endian order... which could override whatever the byte-order-mark was indicating. If the BOM indicated big-endian then the file decoding would break. If there is a BOM, don't override it unless you have to

R-devel community: I have encountered some unexpected behavior using iconv, which may be the source of errors I am getting when connecting to a UTF-16 -encoded SQL Server database. A simple example is below. When researching this problem, I found r-devel reports of the same problem in threads from June 2010 and February, 2016, and that bug #16738 was posted to Bugzilla as a result. However, I

This is not a question but a report on the difficulties I had and the solution I found with respect to UTF-8, YAML::load, and Ruby/Rails. Comments are appreciated. - - - I had been struggling for two days to get UTF-8 working in my Rails app. I had/have a localization file, lib\locale\de.yml, that had iso-8859-1 encoding. I could not get that to display properly. Marnen, quite correctly,

I tried it on R 4.4.1 on Linux Mint 21.3 just before I posted it, and I just tried it on R 3.4.2 on Ubuntu 16.04 and R 4.3.2 on Windows 11 just now and it works on all of them. I don't have a big-endian machine to test on, but the Unicode spec says to honor the BOM and if there isn't one to assume that it is big-endian data. But in this case there is a BOM so your machine has a buggy

Excellent analysis, thank you both for the quick reply! Is there anything I can do to get the bug fixed in the next version of R (e. g. filing a bug report at https://bugs.r-project.org/bugzilla3/)? On Tue, 2016-02-23 at 14:06 +0200, Mikko Korpela wrote: > On 23.02.2016 11:37, Martin Maechler wrote: > >>>>>> nospam at altfeld-im de <nospam at altfeld-im.de> >

When you specify LE in the encoding type, you are logically telling the decoder that you know the two-byte pairs are in little-endian order... which could override whatever the byte-order-mark was indicating. If the BOM indicated big-endian then the file decoding would break. If there is a BOM, don't override it unless you have to (e.g. for a wrong BOM)... leave off the LE unless you really

>>>>> nospam at altfeld-im de <nospam at altfeld-im.de> >>>>> on Mon, 22 Feb 2016 18:45:59 +0100 writes: > Dear R developers > I think I have found a bug that can be reproduced with two lines of code > and I am very thankful to get your first assessment or feed-back on my > report. > If this is the wrong mailing list or I

On Sun, 08 Sep 2024, Christofer Bogaso writes: > Hi, > > I am trying to the data from > https://online.stat.psu.edu/onlinecourses/sites/stat501/files/ch15/employee.txt > without any success. Below is the error I am getting: > >> read.delim('https://online.stat.psu.edu/onlinecourses/sites/stat501/files/ch15/employee.txt') > > Error in make.names(col.names,

I''m developing an international website that uses AJAX. In order to make the international characters appear correctly, I have set my default char set to UTF-8. The problem seems to be that Eclipse even though has the setting to use UTF-8 for encoding, doesn''t save it in the correct format. If I open up the .rhtml file under Notepad++ it encodes the file correctly and accents

On 23/02/2016 7:06 AM, Mikko Korpela wrote: > On 23.02.2016 11:37, Martin Maechler wrote: >>>>>>> nospam at altfeld-im de <nospam at altfeld-im.de> >>>>>>> on Mon, 22 Feb 2016 18:45:59 +0100 writes: >> >> > Dear R developers >> > I think I have found a bug that can be reproduced with two lines of code

This is on r-devel from 2005-03-15. iconvlist() uses (at least some of the time) icfile <- system.file("iconvlist", package = "utils") which looks like """ The following list contain all the coded character sets known. This does not necessarily mean that all combinations of these names can be used for the FROM and TO command line parameters. One coded

The _point_ is to explain the story of the research so people can compare easily with other work. A story interrupted by tedious details is not very comprehensible. And I _did_ recommend providing a link to a code repository and using reproducible coding tools. On December 30, 2024 7:35:37 PM PST, "Ebert,Timothy Aaron" <tebert at ufl.edu> wrote: >Maybe I misunderstand, but if

Fair enough. You do not put citations in the abstract or summary. The level of detail in the methods can be modified by including a link to a repository or by including supplemental material, or appendix, or foot notes, or something equivalent. If all programs/packages are used with system defaults the version number is sufficient. If the packages are customized and such customization materially