Du gehst wahrscheinlich über "View > ANSI", du müsstest aber "View > Convert to ANSI" auswählen.

Hi.

Bei Textdateien klappt die Methode im Notepad++:


Auch nach erneutem Öffnen wird das richtige Encoding angezeigt.
Bei meiner Test-XML hat das nicht geklappt. Bei XML wird das Encoding in der ersten Zeite definiert:



Damit wird das richtige Encoding in der Notepad++ angezeigt.
Bei HTML dachte ich geht es über



leider wird das Encoding da nach einem Neustart trotzdem nicht aktualisiert, hm..

Standardtextdateien sind plain text, ein Codierungsflag wie bei UTF8 mit BOM ist in der Datei also nicht enthalten.
Wenn der Text die Standardzeichen ohne Umlaute enthält, sie also völlig dem ASCII Code (American Standard Code for Information Interchange) entsprechen, kann das textverarbeitende Programm keinerlei "Spezialcodierung" erkennen.
ASCII ist 7 bit codiert, diese 7 Bit sind im ANSI Format (was ja eigentlich noch kein Code ist, da Länderabhängig) und in den UTF Formaten überall gleich. Abwärtskompatibel also.
Jeder Zilog-Z80, PET, C64, Amiga, ATARI ST und dann PC oder MAC funktioniert insofern völlig gleich und kann ASCII.
Die Umlaute passen da aber nicht rein, so entstanden dann die ANSI Formate (8-Bit und somit auch die zeichen oberhalb 128), die aber Länderabhängige Codepages darstellen.
UTF8 und größer versuchten dann das Wirrwar zu entflechten und bietet einen allgemeingültigen Standard. Gemein ist allen Formaten, die ersten 127 Bit sind entsprechend der ASCII Tabelle immer gleich.

So das alles aus dem Kopf, wer Fehler findet möge mich korrigieren.

Ich hab von den Encodings an sich auch zu wenig Ahnung

Ohne Encoding -> UTF8 (ohne BOM beim Schreiben)
Encoding.UTF8 -> UTF8 mit BOM
Encoding.Unicode -> UTF16 LE
Encoding.Default -> Ansi (CP 1252 in DE)
Encoding.Getencoding(850) -> OEM (DOS) Westeuropa

Hi,

also erstmal kann kein Programm (auch Notepad++ nicht) die Zeichenkodierung einer Datei herauslesen - ganz einfach weil diese Information nirgendwo abgelegt ist. Was ein Editor aber machen kann, ist, die Kodierung richtig zu erraten - was natürlich nur möglich/nötig ist, wenn auch Nicht-Ascii Zeichen enthalten sind, und je mehr desto eher wird das Ergebnis richtig geraten sein. Während beispielsweise die Umlaute in den meisten ISO-8859 Zeichensätzen (genauer gesagt in allen Latin-* Zeichensätzen) gleich kodiert sind (das ä ist beispielsweise #228, also hex E4) kann das bei einem anderen Zeichensatz das solche Zeichen ebenfalls enthält binär völlig anders kodiert sein, je nach Zeichensatz muss das nicht nur 1 Byte sein, es können auch mehrere sein.
Als Beispiel nehmen wir Mal das € Euro Zeichen. In ASCII ist das schonmal nicht mit drin. Dafür aber im Windows-1252 Zeichensatz (hex 80, 1-Byte) oder aber auch in ISO-8859-15 (Latin-9, hex A4, 1-Byte) und ISO-8859-16 (Latin-10, hex A4, 1-Byte) und natürlich auch im Unicode-Standard (U+20AC) und mit dem UTF-8 Zeichensatz zusammengesetzt aus 3 Bytes E2 82 AC).

Multibyte-Zeichen (Zeichen die mit mehr als einem Byte gespeichert werden) sind leichter zu identifizieren, speziell im Unicode-Standard in dem es für die Zusammensetzung aus Multibyte-Zeichen standardisierte Regeln gibt.
Trotzdem ist das Ergebnis mit dem ein Editor die Zeichenkodierung errät eben immer noch der best guess. Im Optimalfall ist die Kodierung bekannt, und in dem Fall sagt man dem Editor, in welcher Kodierung er eine textbasierte Datei laden soll. Nur dann lässt sich mit zuverlässigen Daten arbeiten.

Um nochmal ein paar Mythen klarzustellen:
ANSI ist kein Zeichensatz (Unicode auch nicht btw). Es ist ein Überbegriff für alle ASCII-erweiterten Zeichensätze, bei denen das achte Bit mit Zeichen belegt ist (128-255).

UTF-8 mit und ohne BOM ist dasselbe, das BOM bedeutet nur, dass die Datei ganz am Anfang die Bytes EF BB BF enthält. Grundsätzlich ist es immer besser, BOM nicht zu verwenden, das wurde Mal aus Legacy Gründen eingeführt, hat aber eigentlich keine Relevanz mehr, im Gegenteil führt die Verwendung von BOM mehr zu Problemen als sie lösen kann.

Sowas wie "Plain Text" gibt es nicht, eine textbasierte (also nicht-binäre Datei) braucht immer auch eine Kodierung. Textbasierte Dateien haben keine Informationen über Schriftarten oder Schriftgrößen, "Plaintext" im Zusammenhang mit Text an sich meint daher eigentlich unformatierten Text (also nicht fett, nicht kursiv, nicht unterstrichen etc..), somit also nur Relevant für Word-Dokumente bzw generell Software die mit RTF (Richtextformat) arbeitet. Im Zusammenhang mit textbasierten Dateien hingegen ergibt das Wort Plaintext überhaupt keinen Sinn. Den Begriff Plaintext kann man vielleicht grade noch durchgehen lassen wenn damit ASCII gemeint ist und allen beteiligten dieser Umstand klar ist. Ich weiß das klingt alles etwas verwirrend, aber weil das gleiche Wort in verschiedenen Kontexten verwendet wird, macht es das ganze etwas schwieriger, denn Text ist nicht gleich Text. Textbasierte Dateien können mit Editoren oder über die Konsole ausgelesen werden (Beispiele: txt, html, php, csv, bat, json, ...). Auf der anderen Seite gibt es Dateiformate in denen Text erfasst werden kann, wie zum Beispiel Microsoft Word. Die docx Datei die da am Ende rausfällt ist aber eine Binärdatei, sie kann nur gelesen werden mit dem Programm mit dem sie erstellt wurde (oder andere spezieller Software wie Openoffice oder sowas) - kannst ja mal probieren eine Word-Datei mit Windows notepad zu öffnen oder über die Konsole zu lesen, da kommt nur Gewurschte bei raus. RTF Dateien (Endung .rtf) sind so ein reudiges Quasi-Mittelding, im eigentlichen Sinn handelt es sich ganz klar um textbasierte Dateien, nur dass zusätzliche Anweisungen enthalten sind, die von Microsoft Word oder Wordpad interpretiert werden können und mit denen der Text dann entsprechend formatiert wird.

Um aus diesem Thema die Komplexität rauszunehmen und das besser zu verstehen, empfiehlt es sich, eine Datei parallel in einem Hex Editor zu öffnen (ich empfehle HxD), und dann Mal in Notepad++ ein paar spezielle Zeichen (€ oder Umlaute, alles was nicht ASCII ist eben) einzutippen und zu schauen, wie die Daten im Hexeditor aussehen, nachdem man die Zeichensätze im Notepad++ mal konvertiert (ASCII, Latin, UTF8, ...). Eine Textdatei die nur ein € enthält, wird als UTF8 abgespeichert 3 Bytes groß sein, mit ISO-8859-15 hingegen nur 1 Byte.

Und letztendlich: sowas wie eine "kaputte Datei" oder "kaputte Kodierung" gibt es nicht, es gibt nur sowas wie Dateien, bei denen das Encoding nicht bekannt ist.
Es gibt allerdings sowas wie ungültige Bytesequenzen (also Multibyte-Zeichen, bei denen zB Folgebytes keinen Sinn ergeben).

Zum Schluss kann man sagen, dass Zeichensatz-Probleme fürchterlich schwer zu findende Probleme verursachen können und es tausende Gründe dafür geben kann, das kann in unzählige Stunden Fehlersuche ausarten. All das lässt sich vereinfachen wenn man nur einmal die Grundprinzipien verinnerlicht hat, ab dann ist es fast Pillepalle

Hoffe das hilft.

Link

Hi @Haudruferzappeltnoch,

wenn eine Datei nur ASCII-Zeichen enthält (0-127), wird ein Editor das erkennen und dann auch ASCII als erkannten Zeichensatz vorschlagen. Ich mein, eine Datei in der nur ASCII-Zeichen drin sind, kann natürlich auch in jedem anderen Zeichensatz gespeichert sein, der auf ASCII aufbaut, es ist halt dann in dem Fall einfach nur wurscht. Was ich damit sage ist, wenn du Notepad++ öffnest, ist es egal welchen ASCII-kompatiblen Zeichensatz du festlegst, das ändert nichts am binären Output der generiert wird solang nur ASCII-Zeichen geschrieben werden, und umgekehrt ist es das gleiche beim späteren Laden der Datei.

So wie ich es jetzt verstanden habe, sagst du eine Datei hat gar keine Kodierung.

Ich sagte, dass die Information über die Kodierung nicht vorliegt, bzw. nicht irgendwo abgelegt ist. Also im Grunde hast du recht, man muss das Encoding der Datei mit der man arbeitet kennen, einen anderen Weg gibt's nicht. Das klingt aber wilder als es ist, denn mit dem Unicode-Standard und dem UTF-8 Zeichensatz ist es einfach geworden, man kann so ziemlich sicher davon ausgehen dass eine Datei die man bekommt als UTF-8 gespeichert ist. Und wenn nicht, muss man sich die Kodierung von der Person von der man die Datei bekommen hat sagen lassen - oder halt den Editor raten lassen.
Die Kodierung bezeichnet an sich lediglich eine Tabelle (ein "Mapping") die genutzt wurde, um die Zeichen zu kodieren. Am Ende wird schließlich alles binär mit 1 und 0 gespeichert, wobei wir hier natürlich lieber das dezimale oder hexadezimale Zahlensystem verwenden, wenn wir über Zeichensätze sprechen.
ASCII ist ein 7-Bit-Zeichensatz, was logisch ist, weil maximal 7 bits verwendet werden, um Zeichen zu kodieren (0-127 bzw hex. 00-7F). Das achte Bit (128-255 bzw. hex. 80-FF) wird verwendet von Zeichensätzen, die auf ASCII aufbauen (UTF-8 tut das, ebenso wie die ISO-8859 Zeichensätze und ein paar andere). Hier spricht man dann von "Extended ASCII Zeichensätzen", weil der ASCII-Zeichensatz um die weiteren 128 Bits erweitert wird, um zusätzliche Zeichen zu speichern (fällt dann irgendwie wieder unter den ANSI Überbegriff, ebenso wie "Plaintext" ein fürchterlich verwirrender Begriff weil es sowas wie einen offiziellen ANSI-Standard gar nicht gibt) und quasi das achte Bit vollzumachen.

Lirum larum, ein Zeichensatz ist jedenfalls einfach nur eine Tabelle, die festlegt, welches Zeichen wie kodiert wird:



Willst du also ein "A" in eine Textdatei schreiben, wird die binäre Sequenz 01000001 geschrieben (dezimal 65, hexadezimal 41) - wenn wir aus der Binärsequenz die führenden Nullen weglassen, wirst du feststellen, dass es sich um 7 Bit handelt, die verwendet werden. Das wird 01000001 sein egal ob du ASCII, einen auf ASCII aufbauenden Zeichensatz oder UTF-8 verwendest (UTF-8 ist übrigens vollständig kompatibel zu ASCII).
Du siehst, dass es in dieser Tabelle aber zum Beispiel kein "Ä" gibt - klar, das Zeichen ist im ASCII Zeichensatz eben nicht mit drin. Du musst dich also für einen anderen Zeichensatz entscheiden, in dem die Datei abgespeichert werden soll. Das Zeichen "Ä" gibt es zum Beispiel in allen Latin-* Zeichensätzen, zum Beispiel in Latin-1 (ISO-8859-1) wo es hexadezimal mit C4 kodiert ist (siehe de.wikipedia.org/wiki/ISO_8859-1). C4 (dezimal 196) liegt nicht mehr innerhalb von ASCII (also außerhalb von 0-127) und noch innerhalb von 8 Bit (also zwischen 128-255), gehört somit also zum Extended ASCII. Das Zeichen kann also mit 1 Byte kodiert werden, wenn es mit dem ISO-8859-1 Zeichensatz abgespeichert wird.
Innerhalb des Unicode-Standard findest du es hingegen auf U+00C4 (unicode-table.com/de/00C4/), mit UTF-8 wird das "Ä" Zeichen dann mit 2 Bytes kodiert: C3 und 84. Das heißt wenn deine Datei also ISO-8859-1 gespeichert wird, wird die Datei 1 Byte groß sein, wenn du sie in UTF-8 abspeicherst, wird sie 2 Bytes groß sein. Auch hier ist ein Hex-Editor wieder super:

Gespeichert als UTF-8:



Gespeichert als ISO-8859-1:



In beiden Fällen zeigt der Editor das gleiche an, in der Datei sind das aber beides komplett unterschiedliche binäre Sequenzen. Wenn wir dem Editor sagen, welche Datei in welchem Zeichensatz gespeichert ist, wird er sie richtig darstellen (richtig im Sinne von so wie wir es erwarten, weil wir das Encoding in dem wir die Datei gespeichert haben ja kennen). Wir sagen dem Editor also zum Beispiel "das ist im ISO-8859-1 Zeichensatz abgespeichert worden", und der Editor wird sich den Inhalt der Datei anschauen, das erste Byte holen und auf der ISO-8859-1 Zeichentabelle nachschauen, wie das Zeichen das als C4 gespeichert ist dort drin aussieht, und entsprechend dieses Zeichen laden und anzeigen. Genauso wie wir dem Editor sagen, dass die andere Datei in UTF-8 gespeichert ist, entsprechend wird er also das Byte C3 finden, dann sehen dass es sich um ein Multibyte-Zeichen handelt (siehe Regeln: de.wikipedia.org/wiki/UTF-8#Algorithmus) und entsprechend ein weiteres Folge-Byte erwarten - welches er mit dem zweiten Byte (84) auch vorfindet.

Also kann meine Datei mit einer Kodierung vorliegen, die ich gar nicht möchte oder nicht, wenn nur ASCII Zeichen enthalten sind?

Nein, die Kodierung der Datei wählst du selbst, im Editor. Wenn du eine neue Datei erstellst, legst du vorher den Zeichensatz fest. Beim Eintippen des "Ä" Zeichens wird er je nach gewähltem Zeichensatz die entsprechend passende binäre Sequenz in die Datei schreiben, also 11000100 wenn sie als ISO-8859-1 gespeichert wurde oder 11000011 10000100 wenn als UTF-8 gespeichert wird (oder zusätzlich mit den 3 Bytes 11101111 10111011 10111111 (EF BB BF) am Anfang wenn du als "UTF-8 mit BOM" speicherst).


Link