UTF-8 String in RichTextBox anzeigen

hkdd

@Th69 sagte in UTF-8 String in RichTextBox anzeigen:

Welche .NET-Version benutzt du? Ab Version 4.7 ist das wohl gefixt

das könnte die Ursache sein (werde ich probieren).
Ich benutze für bestimmte Programme die 4 (nicht 4.7),
weil nur dadurch diese Programme auch unter XP funktionieren.

Th69

Dann nimm den von mir oben beschriebenen Workaround (jedoch wird das Herzchen dann wohl auch nicht unter XP angezeigt werden, wenn es schon nicht für Win7 klappt).

Mit welcher Windows-Version hast du es denn erstellt und getestet?

Und beim StreamWriter ist UTF-8 das Standard-Encoding (wenn man es nicht explizit angibt), aber ohne BOM: StreamWriter(string) (s. Hinweise)
So gesehen liefert dein Testprogramm jetzt nichts Interessantes.

Dravere

@hkdd Die dotNet String Klasse verwendet intern UTF-16. Der StreamWriter schreibt standardmässig mit UTF-8. Findest du in der Dokumentation:

This constructor creates a StreamWriter with UTF-8 encoding without a Byte-Order Mark (BOM), so its GetPreamble method returns an empty byte array.

Das Problem ist die Darstellung und diese wird von Fonts und Controls übernommen. Und es gibt viele unterschiedliche Arten von Fonts. Und gewisse Controls können mit gewissen Fonts oder spezifischen Zeichen nicht umgehen. Daher hat dies nichts mit Enkodierung oder Unicode zu tun. Hier geht es nur um die Darstellung.

UTF-8, UTF-16 und UTF-32 sagen nichts über die Darstellung aus. Das sind ausschliesslich Definitionen, wie die rohen Textdaten (also Code points) gespeichert werden sollen.

hkdd

@Th69 sagte in UTF-8 String in RichTextBox anzeigen:

Mit welcher Windows-Version hast du es denn erstellt und getestet?

Mit Win10-Pro-64 1903

firefly

@Dravere sagte in UTF-8 String in RichTextBox anzeigen:

@hkdd Die dotNet String Klasse verwendet intern UTF-16. Der StreamWriter schreibt standardmässig mit UTF-8. Findest du in der Dokumentation:

This constructor creates a StreamWriter with UTF-8 encoding without a Byte-Order Mark (BOM), so its GetPreamble method returns an empty byte array.

Das Problem ist die Darstellung und diese wird von Fonts und Controls übernommen. Und es gibt viele unterschiedliche Arten von Fonts. Und gewisse Controls können mit gewissen Fonts oder spezifischen Zeichen nicht umgehen. Daher hat dies nichts mit Enkodierung oder Unicode zu tun. Hier geht es nur um die Darstellung.

UTF-8, UTF-16 und UTF-32 sagen nichts über die Darstellung aus. Das sind ausschliesslich Definitionen, wie die rohen Textdaten (also Code points) gespeichert werden sollen.

Das ist richtig. Nur soweit ich weis ist UTF-8 Support in .Net selbst für Controls nicht vorgesehen sonder UTF-16 (Das ist die standard UNICODE Kodierung von Windows)
Daher sollte man das ganze nochmal prüfen, wenn man den UTF-8 String (Der bestimmt nicht als C# String vorhanden ist, da die String klasse UTF-16 verwendet) nach UTF-16 konvertiert wird bevor es dem Control übergeben wird

hustbaer

@firefly Bitte nicht wieder das UTF-8 Thema aufwärmen, das hatten wir jetzt doch erfolgreich durch. Hier ist kein UTF-8 im Spiel. @hkdd hatte das nur fälschlich angenommen weil seine Source-Files UTF-8 sind. Die CLR Strings die daraus entstehen sind aber schon UTF-16, und falsch konvertiert wird da auch sicher nichts. Weil UTF-8 -> UTF-16 Konvertierung ein paar einfache Zeilen Code sind, in denen bloss ein paar Bits rumgeschoben werden.

hustbaer

@hkdd Bitte lerne mal ein bisschen was über die Tools mit denen du da arbeitest. Alle Strings in .NET sind immer UTF-16. Dass du im File UTF-8 bekommst, liegt daran, dass das Default-Encoding eines StreamWriter, wenn du keines angibst, halt UTF-8 ist.

Hier https://docs.microsoft.com/en-us/dotnet/api/system.io.streamwriter?view=netframework-4.8

StreamWriter defaults to using an instance of UTF8Encoding unless specified otherwise.

Im Speicher sind .NET Strings trotzdem immer UTF-16, und sämtliche Windows Controls (ob .NET oder nicht) arbeiten auch immer mit UTF-16. (Also ausgenommen auf DOS-basierten Windowsen ala 95/Me.)

UTF-8 ist und war hier nie im Spiel, wenn man mal von Encoding deiner Source-Files absieht.

Das Problem ist das (nicht vorhandene) Spezialhandling von Emoticons und/oder allgemein Zeichen die im aktuellen Font nicht vorkommen. (Ich schätze mal dass Emoticons überhaupt super-spezial behandelt werden, da sie farbig dargestellt werden. Und IIRC können normale Schriftarten überhaupt gar keine farbigen Glyphen enthalten.)

hkdd

@hustbaer ,
ok, ich habe also viel über UTF-16 erfahren.
Ursprünglich ging es mir lediglich darum, dass ich in einem Log-Fenster (zunächst im RichText-Format) u.a. die Namen von Dateien und Pfaden protokolliere. Dabei ist es mir völlig egal, in welchem Format das passiert. Das RichText-Fenster hat diese Zeichen nicht angezeigt. Ich habe sie erst kennen gelernt, seit meine drei Enkel ihre Dateien und Namen in den iPhones alle mit so einem Herz gekennzeichnet haben und ich beim Sichern dieser Dateien Probleme mit diesen Dateinamen bekam.
Nun habe ich das mit C# und einem Edit-Fenster gelöst.
Parallel habe ich das Programm in Delphi programmiert und dort gab es ebenfalls derartige Probleme mit diesem Zeichen. Die habe ich inzwischen auch gelöst.
Beide Versionen können mit diesem Zeichen umgehen.
Korrekt angezeigt wird es ab Windows 8.1.
Unter Win7 und XP wird ein Quadrat angezeigt.

Ich bin ja lediglich eine Hobby-Programmierer auf dem PC.
Früher habe ich viele Jahr Host-Programme auf IBM-Großrechnern erstellt. Und parallel etwas C++ und Delphi und vor Windows mit C++ und Turbo Pascal.

Bei Problemen versuche ich im Forum und bei Google eine Lösung zu finden. Und dafür danke ich Euch allen.

hkdd

@hustbaer sagte in UTF-8 String in RichTextBox anzeigen:

dass das Default-Encoding eines StreamWriter, wenn du keines angibst, halt UTF-8 ist.

Ich habe den StreamWriter lediglich für dieses kleine Testprogramm benutzt, weil ich einen Weg gesucht habe, einen String auszugeben und dann in der Datei zu sehen, wie er aufgebaut ist. Lieber wäre es mir gewesen, ich hätte im Debugger eine Möglichkeit gefunden den String im Hex-Format ansehen zu können, so wie er tatsächlich im Speicher steht.
Mir ist das nicht gelungen, entweder, weil das nicht geht oder weil ich nicht weiß, wie man das macht.

Th69

Das hättest du gleich schreiben sollen ;- )
Für VS 2017 gibt es z.B. den HexVisualizer 2017.