Warum verändert Stringr die Kodierung beim Manipulieren von Strings?

Question

Es ist dieses seltsame Verhalten von stringr, die mich wirklich nervt. stringr ändert ohne Warnung die Codierung einiger Zeichenfolgen, die exotische Zeichen enthalten, in meinem Fall ø, å, æ, é und einige andere ... Wenn Sie str_trim einen Vektor von Zeichen, dann werden diejenigen mit exotischen Buchstaben in ein neues umgewandelt Codierung.

letter1 <- readline('Gimme an ASCII character!')  # try q or a 
letter2 <- readline('Gimme an non-ASCII character!') # try ø or é 
Letters <- c(letter1, letter2) 
Encoding(Letters)   # 'unknown' 
Encoding(str_trim(Letters)) # mixed 'unknown' and 'UTF-8' 

Dies ist ein Problem, weil ich data.table für (fast) merge von großen Tabellen verwenden und dass data.table nicht gemischte Codierung unterstützt und weil ich nicht einen Weg, um wieder auf die einheitliche Codierung finden konnte, .

Alle Probleme?

EDIT: Ich dachte, ich könnte zurück zu den Basisfunktionen, aber sie schützen nicht entweder Codierung. paste konserviert es, aber nicht sub zum Beispiel.

Encoding(paste(' ', Letters))     # 'unknown' 
Encoding(str_c(' ', Letters))     # mixed 
Encoding(sub('^ +', '', paste(' ', Letters))) # mixed 

Answer 1

R macht es nicht immer einfach, zwischen Codierungen zu konvertieren (es gibt die Funktion iconv dafür, aber was diese Funktion akzeptiert, ist plattformabhängig). Doch zumindest können Sie immer die Codierung zurückgesetzt Markierung einer Zeichenfolge „unbekannt“:

Letters = str_trim(Letters) 
Encoding(Letters) 
# [1] "unknown" "UTF-8" 
Encoding(Letters) = '' 
Encoding(Letters) 
# [1] "unknown" "unknown" 

Beachten Sie jedoch, dass dies nur Marken die Codierung einer Zeichenkette, ist es nicht wirklich re- kodiere die Zeichenkette. Als Konsequenz kann dies zu verzerrten Daten führen. Wie in den Kommentaren erwähnt, ist dies im besten Fall ein Hack, keine eigentliche Lösung für das Problem.

Encoding veranschaulicht R Probleme mit Codierungen ordnungsgemäß zu arbeiten. Die Dokumentation lautet:

ASCII-Zeichenfolgen werden nie mit einer deklarierten Codierung markiert, da ihre Darstellung in allen unterstützten Codierungen identisch ist.

... die gar offensichtlich nicht hilfreich (und auch mehr als nur ein wenig irreführend, eine UTF-8-String nur aus Codepunkten < 128 kann in eine ASCII-Zeichenfolge nicht zu unterscheiden aussehen, aber auf sie betrieben werden, sollten zu unterschiedlichen Ergebnissen führen abhängig von der Codierung, weshalb es sollte effektiv markiert werden).

Interessanterweise weder enc2native noch enc2utf8 wird hier die gewünschte Sache tun - sowohl in verschiedenen Codierungen für die beiden Strings in Letters ergeben wird, eine direkte Folge des Encoding Problems wie oben zitiert.

Answer 2

stringr wird Ändern der Codierung, da stringr ein Wrapper um das Paket stringi ist, und stringi kodiert immer in UTF-8. Details und eine Erläuterung dieser Design-Option finden Sie unter help("stringi-encoding", package = "stringi").

Um Probleme beim Zusammenführen von data.table s zu vermeiden, stellen Sie sicher, dass alle id Variablen in UTF-8 codiert sind. Sie können dies unter Verwendung von stri_enc_toutf8 im -Paket oder unter Verwendung von iconv tun.

Answer 3

Mit this recent commit kümmert sich data.table jetzt implizit um diese gemischten Codierungen, indem beim Erstellen von Daten korrekte Codierungen sichergestellt werden.Tabellen, sowie durch die Sicherstellung der richtigen Kodierungen in Funktionen wie unique() und duplicated().

Siehe Nachricht (23) unter Bugs für v1.9.7 in README.md.

Bitte testen Sie und schreiben Sie zurück, wenn Sie weitere Probleme haben.