Notepad "verbiegt" Zeichen mit Akzenten

  • Allgemein

Es gibt 9 Antworten in diesem Thema. Der letzte Beitrag () ist von Link.

    Notepad "verbiegt" Zeichen mit Akzenten

    Hi,

    ich habe hier ein Problem, dass nicht so ganz einfach zu beschreiben ist. Ich hoffe, ihr habt ein wenig Geduld.

    Ich habe im Internet eine Seite gefunden, die ich gern offline verwenden möchte. Dazu habe ich den .html File aus dem Netz geladen. Das klappt ohne Probleme. Mit Doppelclick, kann ich die Seite öffnen und auch ohne Netzverbindung auf meinem Bildschirm anzeigen. (s. Display ok.jpg)

    Die Seite enthält sehr viele Buchstaben mit Akzenten. Die werden erst mal auch völlig richtig angezeigt. Wenn ich den .htlm Code aber verändere, dann ist der .html File sofort beschädigt. Die Akzente werden nicht mehr richtig angezeigt. (s. Display corrupted.jpg)

    Es genügt schon, dass ich nur die Seite im Notepad öffne und speichere, um diesen unangenehmen Effekt auszulösen.

    Ich habe einen solchen Problemstring im HexEditor untersucht und die Inhalte verglichen (s. html ok.jpg und html corrupted.jpg)

    Offensichtlich wird das Zeichen "ó" verbogen. aus "F3" wird "EF BF DF". Dabei dürfte es sich um UTF-8 handeln.

    Das ist leider kein Einzelfall, sondern tritt sehr häufig bei HTML Dokumenten aus dem Internet auf. Und natürlich ist ein solches Dokument danach unbrauchbar !

    Offensichtlich interpretiert Firefox und Edge etc. den originalen HTML File vollkommen richtig. Aber der Editor kommt damit nicht klar und verbiegt die Zeichen mit Akzent.

    Wie kann ich das vermeiden ... korrigieren ... umgehen. Vielleicht mit einer in VB geschriebenen Routine?

    Uff ... keine leichte Kost. Ich hoffe, ich habe mein Problem trotzdem verständlich machen können. Es wäre mir sehr wichtig, diese Sache irgendwie vernünftig lösen zu können.

    LG
    Peter

    *Topic verschoben*
    Bilder
    • html corrupted.jpg

      8,17 kB, 597×26, 74 mal angesehen
    • html ok.jpg

      11,86 kB, 605×43, 70 mal angesehen
    • Display corrupted.jpg

      11,71 kB, 982×62, 71 mal angesehen
    • Display ok.jpg

      10,86 kB, 982×62, 72 mal angesehen

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Marcus Gräfe“ ()

    @Peter329 Wie sieht es denn aus, wenn Du den Seitenquelltext anzeigst:
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    ok ... ich habe damit jetzt experimentiert:

    wenn ich in den .html File per Tastaur "ó" eingebe (Akzent + o), dann erscheint auch ein "ó" im Quelltext und mit dem HexEditor sieht man, dass dies hexadezimal mit "C3 B3" gespeichert wird. Offensichtlich generiert der Editor also UTF8. Aber vom Browser wird dieses Zeichen dann allerding im Bildschirm als "ó "vom angezeigt. Offenischtlich erwartet der Browser also kein UTF8.

    Nur wenn ich mit dem HexEditor ein hexadezimales "F3" mit der Brechstange eingebe , dann wird am Bildschirm auch ein "ó" angezeigt. Der Browser erwartet also ASCII.

    Irgendwas hat der File ... ich weiß nur nicht was. Ich habe geschaut ob das Dingens vielleicht eine BOM hat ... aber da iss nix. Der Code beginnt mit dem ersten HTML Tag ...

    Ich bin wieder mal am verzweifeln ...

    Any bright ideas ?

    LG
    Peter
    @Peter329 Möglicherweise musst Du den Text mehrfach hin- und her-konvertieren, je nachdem, was der betreffende Editor bzw. die Anzeige von Dir erwartet.
    Ggf. finde Code für einen eigenen HTML-Editor, dann hast Du alles in einem Programm.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Eierlein schrieb:

    Wenn du Ansi brauchst, einfach bei »Speichern unter« die Codierung auf Ansi stellen.


    Das hatte ich schon vorher versucht. Und das hat leider auch einen "korrumpierten" File geliefert. Aber dein Vorschlag hat mich jetzt auf die richtige Idee gebracht.

    Der File wird offensichtlich bereits beim Einlesen verstrubbelt, weil das standardmäßige "Auto-Detect" den File (fälschlicherweise) als "UTF8" einordnet ! Dann kann ich mich abstrampeln ... und wenn ich den File hinterher als "ANSI" speichere, ist das Kind längst in den Brunnen gefallen. Jetzt verstehe ich das endlich.

    Ich muss also beim ÖFFNEN des Files "Auto-Detect" auf "ANSI" ändern und schon klappt die Sache !

    Wieso aber erkennen die Browser den File richtig ? Das liegt daran das bei einem HTML File das Encoding in einem der ersten Tags festgelegt wird. (Das muss ganz vorne stehen, damit die nachfolgenden Tags richtig gelesen werden können ... :) ). Wenn es kein solches Tag gibt, dann wird ANSI als Default genommen. Und deswegen erscheint mein File im Browser fehlerfrei !

    Ich brauche also kein VB Programm zum Konvertieren!

    Uff ... bin ich erleichtert. Ich habe nämlich bis dato die vermaledeiten Akzente von Hand geändert ! :)

    Jetzt habe ich (interessehalber) nur noch eine Frage: Wieso glaubt Notepad, dass mein bescheidener File aus dem Internet in UTF8 kodiert ist ? Außer den Sonderzeichen gibt es nix, was außergewöhnlich an den Daten wäre. Und diese Sonderzeichen sind doch ganz einfach Zeichen aus den oberen 128 Zeichen des ASCII Zeichensatzes. Mit anderen Worten, wie funktioniert "Auto-Detect" beim Notepad ... wenn es insbesondere keine BOM gibt ? Könnte es sein, dass Notepad so "blond" ist und einfach das erste Bit aus hex "F3" als UTF-Verkettung erkennt ?

    LG
    Peter
    Files ohne BOM und ohne Encoding-Attribut im ersten xml-Tag sind encoding-mässig uneindeutig.
    Bin ich aber enttäuscht, wenn Notepad bei Auto-Detect so schlecht rät - weil es gibt da ziemlich gute Heuristiken, die grade diese > 128-chars untersuchen.
    Andererseits ist utf-8 schon weltweit das bevorzugte Encoding (und langsam aber sicher im Vormarsch), und sollte in Zweifelsfällen immer bevorzugt werden.
    @Peter329 Nimm nicht das Notepad, sondern Notapad++, da solltest Du weniger Probleme haben
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Offensichtlich interpretiert Firefox und Edge etc.


    "Interpretieren" ist an dem Punkt schon beinahe ein Fehler - fühlt sich an wie "raten". Wenn man mit textbasierten Dateien arbeitet, sollte das Encoding bekannt sein in dem die Datei geschrieben wurde. Klar gibt's sowas wie autodetect sodass anhand von hexadezimalsequenzen nach Multibyte-Zeichen gesucht wird und womöglich ist der best guess dann auch ein Treffer, darauf sollte man sich aber nicht immer verlassen.

    Offensichtlich wird das Zeichen "ó" verbogen.

    In der Datei gibt es technisch gesehen kein "ó". Die Datei ist eine Sequenz binärer Stellen die in einem bestimmten Zeichensatz bedeuten kann, dass dort ein "ó" ist - das Encoding in welchem du eine Datei schreibst wird entscheiden, wie der Binärstream aussehen wird. Das "ó" ist im extended Ascii zu finden (#243 / F3), somit also schon über die 0-127 für Single-Byte-Characters drüber und in der Unicode-Tabelle somit ein Multibyte-Zeichen mit 2 oder mehr Bytes - konkret bestehend aus 2 Bytes, nämlich C3 und B3. Wenn du das Zeichen jetzt als UTF-8 abspeichern würdest, hättest du eine Datei mit hexadezimaler Folge "C3 B3". Wenn du sie mit Notepad++ öffnest und konvertierst zu ANSI, so wird die Datei mit der hexadezimalen Folge "F3" abgespeichert. Kannst du direkt mit einem Hex-Editor ausprobieren, HxD ist dafür mein favorisiertes Tool.
    Wenn du also die als UTF-8 kodierte Datei mit dem ANSI Zeichensatz öffnest, wirst du ó zu sehen kriegen - klar, ANSI kennt nur Singlebyte-Encoding, das heißt 1 Byte ist 1 Zeichen, und weil 2 Byte drin sind, wird C3 zu à und B3 zu ³ aufgelöst.
    Wenn du die als ANSI kodierte Datei (F3) mit UTF-8 laden willst in Notepad++, dann wirst du xF3 mit schwarzem Hintergrund zu sehen kriegen - er weiß nicht wie er es darstellen soll, Grund dafür ist dass du die Datei mit UTF-8 zu öffnen versuchst, wo dieses Zeichen nur mit 2 Bytes (C3 B3) "richtig" zu "ó" aufgelöst wird - du erinnerst dich, Singlebyte Zeichen sind die von 0-127 bzw hexadezimal 0-7F, F3 ist 243 und würde somit wenigstens 2 Bytes beanspruchen, dementsprechend tritt ein Fehler auf "Missing Continuation Bytes", UTF-8 schimpft weil es das nächste Byte einer Multibyte-Sequenz sucht und nicht findet.
    Btw, mit einem voranstehenden Nullbyte (somit "00 F3") würde es zumindest mit UTF-16 (Big Endian) wieder funktionieren, das gewünschte Zeichen darzustellen.



    Im Screenshot ist derzeit die Datei geöffnet, die hexadezimal abgespeichert ist mit "F3" und sie wird mit ANSI geöffnet - passt. Ein Klick auf "UTF-8 ohne BOM" würde jetzt versuchen, das F3 mit UTF-8 darzustellen - wie zuvor erklärt wird das nicht klappen. Du kannst aber den angezeigten Inhalt der Datei konvertieren, ein Klick auf "Konvertiere zu UTF-8 ohne BOM" würde somit "C3 B3" schreiben, die Datei ist dann 2 Byte groß. Und diese Datei dann mit ANSI zu laden würde wieder "ó" darstellen.
    Um das schnell zu verstehen ist es am besten, Notepad++ und HxD parallel zu öffnen und die Datei zu verändern und verschiedene Konvertierungen vorzunehmen um zu sehen wie sich das auf den tatsächlichen Binärstream auswirkt.
    Schau auch mal hier: unicode-table.com/de/00F3/

    Wir leben in 2021, davon auszugehen dass eine Datei als UTF-8 vorliegt, ist absolut okay. Manchmal hat man mit älteren Projekten zu tun und es gibt Zeichensatz-Schwierigkeiten. Hier ist Vorsicht geboten, eine Konvertierung sollte nicht vorgenommen werden, das kann nämlich wirklich alles kaputt machen. Die Datei an sich ist nicht "falsch" oder "kaputt", es wird zum Laden einfach nicht das Encoding benutzt wie das mit dem die Datei geschrieben wurde. Wenn eine Datei nicht so aussieht wie man es erwartet, muss man sie einfach nur im korrekten Encoding laden - wenn es also nicht UTF-8 ist, dann im Zweifelsfall sowas wie ANSI, Windows-1252 oder Latin1 ausprobieren.

    PS: UTF-8 ist ein platzsparender Kompromiss, denn es erkennt anhand eines intelligenten festgelegten Schemas ob ein bestimmtes Zeichen aus einem, 2, 3 oder 4 Bytes besteht. Das reduziert den Overhead und ist deswegen auch zu 100% kompatibel für alle ASCII Zeichen. UTF-16 hingegen wird für jedes Zeichen 2 Bytes belegen (auch für Single-Byte-Zeichen, also alles von 0-127) und UTF-32 wird dasselbe tun, nur eben sogar mit 4 Bytes pro Zeichen, indem es Zeichen die nicht die volle Länge belegen mit Nullbytes auffüllt (bei Big Endian mit vorangestellten und bei Little Endian mit nachfolgenden Nullbytes). Das Zeichen "A" ist also in UTF-8 und ASCII dann "41", in UTF-16 ist es "00 41" und in UTF-32 ist es "00 00 00 41".


    Tolles Lese-Material:
    ionos.de/digitalguide/websites…-digitaler-kommunikation/ (deutsch)
    joelonsoftware.com/2003/10/08/…haracter-sets-no-excuses/ (englisch, sehr lesenswert)


    Grüße
    Link
    Hello World

    Dieser Beitrag wurde bereits 13 mal editiert, zuletzt von „Link“ ()