nicht angemeldet Virtuella
MudGuard
Rolf B
dedlfix
Virtuella
Der Martin
dedlfix
Virtuella
Rolf B
Der Martin
dedlfix
Rolf B
Henry
Hallöchen, ich erstelle mein HTML mit Microsoft Expression. Leider wurden die Umlaute nach einem Umzug zu einem neuen Webhoster nicht mehr richtig angestellt. Warum eigentlich? Hat das irgendwas mit PHP zu tun?
Also habe ich nach der klassischen Anleitung mitteln Notepad++ alle HTMLs in "UTF-8 ohne BOM" konvertiert. Leider hat dies den kompletten Code verhunzt, weil alle Umlaute in kryptische Zeichen umgewandelt wurde (ä in ä, ü in ü, ö in ö etc.)
Nun habe ich mehrere Probleme.
Wie auf der Problemseite zu sehen wird plötzlich das "ß" nicht mehr korrekt angezeigt, sondern sieht jetzt so aus: gro�Ÿe Hoffnung. Warum?
Ich habe keine Ahnung wie ich den verhunzten Code bearbeiten soll. Bislang habe ich alle kryptische Zeichen mühsam wieder in Umlaute verwandelt, dann habe ich das HTML editiert, dann mit Notepad++ geöffnet und zu UTF-8 ohne BOM konvertiert. Gibt es da keine einfachere Lösung? Eine Umwandlung ohne dass der Code so versaut wird? Vielleicht nur eine Änderung im Head der Seite?
Mit der neuesten Version von Notepad++ gibt es das "konvertieren zu UTF-8 ohne BOM" nicht mehr. Und nun?
Ich danke schon mal im Voraus für eure Ideen.
MfG
Hi,
Also habe ich nach der klassischen Anleitung mitteln Notepad++ alle HTMLs in "UTF-8 ohne BOM" konvertiert.
Deine Seite behauptet aber, ISO-8859-1 zu sein:
<meta content="text/html; charset=iso-8859-1" http-equiv="Content-Type">
Leider hat dies den kompletten Code verhunzt, weil alle Umlaute in kryptische Zeichen umgewandelt wurde (ä in ä, ü in ü, ö in ö etc.)
Und das ist dann die Konsequenz ...
cu,
Andreas a/k/a MudGuard
Hallo MudGuard,
das kann sie gerne behaupten, aber wie ich heute morgen gelernt habe, hat ein HTTP Header Vorrang. Und da steht UTF-8.
Die Inhalte sind schräg, weil da vermutlich mehrfach hin- und herkonvertiert wurde und es dann zu Schrott kam. Das ß ist im Unicode, in ISO-8859-1 und auch in der Windows Codepage 1252 auf dem Codepoint 0xDF. In einer UTF-Codierung muss dieser Codepoint in zwei Bytes dargestellt werden, als 0xC3 0x9F.
"gleichermaßen", in UTF-8 gespeichert und als ANSI gelesen, wird damit zu "gleichermaßen"
Das Ÿ hat im Unicode den Codepoint 376, und genau das: Ÿ, findet sich im HTML Quelltext.
Davor steht die Unicodesequenz EF BF BD, was dem Codepoint \ufffd entspricht, das "Ungültig" Zeichen.
Da muss man wohl nochmal vorsichtig von vorn beginnen. Wenn Nodepad++ die Konvertierung nicht mehr beherrscht, ist das natürlich ärgerlich.
Die Behauptung: "Leider hat dies den kompletten Code verhunzt, weil alle Umlaute in kryptische Zeichen umgewandelt wurde (ä in ä, ü in ü, ö in ö etc.)" deutet darauf hin, dass die nach Unicode konvertierten Dateien danach als ANSI geöffnet / dargestellt wurden. Denn die Zeichenfolgen, die Virtuella da zeigt, sind gerade die Zeichenpaare, als die Umlaute in UTF-8 erscheinen.
Hier muss der verwendete Toolstack nochmal genau überprüft werden, was da wo wie eingestellt ist, so dass keine Fehlbedienung vorkommt. Von hier aus lässt sich das kaum beurteilen. Ein Encoding zu migrieren ist leider kein Job der Spaß macht.
Rolf
Tach!
Wenn Nodepad++ die Konvertierung nicht mehr beherrscht, ist das natürlich ärgerlich.
Der Notepad++ ist nicht kaputt. Aber er ist auch kein Zauberkünstler und kann nicht einfach so aus allem möglichen das gewünschte Ergebnis generieren. Er konvertiert von A nach B und kann weder von "unbekannt" nach B oder von "kaputter Datei" nach B konvertieren.
Sein Encoding-Menü besteht aus zwei Teilen. Im oberen ist die derzeitige Codierung eingestellt und auch auswählbar. Beim Öffnen der Datei versucht er aus ein paar Indizien die Kodierung zu erraten. Wenn der Text im Editierfeld nicht richtig angezeigt wird, kann man versuchen, die Angabe im oberen Teil umzustellen. Dann versucht er den Text nach dieser Kodierung zu dekodieren. Findet man eine Kodierung, mit der der Text richtig dargestellt wird, kann man im unteren Teil des Menüs eine der "Convert to"-Punkte auswählen, und alles sollte gut werden. Findet man im oberen Teil keine passende Kodierung, dann hat man ein Problem, dessen Ursache man erst ermitteln muss, bevor man es lösen kann. Oder man repariert den Text per Hand.
dedlfix.
Danke & Moin Moin, und es gibt keine Möglichkeit, Umlaute korrekt darstellen zu lassen, ohne dass der ganze Code nachher mit ä, ü und ö gespickt ist? Gibt es eine Möglichkeit, allein im Header was reinzuschreiben?
Und wie soll man diesen Schrottcode editieren? Geht das nur indem man immer hin- und her-konvertiert?
Hallo,
und es gibt keine Möglichkeit, Umlaute korrekt darstellen zu lassen, ohne dass der ganze Code nachher mit ä, ü und ö gespickt ist?
nein, wohl kaum. Um das alte Beispiel mal wieder zu bemühen: Wenn du ein Glas Erdbeermarmelade nimmst und "Akazienhonig" draufschreibst, ändert das am Inhalt nichts. Es wird allenfalls für Verwirrung sorgen.
Gibt es eine Möglichkeit, allein im Header was reinzuschreiben?
Im Header (HTTP-Header und meta-Element in HTML) muss die Codierung angegeben werden, in der die Dokumente auch tatsächlich codiert sind.
Und wie soll man diesen Schrottcode editieren? Geht das nur indem man immer hin- und her-konvertiert?
Ja, natürlich. Und da bei jeder Konvertierung Verluste entstehen können (nicht jede Codierung kann alle Zeichen darstellen), sollte man das lieber vermeiden, indem man konsequent UTF-8 verwendet. Diese Codierung baut auf Unicode auf, der Obermenge aller derzeit existierenden Zeichensätze.
Live long and pros healthy,
Martin
Tach!
und es gibt keine Möglichkeit, Umlaute korrekt darstellen zu lassen, ohne dass der ganze Code nachher mit ä, ü und ö gespickt ist? Gibt es eine Möglichkeit, allein im Header was reinzuschreiben?
Ja doch, aber um eine Kodierung zu entschlüsseln, muss man zum einen den Schlüssel kennen und zum anderen müssen die Daten entsprechend dem Schlüssel kodiert sein. Der Schlüssel ist hier der Name der Kodierung und die dazu passende und öffentlich bekannte Kodierungsvorschrift. Wenn also zum einen die Kodierung bekannt ist und zum anderen die Daten dieser Kodierung entsprechen, dann kann man sie korrekt darstellen.
Man kann aber keinen Algorithmus erstellen, der von "unbekannt" in eine bestimmte Zielkodierung konvertiert. Deshalb gibt es keine Möglichkeit der automatischen Reparatur.
Man kann lediglich anhand einer Indizien und mit Ausschlussverfahren vermuten, dass ein Text in einer bestimmten Kodierung ist, aber ohne menschliche Bestätigung kann das kein Programm zweifelsfrei feststellen.
Und wie soll man diesen Schrottcode editieren? Geht das nur indem man immer hin- und her-konvertiert?
Wenn du Quell- und Ziel-Kodierung kennst, dann ja. Wenn die Kodierung nicht bekannt ist, kann kein Algorithmus sie korrekt konvertieren. Dann musst du mit deinem menschlichen Verstand erraten, was der Text eigentlich sein sollte und ihn per Hand reparieren.
dedlfix.
Kennt ihr einen Freeware-WYSIWYG-Editor wie Microsoft Expression, der aber gleich in UTF-8 codiert?
Warum trat bei meinem alten Webhoster kein Umlaute-Problem auf?
THX!
Warum trat bei meinem alten Webhoster kein Umlaute-Problem auf?
Bei wurde sicherlich in den HTTP-Headern die Information gesendet, dass die Webseiten (und alles andere auch …) gemäß ISO-8859-15 kodiert seien.
Und sicher konntest Du das auch bei dem irgendwo umstellen. (und sei es in der Datei '.htaccess' in dem Verzeichnis Deines Webauftritts)
Warum trat bei meinem alten Webhoster kein Umlaute-Problem auf?
Bei wurde sicherlich in den HTTP-Headern die Information gesendet, dass die Webseiten (und alles andere auch …) gemäß ISO-8859-15 kodiert seien.
Ach so. Das ist reichlich unmodern. Anno 2020 wäre das „Nichtproblem“ genau ein „Großproblem“.
Hallo Raketenwill,
witzigerweise ist ISO-8859-15 zwar die für Westeuropa relevante Norm, aber trotzdem hat es keine Bedeutung (sagt Wikipedia und verlinkt hierhin).
Die Webdesigner, die nicht nach UTF-8 gewechselt sind, sind scheinbar bei USO-8859-1 geblieben und schreiben lieber €, € oder - wenn sie einen progressiven Tag haben - € in den Quelltext...
Rolf
Hallo,
Die Webdesigner, die nicht nach UTF-8 gewechselt sind, sind scheinbar bei USO-8859-1 geblieben und schreiben lieber
€,€oder - wenn sie einen progressiven Tag haben -€in den Quelltext...
oder noch besser "EUR" oder salopp "EU$".
Live long and pros healthy,
Martin
Tach!
Die Webdesigner, die nicht nach UTF-8 gewechselt sind, sind scheinbar bei USO-8859-1 geblieben und schreiben lieber
€,€oder - wenn sie einen progressiven Tag haben -€in den Quelltext...
So umständlich machen sie es nicht. Die schreiben einfach €, das wird gemäß Win-1252 kodiert und die Browser interpretieren die Angabe ISO-8859-1 in Wirklichkeit als Win-1252.
dedlfix.
Hallo Virtuella,
die Expression-Softwarefamilie ist seit 10 Jahren tot, bzw. MS hat beschlossen, die Bausteine Web und Design zu Freeware zu machen (Blend wurde Teil von Visual Studio).
Du wirst vermutlich Expression Web benutzen, vielleicht auch Design. Obwohl das Ding 10 Jahre alt ist, sollte es eigentlich Unicode (also UTF-8) fähig sein - ich finde allerdings Aussagen, dass es da Bugs gäbe. Vieles, was Web kann, dürfte für Dich überflüssig sein. Es sei denn, du baust ASP.NET Webseiten.
Ein reiner, aber reichhaltiger Texteditor ist Visual Studio Code. Auch Freeware. Nur hast Du da keine HTML Designer und keinen "Wie sieht's im Browser aus" Preview, wie dem Vernehmen nach in Expression Web. Als Abkömmling des großen Visual Studio dürfte er aber mit Unicode keine Probleme haben.
Warum trat bei meinem alten Webhoster kein Umlaute-Problem auf?
Das liegt an den Gründen. Leider hat jemand meine Glaskugel gesandstrahlt, darum kann ich sie Dir nicht nennen.
Nein, ehrlich, das kann so viele Ursachen haben, dass man darüber seitenlang spekulieren kann und vermutlich trotzdem noch was übersieht. Es kann am Hoster liegen, an der Art wie Du dorthin Dateien hochlädst, an eine Einstellung der Serverkonfiguration, die Du nicht mitgenommen hast - tausend Sachen.
Rolf
Hallo Virtuella,
- Mit der neuesten Version von Notepad++ gibt es das "konvertieren zu UTF-8 ohne BOM" nicht mehr. Und nun?
Doch das geht, du musst halt nur ein paar Zeichen drin haben, die UTF-8 notwendig sind. Also zb. sobald du ein paar Umlaute drin hast, klappts. Daher habe ich mir angewöhnt im Quelltext das iregendwo versteckt drin zu haben.
Zu deiner Seite, du nutzt eine Menge Bildmaterial, was dir nochmal Rechteprobleme bringen könnte. Gerade heute wurde die Thematik nochmal verschärft.
Dann zu deiner Vorliebe für WYSIWYG, das mag vielleicht für Standardseiten noch hilfreich sein. Aber gerade wenn jemand, so wie du, Datensammlungen anbieten will ist es, auch wenn du das jetzt noch nicht glaubst, auf Dauer entspannter und variabler sich ein bisschen HTML und PHP beiszubringen, spart danach ungemein Zeit und bringt unendliche Möglichkeiten.
Gruss
Henry
Tach!
- Mit der neuesten Version von Notepad++ gibt es das "konvertieren zu UTF-8 ohne BOM" nicht mehr. Und nun?
Doch das geht, du musst halt nur ein paar Zeichen drin haben, die UTF-8 notwendig sind. Also zb. sobald du ein paar Umlaute drin hast, klappts. Daher habe ich mir angewöhnt im Quelltext das iregendwo versteckt drin zu haben.
So einfach ist das nicht. Umlaute können auch ISO-8859-1-kodiert sein. Außerdem hat sie ja Nicht-ASCII-Zeichen drin, sonst gäbe es ja keine Probleme.
dedlfix.
Hallo dedlfix,
So einfach ist das nicht. Umlaute können auch ISO-8859-1-kodiert sein. Außerdem hat sie ja Nicht-ASCII-Zeichen drin, sonst gäbe es ja keine Probleme.
Ach so, gemeint waren ihre Dokumente. Dachte wäre allgemein zu Notepad++. Und daher, weil ich ja mal ähnliche Probleme in der Richtung hatte…
Gruss
Henry
