Ich habe ein seltsames Verhalten von c() mit R 3.3.2 unter Windows mit nicht-US-Englisch Gebietsschema konfrontiert. Es konvertiert die Namen der benannten Vektoren in UTF-8.
Dachte, dass dieses Problem für die meisten Leute nicht problematisch ist, es ist kritisch für diejenigen, die benannte Vektoren als Nachschlagetabellen verwenden (Beispiel ist hier: Ссылка ). Ich bin auch derjenige, der mit dem Verhalten der dplyr-Funktion select () festgefahren ist.
Ich bin mir nicht ganz sicher, ob dieses Verhalten ein Fehler oder ein Design ist. Sollte ich einen Fehlerbericht an R Core senden?
Hier finden Sie Informationen über meine R-Umgebung:
%Vor% Sie sollten weiterhin names(c(x)) == names(x) auf Ihrem System sehen. Die Änderung der Codierung um c() ist möglicherweise unbeabsichtigt, sollte sich jedoch in den meisten Szenarien nicht auf Ihren Code auswirken.
Unter Windows, das kein UTF-8-Gebietsschema hat, ist es die sicherste Wette, alle Zeichenketten zunächst via enc2utf8() in UTF-8 zu konvertieren und dann in UTF-8 zu bleiben. Dies wird auch sichere Suchen ermöglichen.
Sprachsymbole (wie in dplyrs group_by() verwendet) sind ein ganz anderes Thema. Aus irgendeinem Grund werden sie immer in der nativen Codierung interpretiert. (Probieren Sie as.name(names(c(x))) aus.) Es ist jedoch immer noch am besten, sie in UTF-8 zu haben und vor dem Aufruf von as.name() in native umzuwandeln. Das sollte dplyr machen, wir sind noch nicht ganz da.
Ich empfehle, bei Verwendung von dplyr unter Windows nur ASCII-Zeichen für Spaltennamen zu verwenden. Dies erfordert einige Disziplin, wenn Sie sich auf tidyr::spread() für Nicht-ASCII-Spalteninhalte verlassen. Sie könnten auch in Erwägung ziehen, zu einem System (OS X oder Linux) zu wechseln, das nativ mit UTF-8 arbeitet.
Tags und Links r character-encoding