fgetcsv isst den ersten Buchstaben eines Strings, wenn es ein Umlaut ist

8

Ich importiere Inhalte aus einer Excel-generierten CSV-Datei in ein XML-Dokument wie:

%Vor%

Die eingefügten Daten sind englische / deutsche Ausdrücke.

Ich füge diese Werte in eine XML-Struktur ein und gebe das XML wie folgt aus:

%Vor%

Das funktioniert gut, aber ich stoße auf ein wirklich seltsames Problem. Wenn der erste Buchstabe eines Strings ein Umlaut ist (wie in Österreich oder Ägypten ) wird das Zeichen weggelassen, was in gypten oder sterreich resultiert. Wenn der Umlaut in der Mitte des Strings ( Russische Föderation ) ist, wird er korrekt übertragen. Das gleiche gilt für Dinge wie ß oder é oder was auch immer.

Alle Dateien sind UTF-8-codiert und werden in UTF-8 bereitgestellt.

Das scheint mir ziemlich seltsam und bugartig zu sein, doch vielleicht fehlt mir etwas, hier sind viele kluge Leute.

    
m90 12.09.2012, 14:47
quelle

5 Antworten

4

Ok, das scheint also ein Fehler in fgetcsv zu sein.

Ich bearbeite jetzt die CSV-Daten selbst (etwas umständlich), aber es funktioniert und ich habe überhaupt keine Codierungsprobleme.

Dies ist (eine noch nicht optimierte Version von) was ich mache:

%Vor%

Das getCSVValues kommt von hier und wird benötigt, um mit solchen CSV-Zeilen umgehen zu können (Kommas!):

%Vor%

Es sieht so aus:

%Vor%

Ziemlich ein Workaround, aber es scheint gut zu funktionieren.

BEARBEITEN:

Dafür gibt es auch einen archivierten Bug , anscheinend hängt das davon ab in den Gebietsschemaeinstellungen.

    
m90 13.09.2012, 08:20
quelle
3

Wenn die Zeichenkette aus Excel kommt (ich hatte Probleme damit, dass der Buchstabe ø verschwindet, wenn er am Anfang der Zeichenkette war) ... dann hat er das behoben:

setlocale (LC_ALL, 'de_DE.ISO-8859-1');

    
Brian Langhoff 28.06.2013 09:06
quelle
2

Wenn andere Umlaute in der Mitte in Ordnung erscheinen, handelt es sich nicht um ein Basiscodierungsproblem. Die Tatsache, dass es am Anfang der Zeile passiert, weist wahrscheinlich auf eine Inkompatibilität mit der Zeilenvorschubmarkierung hin. Vielleicht wurde die CSV mit einer anderen Newline-Codierung erzeugt.

Dies passiert beim Verschieben von Dateien zwischen verschiedenen Betriebssystemen:

  • Windows: \r\n (Zeichen 13 und 10)
  • Linux: \n (Zeichen 10)
  • Mac OS: \r (Zeichen 13)

Wenn ich Sie wäre, würde ich die Newline-Markierung überprüfen, um sicher zu sein.

Wenn in Linux: hexdump -C filename | more und das Dokument überprüfen.

Sie können die Zeilenumbrüche mit einem sed -Ausdruck ändern, wenn dies der Fall ist.

Hoffe, dass geholfen hat!

    
Fèlix Galindo Allué 13.09.2012 05:29
quelle
2

Eine etwas einfachere Problemumgehung (aber ziemlich schmutzig):

%Vor%     
Josef Sábl 20.05.2013 16:24
quelle
0

Könnte eine Art utf8_encode() Problem sein. Dieser Kommentar auf der Dokumentationsseite zeigt an, ob Sie ein Umlaut kodieren, wenn dies der Fall ist bereits codiert, könnte es Probleme verursachen.

Vielleicht testen Sie, ob die Daten bereits utf-8-kodiert sind mit mb_detect_encoding() .

    
taco 13.09.2012 02:15
quelle