FileZilla verstümmelt JS-dateien
x51398
0 0 x51398
0 
Rolf B
0 Rolf B
0 
Der Martin
FileZilla verstümmelt JS-dateien
x51398
Gunnar BittersmannGuten Morgen,
seit einigen Wochen zeigt FileZilla ein frustrierendes Verhalten: beim Download einer großen Anzahl von Dateien (komplette Website/CMS) werden einige (auf dem Server intakte) JS-Dateien unbrauchbar, weil mitten in der Datei Code durch kryptische Zeichen ersetzt wird:
{"confirmCleanup":"Der Text, den Sie einfügen möchten, scheint aus MS-Word kopiert zu sein. Möchten Sie ihn zuvor bereinigen lassen?","error":"Aufgrund eines internen Fehlers war es nicht möglich die eingefügten Daten zu bereinigen","title":"Aus Word einf�p�HgwU
Ich habe den Übertragungsmodus im FileZilla auf "auto", "ascii" und "binary" gewechselt, leider ohne Erfolg.
Protokoll ist FTP/TLS.
Was kann das sein?
Vielen Dank, viele grüße Basti
-
seit einigen Wochen zeigt FileZilla ein frustrierendes Verhalten: beim Download einer großen Anzahl von Dateien (komplette Website/CMS) werden einige (auf dem Server intakte) JS-Dateien unbrauchbar, weil mitten in der Datei Code durch kryptische Zeichen ersetzt wird:
Ich habe den Übertragungsmodus im FileZilla auf "auto", "ascii" und "binary" gewechselt, leider ohne Erfolg.
Was kann das sein?
Ich glaube nicht, dass FileZilla hier die Schuld trifft. Gut, dass Du den Screenshot beigefügt hast, mein Verdacht geht nämlich auf VS Code. Spiel mal mit den Codierungen.
-
Ich glaube nicht, dass FileZilla hier die Schuld trifft. Gut, dass Du den Screenshot beigefügt hast, mein Verdacht geht nämlich auf VS Code.
Das glaube ich nicht. Wenn ich die frisch runtergeladene Datei z.B. mit dem notepad.exe öffne, ist die entsprechende Zeile ebenfalls fehlerhaft. Das Problem tritt auch nicht immer auf - wenn ich die entsprechende Datei einzeln runterlade, ist sie meistens in Ordnung. Ich habe den Eindruck, dass der Fehler vorwiegend auftritt, wenn ich viele Dateien runterlade.
Viele Grüße Basti
-
Hallo x51398,
ich habe gerade mal ein schon lang anstehendes Filezilla Update nachgeholt. Und nein - da sind auch in der neuesten Version 3.51 keine Optionen zur Codierungswandlung drin.
Der Unterschied zwischen ASCII und Binary betrifft nur die Zeilenenden. Werden Zeilenenden durch CR+LF, LF+CR, CR oder LF gebildet? Windows verwendet CR+LF, Unix verwendet nur LF, das alte Mac OS hat, wenn ich mich recht erinnere, nur CR verwendet. Filezilla versucht, die Zeilenenden für die jeweilige Zielplattform passend zu machen. Aber von Umlauten lässt er die Finger.
Das Vernichten von Umlauten ist Aufgabe der Zeichencodierung. Die klassische Codierung einer Textdatei verwendet einen Ein-Byte Zeichensatz. Auf Windows heißt der Latin-1 (Codepage 1252), was ISO-8859-1 entspricht. Die Command-Shell von Windows verwendet Codepage 850. Für eine Webseite ist es seit HTML 5 aber verpflichtend, ihre Inhalte UTF-8 codiert als Unicode auszuliefern.
Um das richtig zu machen, muss der Editor richtig eingestellt sein.
Serverseitige Scripte müssen so gebaut sein, dass sie UTF-8 ausgeben. Gerade bei älteren PHP am Server ist das oft nicht so, weil PHP im Kern immer noch auf Latin-1 ausgelegt ist und man scharf achtgeben muss, eine korrekt auf Unicode basierende Server-Anwendung zu schreiben.
Was bei Dir auffällt, ist, dass das ü zunächst korrekt ist (bei "pastetext"), aber dann bei "pastefromword" kaputt ist.
Die Datei wechselt also mittendrin die Codierung; das kann kein Editor dieser Welt auffangen. Sie ist falsch erstellt worden, sie ist mit Editoren bearbeitet worden, die unterschiedliche Codierungen verwenden. Oder von Programmen verändert worden, die unterschiedliche Codierungen verwenden. Du musst die betroffenen Quelldateien reparieren. Es ist kein Problem des Transfers.
Ob für die Abläufe auf der Seite die Codierung in Latin-1 oder UTF-8 die richtige ist, kann Dir von hier aus keiner sagen. Es muss nur konsistent sein.
Rolf
--
sumpsi - posui - obstruxi-
Ein Nachtrag: Dein Editor zeigt unten an: "UTF-8 with BOM". Deine Textdatei beginnt also mit der BOM Sequenz (bei UTF-8 ist das die Bytefolge EF BB BF). Bei pastefromword/title scheint das verletzt zu sein, da hat jemand das ü als Latin-1 oder Codepage 850 eingefügt und das bringt die UTF-8 Codierung aus dem Tritt.
Wer fummelt mit welchen Editoren an dieser Datei herum?
Rolf
--
sumpsi - posui - obstruxi -
Hallo,
Das Vernichten von Umlauten ist Aufgabe der Zeichencodierung.
YMMD! 😀
Die Command-Shell von Windows verwendet Codepage 850.
Oder 437, was dem fest eingebauten Zeichenvorrat der Grafikkarten im Textmodus entspricht.
Für eine Webseite ist es seit HTML 5 aber verpflichtend, ihre Inhalte UTF-8 codiert als Unicode auszuliefern.
Echt?? Das ist mir neu. Dass UTF-8 empfohlen wird, keine Frage. Aber vorgeschrieben?
Was bei Dir auffällt, ist, dass das ü zunächst korrekt ist (bei "pastetext"), aber dann bei "pastefromword" kaputt ist.
Die Datei wechselt also mittendrin die Codierung; das kann kein Editor dieser Welt auffangen.
Ja, aber wie erklärst du dir dann, dass ab dieser Stelle plötzlich ein ganzes Rudel nicht darstellbarer UTF-8-Codes kommt (Ersatzzeichen: Raute mit Fragezeichen)? Wenn der VSCode-Editor hier UTF-8 annimmt und das stimmt am Anfang noch, und dann kommt auf einmal ein ISO-codiertes ü - dann wäre das ein fehlerhaftes, nicht decodierbares Zeichen, danach würde es mit "gen" von "einfügen" weitergehen, schlimmstenfalls wäre noch das "g" verschluckt.
Ich habe den Eindruck, da geht noch viel mehr schief.
Es ist kein Problem des Transfers.
Das würde ich auch mal veermuten.
Live long and
proshealthy,
Martin--
Früher war ich klein und dumm. Inzwischen hat sich so manches geändert. Ich bin größer geworden.-
Hallo Martin,
Echt?? Das ist mir neu. Dass UTF-8 empfohlen wird, keine Frage. Aber vorgeschrieben?
Das hab ich neulich bei MDN gelesen, unter <meta charset>.
Ist das ein alternative fact?
Ja, aber wie erklärst du dir dann, dass ab dieser Stelle plötzlich ein ganzes Rudel nicht darstellbarer UTF-8-Codes kommt
Gute Frage. Ein ü ist FC, also '11111100' - hui, 6 Bits, das ist eine UTF-8 Sequenz aus 6 Bytes und hooooch in den Unicode-Wolken. So hoch, dass wir vermutlich ohne die Gründung der UFP den Bedarf dafür nicht haben werden. Es sei denn, die Emoji-Inflation hält weiter an...
Ein dummer Editor bemerkt vielleicht nicht, dass hinter dem ü kein UTF-8 Fortsetzungszeichen kommt, sondern ein g (0x67).
"einfügen möchten" ist dann noch ein besonders gemeiner Text, weil ü und ö genau 6 Zeichen auseinander liegen. Dem armen Editor wird vom ü ein Bein gestellt, und wenn er sich wieder aufrappelt, trampelt er genau auf das ö. Was da genau passiert, kann man vermutlich nur durch genaueres Studium der Bytes in der Datei betrachten.
Das Müllrudel kann aber auch eine Folge von mehrfach hintereinander erfolgten Codierungs-Unfällen sein und im Verlauf mehrerer Load/Edit+Shred/Save Operationen gewuchert sein.
Rolf
--
sumpsi - posui - obstruxi-
Hi,
Dass UTF-8 empfohlen wird, keine Frage. Aber vorgeschrieben?
Das hab ich neulich bei MDN gelesen, unter <meta charset>.
Ist das ein alternative fact?
zumindest eine Sekundärquelle - ein Browserhersteller. Ich hätte jetzt eher auf irgendwas vom W3C oder der IETF gehofft. Aber heutzutage sind wir ja wieder so weit wie um die Jahrtausendwende, wo Browserhersteller irgendwas implementieren oder definieren, und dann die Beschwörungsformel murmeln: "Es werde Standard."
Mir gefiel das frühere Konzept besser, bei dem ein Gremium Standards definiert und festschreibt. Wobei die Browserhersteller in diesem Gremium durchaus ein Mitspracherecht haben müssen, aber nicht allein vorpreschen dürfen.
Das ist ja in der Industrie genauso: Die Hersteller von Produkten entsenden auch Vertreter in die einschlägigen Normengremien nach Brüssel, in denen über EU-Standards beraten und beschlossen wird.Ja, aber wie erklärst du dir dann, dass ab dieser Stelle plötzlich ein ganzes Rudel nicht darstellbarer UTF-8-Codes kommt
Gute Frage. Ein ü ist FC, also '11111100' - hui, 6 Bits, das ist eine UTF-8 Sequenz aus 6 Bytes und hooooch in den Unicode-Wolken.
Ah. Guter Punkt. So tief bin ich gar nicht eingedrungen.
Anyway, ein anständiger UTF-8-Parser müsste dann aber auch feststellen, dass im nachfolgenden Byte das MSB nicht gesetzt ist, dieses Byte also wieder ein Zeichen für sich darstellt und die eben eingeleitete Sequenz damit abgebrochen werden muss.Ein dummer Editor bemerkt vielleicht nicht, dass hinter dem ü kein UTF-8 Fortsetzungszeichen kommt, sondern ein g (0x67).
Eben, das meinte ich. Das sollte er eigentlich merken. Der Rest deiner Argumentation ist dann aber durchaus nachvollziehbar.
Das Müllrudel kann aber auch eine Folge von mehrfach hintereinander erfolgten Codierungs-Unfällen sein und im Verlauf mehrerer Load/Edit+Shred/Save Operationen gewuchert sein.
Auch vorstellbar.
Live long and
proshealthy,
Martin--
Früher war ich klein und dumm. Inzwischen hat sich so manches geändert. Ich bin größer geworden.-
@@Der Martin
Dass UTF-8 empfohlen wird, keine Frage. Aber vorgeschrieben?
Das hab ich neulich bei MDN gelesen, unter <meta charset>.
Ist das ein alternative fact?
zumindest eine Sekundärquelle
Ja.
ein Browserhersteller.
Nein. An MDN schreiben wohl auch Leute mit, die nicht von Mozilla dafür bezahlt werden. IIRC jetzt sogar ausschließlich.
Ich hätte jetzt eher auf irgendwas vom W3C oder der IETF gehofft.
Das W3C hat die Hoheit über die HTML-Spec zugunsten der WHATWG aufgegeben.
4.2.5.4 Specifying the document's character encoding ist wohl die betreffende Stelle.
Übrigens verlinkt auch die besagte MDN-Seite auf die HTML-Spec, nur eine Hierarchie-Ebene höher: 4.2.5 The meta element.
😷 LLAP
--
“When I was 5 years old, my mother always told me that happiness was the key to life. When I went to school, they asked me what I wanted to be when I grew up. I wrote down ‘happy.’ They told me I didn’t understand the assignment, and I told them they didn’t understand life.” —John Lennon
-
-
-
-
-
-