6
Dateiinhalt in UTF-8 ist nicht gleich UTF-8?
Hi Linux und PHP Gurus,
ich habe ein Problem mit dem Zeichensatz *in* einer Datei und komme nicht weiter:
Eine Datei "language.php" enthält Übersetzungen in allen möglichen Sprachen - Text UTF-8. Sie liegt auf einem SuSE 11 Server (Dateisystem XFS) und funktionierte dort einwandfrei und lässt sich dort auch sauber betrachten (less), inkl. Russisch, Dänisch, Polnisch etc.
Diese Datei kopierte ich auf einen Ubuntu 14.04 Server (Dateisystem EXT4) und verhält sich völlig anders:
Mit "(z.B. iconv -f UTF-8 -t ISO-8895-1 ...)" komme ich zu keinem Ergebnis, das stolpert immer über unbekannte Zeichen und bricht ab. Und das, was es bis dahin produziert hat, ist auch nicht wirklich brauchbar. Also ist eine Konvertierung zwecklos.
Die Datei ist bis aufs Byte gleich gross auf beiden Seiten, hat Unix Umbrüche, ... alles passt soweit. Kopiert habe ich per FTP als Plain Text und und testweise auch als .gz, alles umsonst bis hier.
Wo muss ich nach Ursache suchen?
Dateisystem? Locale? PHP oder Apache Konfiguration?
Bin für jede solide Idee dankbar.
ich habe ein Problem mit dem Zeichensatz *in* einer Datei und komme nicht weiter:
Eine Datei "language.php" enthält Übersetzungen in allen möglichen Sprachen - Text UTF-8. Sie liegt auf einem SuSE 11 Server (Dateisystem XFS) und funktionierte dort einwandfrei und lässt sich dort auch sauber betrachten (less), inkl. Russisch, Dänisch, Polnisch etc.
Diese Datei kopierte ich auf einen Ubuntu 14.04 Server (Dateisystem EXT4) und verhält sich völlig anders:
- less zeigt dort, wo es kritisch ist, nur Zeichensalat / Platzhalter an.
- die zugehörige PHP Prozedur (json_encode), die mit Hilfe dieser Datei eine Ausgabe produzieren soll, endet mit der Warnung (im error_log) "PHP Warning: json_encode(): Invalid UTF-8 sequence in argument in /var/www/vhosts/some.host.com/httpdocs/typo3conf/ext/geo_search/all_results.php on line 235"
Mit "(z.B. iconv -f UTF-8 -t ISO-8895-1 ...)" komme ich zu keinem Ergebnis, das stolpert immer über unbekannte Zeichen und bricht ab. Und das, was es bis dahin produziert hat, ist auch nicht wirklich brauchbar. Also ist eine Konvertierung zwecklos.
Die Datei ist bis aufs Byte gleich gross auf beiden Seiten, hat Unix Umbrüche, ... alles passt soweit. Kopiert habe ich per FTP als Plain Text und und testweise auch als .gz, alles umsonst bis hier.
Wo muss ich nach Ursache suchen?
Dateisystem? Locale? PHP oder Apache Konfiguration?
Bin für jede solide Idee dankbar.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 278585
Url: https://administrator.de/forum/dateiinhalt-in-utf-8-ist-nicht-gleich-utf-8-278585.html
Ausgedruckt am: 26.12.2024 um 01:12 Uhr
6 Kommentare
Neuester Kommentar
Hi Lexa,
wenn die Datei gleich ist kann es nur am "Verarbeiter" liegen. PHP, .htaccess? usw usf.
Grüße
wenn die Datei gleich ist kann es nur am "Verarbeiter" liegen. PHP, .htaccess? usw usf.
Grüße
Moin,
Stimmt der md5- oder sha-hash?
FTP Übertragung im Textmodus vermurkst oft etwas. heutzutage sollte man nur noch binry-Mode vewenden.
lks
Stimmt der md5- oder sha-hash?
FTP Übertragung im Textmodus vermurkst oft etwas. heutzutage sollte man nur noch binry-Mode vewenden.
lks
Hi ihr,
Danke euch beiden für die Ideen, aber ich bin noch nicht viel weiter. Die Datei ist gleich (s.u.). Dass die "Verarbeiter" Schuld sind erscheint mir unwahrscheinlich, kann ich aber nicht ausschliessen, aber die PHP Optionen phpinfo() und die htaccess sind identisch. Da finde ich keinen neuen Hebel.
Der Tipp mit den Hashes ist gut
, da hätte ich auch selbst drauf kommen können/müssen. Aber so ist das, wenn man sich verrennt... Ich breche das Problem auf den MD5 Hash herunter und stelle fest, dass der auf Server1 und Server2 exakt identisch ist.
Somit ist klar, dass es nicht an der Datei liegt.
Wieso zeigt mir aber 'less languages.php' unterschiedliche Inhalte an. Woran kann das liegen?
Ausserdem (kürzlich erst entdeckt):
In einem Ordner liegen PDF-Dateien mit kyrillischen (Russisch) Zeichen im Dateinamen, welche auf Server1 korrekt angezeigt werden (ls -al) und auf dem Problem-Server2 mit Zeichensalat.
Könnte das einen Zusammenhang haben und wie kann man das korrigieren?
Danke euch beiden für die Ideen, aber ich bin noch nicht viel weiter. Die Datei ist gleich (s.u.). Dass die "Verarbeiter" Schuld sind erscheint mir unwahrscheinlich, kann ich aber nicht ausschliessen, aber die PHP Optionen phpinfo() und die htaccess sind identisch. Da finde ich keinen neuen Hebel.
Der Tipp mit den Hashes ist gut
, da hätte ich auch selbst drauf kommen können/müssen. Aber so ist das, wenn man sich verrennt... Ich breche das Problem auf den MD5 Hash herunter und stelle fest, dass der auf Server1 und Server2 exakt identisch ist.Somit ist klar, dass es nicht an der Datei liegt.
Wieso zeigt mir aber 'less languages.php' unterschiedliche Inhalte an. Woran kann das liegen?
Ausserdem (kürzlich erst entdeckt):
In einem Ordner liegen PDF-Dateien mit kyrillischen (Russisch) Zeichen im Dateinamen, welche auf Server1 korrekt angezeigt werden (ls -al) und auf dem Problem-Server2 mit Zeichensalat.
Könnte das einen Zusammenhang haben und wie kann man das korrigieren?
Moin,
was sagt ein
in einer Shell der Useraccounts ?
Und in der httpd.conf des Apache steht dort ein:
?
Gruß grexit
was sagt ein
echo $LANG
Und in der httpd.conf des Apache steht dort ein:
AddDefaultCharset utf-8
Gruß grexit
Zitat von @lexa-lexa:
In einem Ordner liegen PDF-Dateien mit kyrillischen (Russisch) Zeichen im Dateinamen, welche auf Server1 korrekt angezeigt werden
(ls -al) und auf dem Problem-Server2 mit Zeichensalat.
Könnte das einen Zusammenhang haben und wie kann man das korrigieren?
In einem Ordner liegen PDF-Dateien mit kyrillischen (Russisch) Zeichen im Dateinamen, welche auf Server1 korrekt angezeigt werden
(ls -al) und auf dem Problem-Server2 mit Zeichensalat.
Könnte das einen Zusammenhang haben und wie kann man das korrigieren?
Dann soltest Du mal die verschiedenen Umgebungsvariablen, die die Zeichencodierung betreffen durchschauen, z.B. LANG.
lks
Das Problem mit dem Dateiinhalt ist wahrscheinlich gelöst und liegt bei PHP oder Typo3:
http://wissen.netzhaut.de/typo3/utf-8-zeichen-in-dateinamen/
Obwohl sich der Tipp mit Dateinamen beschäftigt, habe ich - bevor json_encode() ausgeführt wird - nun quick-n-dirty einfach mal ein "setlocale()" reingepackt und der Code geht nun. Ob und wie ich das global für den Server oder PHP oder Typo3 mache, kann ich nun gezielt untersuchen.
Was die Umgebung betrifft:
Ich bin angemeldet als root und führe "$ locale" auf Server1 aus:
server1:~ # locale
LANG=POSIX
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
auf dem Problem Server2:
server2:~# locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE=en_US
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
Die Herausforderung scheint nun zu sein, wie man Apache, root, PHP, Typo3... usw. unter einen definierten Hut bekommt, damit alle mit denselben Einstellungen werken. Aber ich glaube, das ist dann ein anderes Thema.
Danke euch Dreien für den wertvollen Input
http://wissen.netzhaut.de/typo3/utf-8-zeichen-in-dateinamen/
Obwohl sich der Tipp mit Dateinamen beschäftigt, habe ich - bevor json_encode() ausgeführt wird - nun quick-n-dirty einfach mal ein "setlocale()" reingepackt und der Code geht nun. Ob und wie ich das global für den Server oder PHP oder Typo3 mache, kann ich nun gezielt untersuchen.
Was die Umgebung betrifft:
Ich bin angemeldet als root und führe "$ locale" auf Server1 aus:
server1:~ # locale
LANG=POSIX
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
auf dem Problem Server2:
server2:~# locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE=en_US
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
Die Herausforderung scheint nun zu sein, wie man Apache, root, PHP, Typo3... usw. unter einen definierten Hut bekommt, damit alle mit denselben Einstellungen werken. Aber ich glaube, das ist dann ein anderes Thema.
Danke euch Dreien für den wertvollen Input
