Arabische Schrift beim Daten herunterladen in R

Question

Ich habe einen Fragebogen, der von manchen Befragten in Farsi mit arabischen Schriftzeichen ausgefüllt wird. Beim Import in R mit dem SoSci-Script erscheint:

Warning messages:
1: In scan(file = file, what = what, sep = sep, quote = quote, dec = dec, :
invalid input found on input connection '[...Link zensiert...]&vQuality='
2: In scan(file = file, what = what, sep = sep, quote = quote, dec = dec, :
EOF within quoted string

Und der Import bricht an der Stelle ab, an der das erste Mal arabische Schriftzeichen in den Daten auftauchen.

Vor dem Update auf Programm-Version 3.4.19, als der r-Import noch mit read.table() statt read.delim() funktioniert hat, ging das noch.

Comments

Auch mit Umlauten in offenen Angaben treten in R Probleme auf (allerdings nicht beim Import der Daten sondern erst bei der Weiterverarbeitung), die vor dem Update nicht bestanden.

---

R und Unicode sind leider nicht die besten Freunde. Und das gemeine: Manchmal funktioniert es, manchmal nicht.

Könnten Sie die Syntax bitte testweise mal herunterladen (einfach den [...Link zensiert...] im Browser aufrufen), in R öffnen und dort ausführen. Mitunter reicht das schon, damit R die richtige Kodierung verwendet.

Ansonsten müssten wir uns mal konkret ansehen, warum read.delim() hier Probleme macht. Wir hatten die Funktionen getauscht weil (!) derartige Probleme mit read.table() aufgetreten waren. Und bei read.delim() kann man die Verarbeitung eigentlich ein wenig besser steuern.

> allerdings nicht beim Import der Daten sondern erst bei der Weiterverarbeitung

Möchten Sie das genauer spezifizieren? Welche Kodierung zeigt R für die Variablen denn an?

---

Ich arbeite ja mit der neuesten von Ihnen bereitgestellten Syntax zu meinem Projekt.
Ich habe mal ein Minimalbeispiel erstellt. Hier der Link zum Fragebogen:
https://www.soscisurvey.de/test376827/
Hier das R-Skript für den Export:
https://www.soscisurvey.de/test376827/?act=PHJ2QHzUFGiBOcc7ACOakX2q&vQuality&rScript
Im Datensatz habe ich unter anderem eingegeben افغانستان (Afghanistan). Das R-Skript läuft auf die Fehlermeldung:

Error in as.POSIXlt.character(x, tz, ...) :
  Zeichenkette ist nicht in einem eindeutigen Standardformat
In addition: Warning messages:
1: In read.table(file = file, header = header, sep = sep, quote = quote,  :
  invalid input found on input connection 'https://www.soscisurvey.de/test376827/?act=PHJ2QHzUFGiBOcc7ACOakX2q&vQuality='
2: In read.table(file = file, header = header, sep = sep, quote = quote,  :
  unvollständige letzte Zeile von readTableHeader in 'https://www.soscisurvey.de/test376827/?act=PHJ2QHzUFGiBOcc7ACOakX2q&vQuality=' gefunden

(In der Fehlermeldung wird read.table genannt, obwohl im Skript read.delim genutzt wird. Vermutlich ist read.delim ein Wrapper für read.table.)

Ich weiß allerdings nicht, ob der Fehler bei der Änderung des Skripts oder bei R liegt. Wenn ich das alte Skript vom 03.07. (vor dem Update auf unserem SoSci-Server), das damals funktioniert hat, auf die damaligen Daten vom richtigen Befragungsprohekt laufen lasse, bekomme ich ebenfalls die in der obigen Frage genannte Fehlermeldung. Das R- und R-Studio-Update war aber am 30.06. und danach hat das Skript noch funktioniert.

Wenn ich keine arabischen Schriftzeichen im Datensatz habe, funktioniert der Import.

Das zweite Problem sind deutsche Umlaute, wenn ich mir die offenen Angaben der Länder (nach Import des Datensatzes aus dem genannten Testprojekt ohne arabische Schriftzeichen, sonst genauso) als Tabelle ausgeben lasse, z.B. mit
knitr::kable(ds$AA01_01[!is.na(ds$AA01_01)])
erscheint in der Tabelle
\xd6sterreich
Das kann ich aber hinbekommen mit
iconv(ds$AA01_01[!is.na(ds$AA01_01)], from = "ISO-8859-1", to = "UTF-8")
Es ist nur komisch, dass dieser Zwischenschritt nötig ist, denn vor dem Update war er das nicht und in Ihrem Skript ist ja auch enthalten: options(encoding = "UTF-8") und in read.delim: encoding="UTF-8", fileEncoding="UTF-8"

---

Danke für den Download-Link. Was soll ich sagen ... in meinem RStudio 2023-06.1 mit R 4.2.1 läuft es auf Anhieb. Natürlich. Sonst wäre es ja einfach ;)

Und natürlich funktioniert auch die Tabelle:

> knitr::kable(ds$AA01_01[!is.na(ds$AA01_01)])


|x           |
|:-----------|
|Deutschland |
|Frankreich  |
|Österreich  |
|افغانستان   |
|Usbekistan  |

Sie können mal prüfen, ob eine Änderung der internen Kodierung R Abhilfe schafft:

Sys.setlocale("LC_ALL", "de_DE.UTF-8")

Die ursprüngliche Fehlermeldung mit dem as.POSIXlt.character() bezieht sich eigentlich nicht auf die arabischen Schriftzeichen, sondern auf die Variable STARTED. Die wiederum könnte Ärger machen, wenn R die Trennzeichen im CSV nicht richtig interpretiert, weil irgendwas bei der Unicode-Verarbeitung nicht funktioniert.

---

Sind Sie mit dem setlocale() weiter gekommen?

---

Danke der Nachfrage. Ich bekomme folgende Meldung:

Sys.setlocale("LC_ALL", "de_DE.UTF-8")
[1] ""
Warning message:
In Sys.setlocale("LC_ALL", "de_DE.UTF-8") :
  OS reports request to set locale to "de_DE.UTF-8" cannot be honored

Und setlocale() hilft auch nicht die Probleme zu lösen. Wenn das ein Problem mit dem Betriebssystem sein sollte, muss ich dieses wohl neu aufsetzen.

Übrigens habe ich diese Probleme in einem älteren Projekt, das nicht auf SoSci läuft, nicht. Dort ziehe ich die Daten mit dem rvest-Package.

---

Sie können nachtürlich auch ein paar andere Locales ausprobieren, en_EN.UTF-8 zum Beispiel. Wichtig ist, dass R die Character-Daten intern als UTF-8 verarbeitet.

Ich würde empfehlen, dass Sie einmal ausprobieren, ob das Problem auf einem anderen Rechner genauso auftritt. Ich denke nicht, dass es ein generelles Problem mit dem Rechner ist, aber vermutlich wurde irgendwo irgendeine Konfigurationsoption geändert, sodass das Einlesen aus den CSVs nicht sauber funktioniert.

Ich tue mich mit kontruktiver Unterstützung nur leider schwer, solange ich das Problem nicht replizieren kann.