4
UTF-8 wird nicht nach FTP-Transfer nicht korrekt dargestellt
Hallo allerseits!
Nachdem uns unser Webhoster offenbar nicht helfen kann, also hier meine Bitte um einen hilfreichen Tipp. Zur Ausgangssituation:
Unsere Website ist komplett in HTML, CSS und JavaScript realisiert, enthält in längeren Texten neben den üblichen deutschen Umlauten chinesische Schriftzeichen in traditionell und vereinfacht und ist entsprechend als UTF-8 kodiert. Wird sie lokal, auf Wechseldatenträgern oder Netzlaufwerken veröffentlicht, kann sie auch von allen gängigen Clients korrekt dargestellt werden: Win7 de/en, WinServer 2008 (ok - nicht so gängig;), iPad, Android machen brav was sie sollen, inklusive IE, FF, GC, OP und Safari.
Nach der Übertragung per FTP auf den Webserver musste ich allerdings feststellen, dass die Seiten (erstellt in notepad++) nur in der Kodierung UTF-8 mit BOM korrekt dargestellt werden, und das leider auch nicht auf allen Clients: Win7 en zeigt statt chinesisch und Umlauten den gleichen Symbolsalat, als hätte ich die Dateien (wie beim ersten Versuch) in UTF-8 ohne BOM übertragen. Ein im head eingebundenes externes JavaScript wird (vermutlich der vielen Sonderzeichen aller möglichen Sprachen wegen) nicht ausgeführt, eine einfache JavaScript-Anweisung im body (über die alle Inhalte aus .txt-Dateien eingebunden werden) dagegen durchaus.
Als FTP-Client benutze ich FileZilla mit den Standard-Einstellungen (Server/Benutzer/Passwort, sonst nichts) und die Daten kommen auch alle an.
Welcher Server bei unserem Hoster läuft, wissen wir bisher nicht (der Versuch, über Fehlerseiten einen Hinweis zu erhalten, brachte nur den Hinweis, dass der doctype header auf IETFDTD HTML 2.0// verweist). Die Versuche, den Server mit .htaccess [addCharset: utf-8.htm] und httpd.conf[AddDefaultCharset utf-8] (hier aus den gelösten Threads gesammelt) zur korrekten Darstellung zu motivieren, sind leider fehlgeschlagen.
Ich hoffe, ich habe alle relevanten Informationen geliefert und bin dankbar für jeden Tipp!
Schönen Abend wünsche ich
Spinnifex
Nachdem uns unser Webhoster offenbar nicht helfen kann, also hier meine Bitte um einen hilfreichen Tipp. Zur Ausgangssituation:
Unsere Website ist komplett in HTML, CSS und JavaScript realisiert, enthält in längeren Texten neben den üblichen deutschen Umlauten chinesische Schriftzeichen in traditionell und vereinfacht und ist entsprechend als UTF-8 kodiert. Wird sie lokal, auf Wechseldatenträgern oder Netzlaufwerken veröffentlicht, kann sie auch von allen gängigen Clients korrekt dargestellt werden: Win7 de/en, WinServer 2008 (ok - nicht so gängig;), iPad, Android machen brav was sie sollen, inklusive IE, FF, GC, OP und Safari.
Nach der Übertragung per FTP auf den Webserver musste ich allerdings feststellen, dass die Seiten (erstellt in notepad++) nur in der Kodierung UTF-8 mit BOM korrekt dargestellt werden, und das leider auch nicht auf allen Clients: Win7 en zeigt statt chinesisch und Umlauten den gleichen Symbolsalat, als hätte ich die Dateien (wie beim ersten Versuch) in UTF-8 ohne BOM übertragen. Ein im head eingebundenes externes JavaScript wird (vermutlich der vielen Sonderzeichen aller möglichen Sprachen wegen) nicht ausgeführt, eine einfache JavaScript-Anweisung im body (über die alle Inhalte aus .txt-Dateien eingebunden werden) dagegen durchaus.
Als FTP-Client benutze ich FileZilla mit den Standard-Einstellungen (Server/Benutzer/Passwort, sonst nichts) und die Daten kommen auch alle an.
Welcher Server bei unserem Hoster läuft, wissen wir bisher nicht (der Versuch, über Fehlerseiten einen Hinweis zu erhalten, brachte nur den Hinweis, dass der doctype header auf IETFDTD HTML 2.0// verweist). Die Versuche, den Server mit .htaccess [addCharset: utf-8.htm] und httpd.conf[AddDefaultCharset utf-8] (hier aus den gelösten Threads gesammelt) zur korrekten Darstellung zu motivieren, sind leider fehlgeschlagen.
Ich hoffe, ich habe alle relevanten Informationen geliefert und bin dankbar für jeden Tipp!
Schönen Abend wünsche ich
Spinnifex
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: 287215
Url: https://administrator.de/contentid/287215
Ausgedruckt am: 25.11.2024 um 06:11 Uhr
4 Kommentare
Neuester Kommentar
Hallo Spinnifex,
da wir bisher nur eingrenzen können, dass es
a) ein Problem gibt
b) dieses Problem mit dem Hoster und
c) mit UTF-8 Seiten (multi lang) gibt.
Bitte teile uns doch bitte
a) den Hoster
b) die Domain und
c) eine konkrete Seite mit.
Dann(!) können wir dir helfen, ohne, dass sich jeder um die sündhaft teure und aufwändige Anschaffung einer Glaskugel kümmern muss.
Vielen Dank und schöne Grüße,
Christian
certified IT
da wir bisher nur eingrenzen können, dass es
a) ein Problem gibt
b) dieses Problem mit dem Hoster und
c) mit UTF-8 Seiten (multi lang) gibt.
Bitte teile uns doch bitte
a) den Hoster
b) die Domain und
c) eine konkrete Seite mit.
Dann(!) können wir dir helfen, ohne, dass sich jeder um die sündhaft teure und aufwändige Anschaffung einer Glaskugel kümmern muss.
Vielen Dank und schöne Grüße,
Christian
certified IT
Moin,
wurden die Seiten im FTP-Client im "Binary-" oder im Textmodus übertragen ?
Gruß jodel
wurden die Seiten im FTP-Client im "Binary-" oder im Textmodus übertragen ?
Gruß jodel
Moin Jodel
ich habe für den Transfer alle drei in FileZilla verfügbaren Modi (Auto, ASCII und Binär) versucht und weiter im Server-Manager die Übertragung als UTF-8 "erzwungen" (heißt da so.) Leider jedes Mal mit dem gleichen beschi... Ergebnis.
Grüße Spinnifex
ich habe für den Transfer alle drei in FileZilla verfügbaren Modi (Auto, ASCII und Binär) versucht und weiter im Server-Manager die Übertragung als UTF-8 "erzwungen" (heißt da so.) Leider jedes Mal mit dem gleichen beschi... Ergebnis.
Grüße Spinnifex
Hallo allerseits,
inzwischen konnte ich das Problem (zumindest zum größten Teil) lösen:
Offenbar brauchte der Server in der .htaccess nicht nur den Auftrag addCharset: utf-8 .htm, sondern auch für alle anderen verwendeten Dateitypen. Seitdem ich die Datei um gleichlautende Zeilen für .txt und .js ergänzt habe, werden die Umlaute und chinesischen Schriftzeichen korrekt dargestellt.
Das externe JavaScript muss ich mir aber immer noch von einem anderen Server holen. Damit kann ich im Prinzip zwar leben, elegant (und vor Allem technisch nachvollziehbar) finde ich es allerdings nicht.
Schönen Sonntag noch!
Spinnifex
inzwischen konnte ich das Problem (zumindest zum größten Teil) lösen:
Offenbar brauchte der Server in der .htaccess nicht nur den Auftrag addCharset: utf-8 .htm, sondern auch für alle anderen verwendeten Dateitypen. Seitdem ich die Datei um gleichlautende Zeilen für .txt und .js ergänzt habe, werden die Umlaute und chinesischen Schriftzeichen korrekt dargestellt.
Das externe JavaScript muss ich mir aber immer noch von einem anderen Server holen. Damit kann ich im Prinzip zwar leben, elegant (und vor Allem technisch nachvollziehbar) finde ich es allerdings nicht.
Schönen Sonntag noch!
Spinnifex
