similar to: Native characterset is wrong for unicode builds for Windows

Am 27.02.2015 um 03:13 schrieb Duncan Murdoch: > On 26/02/2015 6:34 PM, maillist at tlink.de wrote: >>> On 26/02/2015 3:09 PM, maillist at tlink.de wrote: >>>> When I send some outlandish characters through enc2native (or format) in >>>> R 3.1.2 on Ubuntu trusty it works quite well: >>>> >>>> > "?????" >>>> [1]

> On 26/02/2015 3:09 PM, maillist at tlink.de wrote: >> When I send some outlandish characters through enc2native (or format) in >> R 3.1.2 on Ubuntu trusty it works quite well: >> >> > "?????" >> [1] "?????" >> > enc2native("?????") >> [1] "?????" >> > Encoding(enc2native("?????"))

On Thu, Feb 26, 2015 at 2:09 PM, maillist at tlink.de <maillist at tlink.de> wrote: > > When I send some outlandish characters through enc2native (or format) in R > 3.1.2 on Ubuntu trusty it works quite well: > > > "?????" > [1] "?????" > > enc2native("?????") > [1] "?????" > >

On 27/02/2015 2:31 AM, maillist at tlink.de wrote: > Am 27.02.2015 um 03:13 schrieb Duncan Murdoch: >> On 26/02/2015 6:34 PM, maillist at tlink.de wrote: >>>> On 26/02/2015 3:09 PM, maillist at tlink.de wrote: >>>>> When I send some outlandish characters through enc2native (or format) in >>>>> R 3.1.2 on Ubuntu trusty it works quite well:

On 26/02/2015 6:34 PM, maillist at tlink.de wrote: >> On 26/02/2015 3:09 PM, maillist at tlink.de wrote: >>> When I send some outlandish characters through enc2native (or format) in >>> R 3.1.2 on Ubuntu trusty it works quite well: >>> >>> > "?????" >>> [1] "?????" >>> > enc2native("?????")

Upon further inspection, I think these are at least two problems. First the issue with printing latin1/cp1252 characters in the "80" to "9F" code range. x <- c("?", "?", "?") Encoding(x) print(x) I assume that these are Unicode escapes!? (Given that Encoding(x) shows "latin1" I'd rather expect latin1/cp1252 escapes here, but

Thank you!. My apologies again for not including the console output in my message before. I sent another e-mail with the output in the meantime, so it should be a bit clearer now, what I am seeing. In case I missed something, please let me know. Yes, I am using latin1 and cp1252 interchangebly here, mostly because Encoding() is reporting the encoding as "latin1". You presumed correctly

This is a follow-up on my initial posts regarding character encodings on Windows (https://stat.ethz.ch/pipermail/r-devel/2017-August/074728.html) and Patrick Perry's reply (https://stat.ethz.ch/pipermail/r-devel/2017-August/074830.html) in particular (thank you for the links and the bug report!). My initial posts were quite chaotic (and partly wrong), so I am trying to clear things up a

Something that looks like a bug to me - but as there may be a documented reason I have missed, I wanted to ask about it here first. Please let me know if this looks like something I should submit as a bug, if not, why this behavior is intended. Using RGui v2.15.3, 64bit, on a Windows 7 machine with US English locale You can see the behavior I describe in the following -------------------- >

You seem confused about Latin-1: those characters are not in Latin-1. (MicroSoft code pages are a proprietary encoding, some code pages such as CP1252 being extensions to Latin-1.) You have not given the 'at a minimum information' asked for in the posting guide so we have no way to reproduce this, and without showing us the output on your system, we have no idea what you saw. [As a

Recent functionality in jsonlite allows for streaming json to a user supplied connection object, such as a file, pipe or socket. RFC7159 prescribes json must be encoded as unicode; ISO-8859 (including latin1) is invalid. Hence I would like R to write strings as utf8, irrespective of the type of connection, platform or locale. Implementing this turns out to be unsurprisingly difficult on windows.

| Confirmed for R-devel (current) on Ubuntu 17.10. But ... isn't the regexp | you use wrong, ie isn't R-devel giving the correct answer? No, I don't think R-devel is correct (or at least consistent with the documentation). My interpretation of gsub("(\\w)", "\\U\\1", entry, perl = TRUE) is "Take every word character and replace it with itself, converted to

I was told to re-raise this issue with R-dev: In the documentation of R-dev and R-3.4.3, under ?gsub > replacement > ... For perl = TRUE only, it can also contain "\U" or "\L" to convert the rest of the replacement to upper or lower case and "\E" to end case conversion. However, the following code runs differently: tempf <- tempfile()

Hello, notice in the console output beneath that there is a resultid 6 but it can not be cleared : [May 5 11:46:27] -- Executing [s at sub:3] MYSQL("SIP/vart-00000336", "Connect connid localhost dialplan host Asterisk") in new stack [May 5 11:46:27] -- Executing [s at sub:4] MYSQL("SIP/vart-00000336", "Query resultid 4 DELETE FROM pickuptbl WHERE

I have a problem with some missing headers when trying to install RODBC on my linux box. > install.packages("RODBC", + lib="/usr/local/david/R") trying URL 'http://cran.stat.auckland.ac.nz/src/contrib/RODBC_1.3-1.tar.gz' Content type 'application/x-gzip' length 990220 bytes (967 Kb) opened URL

Hello, There is a long-lasting problem with processing UTF-8 source code in R on Windows OS. As Windows do not have "UTF-8" locale and R passes source code through OS before executing it, some characters are "simplified" by the OS before processing, leading to undesirable changes. Minimalistic example: Let's type "?" (LATIN SMALL LETTER R WITH CARON) in RGui

Dear helpers, I'm trying to replace a character with a unicode code inside a data frame using gsub(), but unsuccessfully. > data.frame(animals=c("dog","wolf","cat"))->my.data > gsub("o","\u0254",my.data$animals)->my.data$animals > my.data$animals [1] "d??g" "w??lf" "cat" It's not that a data

Hi Tomas, Sorry for the false alarm! I did some further testing, and you were right. There was no regression. I suspected it was a regression because the user who reported the issue said his code worked in R 3.6 but not 4.0. I should have tested it more carefully by myself. After I tested it again with the German locale and Chinese locale, respectively, I found that the code worked for both

All, As some of you know, Jeroen has added support for Unicode strings in the unstable development version of FOX (version 1.5). I''m trying to plan ahead to decide how best to support this for FXRuby 1.6, but I don''t really know anything about Ruby''s support for Unicode or i18n in general. If you''re familiar with this topic (how/if Ruby deals with Unicode

On 2017-05-24, Duncan Murdoch wrote: > > I think the test is wrong because in the first case you are working in a > locale where that character is representable. In my locale it is not, so x1 > is converted to UTF-8, and everything compares equal. > > An explicit conversion of x1 to UTF-8 should fix this, i.e. replace > > x1 <- path.expand(paste0("~/",