FTP-Fileupload mit FileZilla

[00willson]

Servus zusammen.

Habe bei verschiedenen Websites/Providern immer wieder folgendes Problem: nach dem Upload der HTML-Dateien werden Sonderzeichen (insbes. Umlaute) zerstört dargestellt. Die jeweiligen Dateien sind alle mittels Notpad++ in UTF-8 bzw. UTF-8 (ohne BOM) konvertiert. Die HTML-Files selbst tragen ebenfalls den Content-Type UTF-8

  
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">  

Da dies bereis unterschiedliche Provider betraf, gehe ich davon aus, daß es nicht an deren mangelnder UTF-8-Unterstützung liegen sollte. Bliebe also noch mein FTP-Client FileZilla. Hab hier den Transfermode bereits von "automatisch" auf "binär" geändert - erfolglos.

Hat jemand von Euch schon mal von entsprechenden Problemen mit FileZilla gehört? Was könnte ich noch vergessen haben?

Besten Dank vorab!

[Der Martin]

Hallo,

Habe bei verschiedenen Websites/Providern immer wieder folgendes Problem: nach dem Upload der HTML-Dateien werden Sonderzeichen (insbes. Umlaute) zerstört dargestellt. Die jeweiligen Dateien sind alle mittels Notpad++ in UTF-8 bzw. UTF-8 (ohne BOM) konvertiert.

und welche Codierung ist serverseitig eingestellt, also welche Codierung gibt der Server im Content-Type-Header an? Am einfachsten kannst du das mit der LiveHTTP-Extension des Firefox kontrollieren. Vermutlich deklariert der Server die ausgelieferten HTML-Ressourcen noch als ISO-8859-1 oder sowas.

Die HTML-Files selbst tragen ebenfalls den Content-Type UTF-8
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Diese Zeile ist bedeutungslos, wenn im HTTP-Header eine Codierung mitgeteilt wird. Denn die meta-Angabe ist nur ein Fallback für den Fall, dass der Server von sich aus keine Angabe macht.

Da dies bereis unterschiedliche Provider betraf, gehe ich davon aus, daß es nicht an deren mangelnder UTF-8-Unterstützung liegen sollte.

Genau, sondern eher an der falschen Konfiguration.

Bliebe also noch mein FTP-Client FileZilla. Hab hier den Transfermode bereits von "automatisch" auf "binär" geändert - erfolglos.

Ja, das beträfe auch nur die Umwandlung der Zeilenumbrüche. Andere Zeichen dürfen bei der FTP-Übertragung nicht verändert werden.

So long,
 Martin

[dedlfix]

Hi!

Hat jemand von Euch schon mal von entsprechenden Problemen mit FileZilla gehört?

Das Problem ist garantiert nicht die FTP-Übertragung. ASCII und Binär behandeln nur die Zeilenendezeichen.

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Was könnte ich noch vergessen haben?

Du könntest vergessen haben, dass diese Meta-Angabe nur ein Ersatz für den gleichnamigen Content-Type-Header ist. Ist in dem eine charset-Angabe enthalten, wird die Meta-Angabe ignoriert. Wie die Header aussehen, kannst du dir beispielswiese mit der livehttpheaders-Extension für den Firefox ansehen.

Garantiert vergessen hast du, genauer zu beschreiben, was am Ende wie aussieht, denn dann könnte man genauere Tipps geben, was die Ursache sein könnte.

Lo!

[00willson]

Hi Lo,

die Meta-Angaben lauten:
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Du könntest vergessen haben, dass diese Meta-Angabe nur ein Ersatz für den gleichnamigen Content-Type-Header ist. Ist in dem eine charset-Angabe enthalten, wird die Meta-Angabe ignoriert. Wie die Header aussehen, kannst du dir beispielswiese mit der livehttpheaders-Extension für den Firefox ansehen.

Sorry. Umlaute werden wie folgt verunstaltet:
Für --- Für
Über --- Ãœber
möglich --- möglich

Garantiert vergessen hast du, genauer zu beschreiben, was am Ende wie aussieht, denn dann könnte man genauere Tipps geben, was die Ursache sein könnte.

Ok, ich weiß jetzt, daß der Server utf-8 akzetiert, Sonderzeichen aber dennoch abändert. Was bliebe mir denn noch, um eine richtige Darstellung zu gewährleisten? Da der Content auch von anderen Personen gepflegt werden soll, sieht es mit Alternativen wie Entities oder Unicode eher mau aus.

Danke vorab.

[Der Martin]

Hallo,

die Meta-Angaben lauten:
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

das sind keine meta-Angaben, sondern HTTP-Header. Und zwar die, die dein Browser mit der Anforderung an den Server sendet. Da sagt dein Browser bloß dem Server, was er denn so alles annehmen würde (accept).
Was aber antwortet der Server darauf? DAS wäre hier die spannende Frage!

Sorry. Umlaute werden wie folgt verunstaltet:
Für --- Für
Über --- Ãœber
möglich --- möglich

Typisches Erscheinungsbild: Das Dokument ist UTF-8-codiert, der Server deklariert es aber fälschlich als ISO-irgendwas oder sogar Windows-1252, und der Browser hält sich an diese falsche Information - er versucht nach besten Kräften, das Zeug als z.B. ISO-8859-1 zu interpretieren.

Ok, ich weiß jetzt, daß der Server utf-8 akzetiert, Sonderzeichen aber dennoch abändert.

Nein, du weißt, dass dein Browser bereit ist, UTF-8 zu akzeptieren.
Aus den Indizien können wir außerdem ableiten, dass der vom Server gesendete Inhalt auch tatsächlich UTF-8 ist, aber nicht korrekt gekennzeichnet ist (falsche Codierungsangabe im Content-Type-Header).

Da der Content auch von anderen Personen gepflegt werden soll, sieht es mit Alternativen wie Entities oder Unicode eher mau aus.

Wieso? Du verwendest doch schon die ganze Zeit Unicode. Und auf Entity-Referenzen sollte man zugunsten der Lesbarkeit (des Quellcodes) ohnehin verzichten, wenn die gewählte Codierung die Zeichen auch im Klartext darstellen könnte.

So long,
 Martin