Char 2 Byte gross !

[Warf]

Naja zum einen effizienz. Zugriff auf einzelne Chars per Index geht in einer Operation, während es bei UTF-8 immer ein Lineares Suchproblem ist. Das macht für User Programme nicht viel aus, aber auf Btriebsystem Ebene wie Windows, oder im Low Level Emulator der JVM oder CLR (.Net) kann das schon einen Relevanten Performance Unterschied machen.
Bei Windows kommt noch Historie hinzu, als Windows Internationalisierung unterstützen musste im NT Kernel gab es noch kein UTF-8 und der Unicode Space war auch noch nicht voll Durchspezifiziert, aber Microsoft konnte nicht warten weil ihnen Internationale Kunden aufs Dach gestiegen sind, und daher haben sie das genommen was da war, eine nicht fertige Version von UTF-16. Es löst die Probleme natürlich nicht vollständig, zum einen gab es noch Änderungen an den Unicode Codepunkten weshalb es nicht komplett UTF-16 Kompatibel ist (Witzelnd oft daher WTF-16 genannt), zum anderen reicht UTF-16 natürlich auch nicht (es gibt >80k Chinesische Zeichen im Unicode aber UTF-16 kann nur 65k Zeichen, das passt also nicht), weshalb Unicode Planes eingeführt wurden, womit UTF-16 im Grunde auch nur ein verstecktes UTF-32 ist.

UTF-8 hat sich allerdings durchgesetzt, weshalb es mittlerweile alle (offiziellen) Windows APIs als UTF-8 version gibt, und auch mit Java 18 (in 2022) Java auch offiziell per Default auf UTF-8 gewechselt hat, womit Microsofts .Net so ziemlich das letzte Verbleibende System ist was auf UTF-16 setzt.

Ich kann verstehen wenn man einen Delphi kompatibilitätsmodus haben will, die RTL ist ja jetzt nicht so groß das man die nicht auch in 2 versionen ausliefern könnte. Aber jetzt auf UTF-16 als Default zu gehen wenn alle anderen davon weg gehen halte ich für eine sehr Fragwürdige Entscheidung, umso mehr wenn es auch nicht mal Einheitlich über die Plattformen hinweg ist.

[Mathias]

Bei Windows kommt noch Historie hinzu, als Windows Internationalisierung unterstützen musste im NT Kernel gab es noch kein UTF-8 und der Unicode Space war auch noch nicht voll Durchspezifiziert, aber Microsoft konnte nicht warten weil ihnen Internationale Kunden aufs Dach gestiegen sind, und daher haben sie das genommen was da war, eine nicht fertige Version von UTF-16.

Habe ich mir fast gedacht, das dies so ein Microschrott Müll ist. Alles ist ein Gebastel in ihrem OS.

[af0815]

Habe ich mir fast gedacht, das dies so ein Microschrott Müll ist. Alles ist ein Gebastel in ihrem OS.

Würde ich so nicht unterschreiben, das war beim fpc/Lazarus auch nicht alles so easy und Strings in FPC/Lazarus sind immer noch etwas mit Bauchweh.

Das erste NT ist so um 1992 herausgekommen und zu diesem Zeitpunkt hat sich auch utf-8 gebildet. Noch dazu sind die ersten Windows Versionen mehr oder minder DOS gefolgt und das hatte ASCII Kodierungen bzw. über Zeichenpages die Sprachumschaltung gemacht. War aber auch bei Novell so, das ja vor Windows so richtig als Netzwerksystem gearbeitet hat (Ich habe noch Admin Schulungen für Novell gehabt, 1980-2014). Und dort war von utf-8 und Konsorten auch weit und breit nichts zu sehen.

Unix und die Linuxoiden haben sich rasch auf utf-8 draufgesetzt, das es in der einfachsten Form auch ASCII entsprochen hat (mit eingeschränkten Zeichensatz, am Teletype auch kein Problem).

Müll ist was nur dann, wenn es nicht funktioniert und trotzdem Geld gekostet hat. Das kann man Windows nicht vorwerfen (Ausser bei vielleicht bei ein paar Versionsnummern ).

[Warf]

UTF-8 war von anfang an für Netzwerkdaten, insbesondere für dieses neue Ding namens Internet gedacht. Zeichen die viel benutzt werden haben dabei kurze Representationen, Zeichen die wenig benutzt werden lange. Kompression ist in das Encoding direkt eingebaut. Der Overhead beim Parsen ist eigentlich kein Problem da die Netzwerk streams ja eh langsamer als die CPU sind, man kann die Daten also beim laden direkt dekodieren.
Die Idee damals Festlängen Chars für lokale representation wo die Verarbeitung passieren muss und Dynamische Längen dann über das Netzwerk.
Microsoft und Sun sind diesen Weg damals gegangen, Microsoft sogar etwas zu früh als das Unicode Konsortium noch nicht fertig war, weshalb es ein paar Inkompatibilitäten gab.

Hingegen ist einfach sehr lange zeit sich auf 8 bit chars mit Codepages geblieben und hatte daher da noch kein Pferd im rennen. Dann ist das Web absolut explodiert, und damit ist UTF-8 überall gewesen, gleichzeitig ist man durch dinge wie Emojis sehr schnell an die Grenzen der 16 Bit chars gekommen, wo man vorher dachte das die 65k Zeichen für die meisten Use-Cases voll ausreichen würden, mit dem Ergebnis das man mit UTF16+Unicode Planes im Grunde wieder die selbe Problematik hatte wie mit CodePages, weshalb die meisten Systeme einfach direkt auf UTF-8 gegangen sind.
Als Linux dann nachgezogen ist war schon klar das UTF-8 "gewonnen" hat und Windows und Java mit UTF-16 auf das falsche Pferd gesetzt haben. Das Problem ist, der NT Kernel arbeitet nunmal intern mit UTF-16, das wird sich auch so schnell nicht ändern lassen. .Net wurde auf basis von UTF-16 gebaut. Bei Java hats auch bis 2022 gedauert bis sie auf UTF-8 umgestiegen sind.

Übrigens was ich recht interessant finde ist der Ansatz von Rust, Rust hat auf Sprachlevel unicode support, Chars sind 32 bit lang und Strings sind utf-8, wobei die Sprache dann transparent zwischen den beiden konvertiert, sodass man zur verarbeitung mit den 32 bit Codepoints arbeiten kann ohne sich über die Char Representation im String Gedanken machen zu müssen

[Mathias]

Müll ist was nur dann, wenn es nicht funktioniert und trotzdem Geld gekostet hat. Das kann man Windows nicht vorwerfen (Ausser bei vielleicht bei ein paar Versionsnummern ).

Für mich ist Windows gestorben, das kommt nicht mehr auf meinen PC.

Übrigens was ich recht interessant finde ist der Ansatz von Rust, Rust hat auf Sprachlevel unicode support, Chars sind 32 bit lang und Strings sind utf-8, wobei die Sprache dann transparent zwischen den beiden konvertiert, sodass man zur verarbeitung mit den 32 bit Codepoints arbeiten kann ohne sich über die Char Representation im String Gedanken machen zu müssen

Diese 32Bit Chars sind was recht spezielles. An denen kann man sich recht die Zähne ausbeissen.

[PascalDragon]

Man könnte es wenigstens mit eine Compilerschalter machen.
Bei den ShortString hatten sie es mit {$H+} gemacht.
Dann würde der alte Code kompatibel bleiben, wen mal etwas am Char geändert wird.

Das ist das was ursprünglich mit $ModeSwitch UnicodeStrings gedacht war, aber so funktioniert es einfach nicht, da für korrekte Funktion und Kompatibilität die komplette RTL mit String = UnicodeString arbeiten muss.

Die Entscheidung auf 16 bit chars zu gehen könnte ich ja irgendwo noch verstehen aus Delphi Kompatibilität. Aber so ein misch-masch aus 8 und 16 bit Chars das hilft doch absolut niemandem. Und wenn das Ziel kompatibilitätsmaximierung ist dann wäre UTF-32 mit 4 byte Chars der richtige Weg

UTF-32 ist eine riesen Verschwendung von Speicher, besonders auf kleineren Plattformen, die FPC nunmal auch unterstützt. Deswegen auch die Entscheidung, das je nach Plattform zu unterscheiden, da dann Plattformen wie MS-DOS oder Win16 weiterhin String = AnsiString nutzt, während zum Beispiel für Win32 und Win64 String = UnicodeString genutzt wird, was einerseits die Kompatibilität zu aktuellem Delphi-Code erhöht und andererseits Konvertierungen innerhalb der Windows API umgeht, da Windows nunmal UTF-16 nutzt.

Was nützt eigentlich ein 16bit Char. Mit utf8 ist doch das Problem gelöst, das man fast unendlich viele Zeichen darstellen kann.
Und wen doch einmal einer auf die Idee kommt und eine 16bit Char will, gibt es ja WideChar.
Es reicht ja schon, das es beim Integer keine Garantie gibt, das er 32bit hat.

Bei UTF-8 hast du Zeichen, die zwischen 1 und 4 Byte lang sind. Das heißt du kannst nicht ohne Durchgehen des Strings den Index eines Zeichens ermitteln. Bei UTF-16 ist die Basisgröße 2 Byte und auch wenn es Surrogate Zeichen gibt, die aus 2 2 Byte Zeichen bestehen, ist die Indizierung dennoch einfacher als bei UTF-8.

Bei Windows kommt noch Historie hinzu, als Windows Internationalisierung unterstützen musste im NT Kernel gab es noch kein UTF-8 und der Unicode Space war auch noch nicht voll Durchspezifiziert, aber Microsoft konnte nicht warten weil ihnen Internationale Kunden aufs Dach gestiegen sind, und daher haben sie das genommen was da war, eine nicht fertige Version von UTF-16.

Habe ich mir fast gedacht, das dies so ein Microschrott Müll ist. Alles ist ein Gebastel in ihrem OS.

Dann lass doch mal hören, wie du Internationalität umgesetzt hättest, wenn es noch keinen finalisierten Standard für UTF-8 oder UTF-16 gibt, du aber abliefern musst?