[C#] TextBox mit Encodings

[BeRsErKeR]

Hallo,

ich möchte einen kleinen HTML-Editor für eine Applikation schreiben, der eigentlich nur aus einer ToolBar und einer RichTextBox besteht. RichText nur zwecks Syntax-Highlighting, daher können wir für diesen Fall einfach von einer normalen TextBox ausgehen.

Da die HTML-Dateien, die man damit öffnet nicht alle valide sind und somit auch nicht immer ein Meta-Tag mit dem Encoding enthalten biete ich einfach eine ComboBox mit allen verfügbaren Encodings in der ToolBar an, aus der der Anwender das richtige Encoding wählen kann. Beim Umschalten soll sich nun auch der Inhalt der TextBox entsprechend ändern (z.B. für Windows-1252 ein Ö anzeigen, während es mit einem chinesischen Encoding was anderes oder was fehlerhaftes ist). Das Problem ist nun, dass ich mir die Daten immer weiter vermurkse wenn ich die Encodings umstelle und nur den Inhalt der TextBox als Input und gleichzeitig als Output nehme. Nun hab ich mir überlegt die realen Byte-Daten in einem Buffer zusätzlich zu speichern, damit ich davon ausgehend immer den Text aus dem aktuellen Encoding generiere. Das wäre prinzipiell möglich, allerdings soll man den HTML-Inhalt auch in der TextBox ändern können.

Da kommt dann das Problem ins Spiel. Zum einen müsste ich Buffer und Text synchronisieren, zum anderen würde ich mir meinen Buffer wieder kaputt machen, wenn ein Encoding gewählt wird, welches den eingegebenen Text nicht richtig verarbeiten kann.

Hat da jemand eine Idee wie man das elegant lösen könnte? Mein Ziel ist einfach, dass der Anwender fröhlich rumeditieren kann, das passende Encoding auswählt und am Ende die Datei speichern kann, sodass auch was vernünftiges rauskommt.

BOM und Meta-Tag sind leider keine Option. Die HTML-Dateien können von sonstwo herkommen und müssen auch editierbar sein, wenn sie nicht valide sind. :(

[Schrompf]

Ich glaube, es ist eine schlechte Idee, die Datei in jeder Kodierung editierbar zu machen. Mein Vorschlag wäre stattdessen:

- Datei laden
- Kodierung erkennen
- intern konvertieren nach einer von Dir gewählten Standard-Konvertierung, z.B. UTF8
- editieren lassen
- beim Speichern in Zielkodierung konvertieren und schreiben

Das Erkennen der Kodierung ist da das einzige wirkliche Problem, glaube ich. Und vielleicht bringt das .NET-Framework selbst dafür schon was mit.

[BeRsErKeR]

Danke erstmal für die Antwort. Das Encoding erkennen ist prinzipiell nicht möglich, es sei denn ich rate wie es z.B. Notepad macht wenn kein BOM da ist. Aber darauf will ich mich ehrlich gesagt nicht verlassen, da das Programm real eingesetzt wird und Encoding-Fehler ein NoGo sind und verheerende Auswirkungen nach sich ziehen könnten. Allerdings ist dein Ansatz an sich recht gut. Ich lasse beim Öffnen den Anwender das Encoding einmalig auswählen (vielleicht mit einer kleiner Vorschau) und dann einfach nur noch in UTF-8 arbeiten. Am Ende nutze ich das gleiche Encoding, welches der Anwender gewählt hat als Zielencoding. Danke, hat mich weiter gebracht.

[odenter]

Wie hier:
http://blogs.msdn.com/b/oldnewthing/arc ... 58334.aspx
beschrieben.
Entweder sicher erkennen oder als 8-Bit ANSI behandeln.

Kannst ja die API-Funktion IsTextUnicode verwenden, vielleicht benutzt .NET die sogar intern? Dann biste mindestens "genauso" schlecht wie Notepad, aber auf keinen Fall schlechter.

[LaBerg]

C# arbeitet intern bei den strings bzw. chars mit UTF-16 Codierung.
http://msdn.microsoft.com/de-de/library ... 80%29.aspx
http://msdn.microsoft.com/de-de/library ... 80%29.aspx (das kleine string Schlüsselwort ist ja nur ein Alias auf diese Klasse)

Die Text-Property bei der Textbox oder der Richtextbox gibt ja auch einen String zurück.

Die von Schrompf Vorgeschlage Variante beim Öffnen bzw. beim Speichern das Encoding zu erkennen oder den Benutzer wählen zu lassen, ist wohl die praktikabelste Lösung. Wenn man will kann man auch noch eine Umwandlung der Kodierungen implementieren. Wobei dabei ja faktisch nur ein nimm den UTF-16 String, interpretiere ihn als irgendetwas anderes z.B. ANSI und schreibe das wie die Zeichen jetzt aussehen zurück in den UTF-16 String ist. Wenn man jetzt irgendetwas eingibt, kommt mit ziemlicher Sicherheit Kodierungsmischmasch raus.

[BeRsErKeR]

Wie hier:
http://blogs.msdn.com/b/oldnewthing/arc ... 58334.aspx
beschrieben.
Entweder sicher erkennen oder als 8-Bit ANSI behandeln.

Kannst ja die API-Funktion IsTextUnicode verwenden, vielleicht benutzt .NET die sogar intern? Dann biste mindestens "genauso" schlecht wie Notepad, aber auf keinen Fall schlechter.

Naja in diesem Fall weiß der Anwender welches Encoding das Richtige ist bzw. sollte es wissen, da die HTML-Seiten immer Teil eines "Sprach-Pakets" sind. Für westeuropäische Sprachen ist dies immer Windows-1252, für chinesisch, japanisch, koreanisch halt spezielle Encodings usw. Aber der Anwender kennt die Sprache und kann somit durch eine feste Zuordnung von Sprache zu Encoding immer das richtige wählen, daher minimiere ich den Fehler lieber und lasse den Anwender entscheiden. Wenn das Tool rät hat man als Anwender keine Möglichkeit ein eventuell falsch erkanntes Encoding zu korrigieren. Wenn der Anwender das falsche Encoding wählt, dann ist er selbst schuld. Die Anwender wissen aber in diesem Fall genau worum es geht.

C# arbeitet intern bei den strings bzw. chars mit UTF-16 Codierung.
http://msdn.microsoft.com/de-de/library ... 80%29.aspx
http://msdn.microsoft.com/de-de/library ... 80%29.aspx (das kleine string Schlüsselwort ist ja nur ein Alias auf diese Klasse)

Die Text-Property bei der Textbox oder der Richtextbox gibt ja auch einen String zurück.

Die von Schrompf Vorgeschlage Variante beim Öffnen bzw. beim Speichern das Encoding zu erkennen oder den Benutzer wählen zu lassen, ist wohl die praktikabelste Lösung. Wenn man will kann man auch noch eine Umwandlung der Kodierungen implementieren. Wobei dabei ja faktisch nur ein nimm den UTF-16 String, interpretiere ihn als irgendetwas anderes z.B. ANSI und schreibe das wie die Zeichen jetzt aussehen zurück in den UTF-16 String ist. Wenn man jetzt irgendetwas eingibt, kommt mit ziemlicher Sicherheit Kodierungsmischmasch raus.

Naja das hab ich ja bereits gesagt, dass ich dann das Mischmasch-Problem kriege. Ich bräuchte mindestens einen zweiten Buffer, der die unberührten Daten enthält, in welcher Form auch immer, ob nun UTF-16, UTF-8 oder als Byte-Array. Aber wie gesagt ist Schrompfs Ansatz abgewandelt mit "Benutzer wählt das Encoding einmalig" schon in Ordnung für meine Zwecke. ;)