Die meisten Programmiersprachen haben einige Unterstützung für Unicode, aber alle haben mehr oder weniger dokumentierte Fälle, wo Dinge nicht richtig funktionieren.
Beispiele
Java: reverse () in StringBuilder / StringBuffer funktioniert ordnungsgemäß. Aber length (), charAt () usw. in String nicht, wenn ein Zeichen mehr als 16bit zum Codieren benötigt.
C #: Es wurde keine korrekte umgekehrte Methode gefunden. Die Länge und der indizierte Zugriff geben falsche Ergebnisse zurück.
Perl: Gleiches Problem.
PHP: Hat überhaupt keine Idee von Unicode, mbstring hat einige bessere funktionierende Ersetzungen.
Ich frage mich, ob es eine Programmiersprache gibt, die vollständige und korrekte Unicode-Unterstützung hat? Welche Kompromisse mussten dort gemacht werden, um so etwas zu erreichen?
Wie wurde es intern implementiert?
Ich habe gesehen, dass Python 3 in diesem Bereich ziemlich große Veränderungen erfahren hat. Wie nah ist Python 3 nun an eine korrekte Implementierung?
Es sieht so aus, als ob Perl 6 eine gute Unicode-Unterstützung bekommt:
perlgeek.de//article/5-to-6#post_17
Zum Beispiel bietet es Ihnen drei verschiedene Längenmethoden:
Dies wird auch in die regulären Ausdrücke von Perl integriert.
Sieht für mich wie ein Schritt in die richtige Richtung aus.
Die Java-Implementierung ist korrekt in dem Sinne, dass sie den Unicode-Standard nicht verletzt; Es gibt keine Vorschrift, dass die String-Indizierung an Codepunkten statt an Codeeinheiten arbeitet und das Verhalten dokumentiert ist. Der Unicode-Standard gibt den Implementierern große Freiheit in Bezug auf Optimierungen, solange kein ungültiger String verloren geht. In Bezug auf "volle Unterstützung" ist das noch schwieriger zu definieren. Der Unicode-Standard erfordert im Allgemeinen nicht, dass bestimmte Funktionen implementiert werden, um Unicode-kompatibel zu sein; nur dass die implementierten Features dem Standard entsprechen. Große Teile der Skriptverarbeitung gehören zu den Schriften oder dem Betriebssystem, die von Programmiersystemen nicht gesteuert werden können. Wenn Sie über die Unicode-Unterstützung bestimmter Technologien entscheiden möchten, können Sie mit dem Testen der folgenden (subjektiven und nicht erschöpfenden) Themenliste beginnen:
UpperCase("ß") = "SS" ? UpperCase("i") = "İ" ) Ich denke, dass die Antwort von Java und .NET auf diese Fragen meistens "Ja" ist, während die Antwort von Python 3.x fast immer "Nein" ist.
In Python 3 sind Strings immer Unicode (es gibt bytes für ASCII oder ähnliche Codierungen). Ich bin mir nicht bewusst, dass die eingebauten Komponenten nicht korrekt funktionieren. Es mag einige geben, aber wenn man bedenkt, dass es schon eine ganze Weile draußen ist, denke ich, dass sie über alles verfügen, was täglich benötigt wird.
Natürlich hat Unicode einen höheren Speicherverbrauch (UTF-8 nicht wirklich, wenn Sie im ASCII-Bereich bleiben, aber sonst ...) und ich kann mir vorstellen, dass Mehrfachlängencodierungen intern mühsam zu handhaben sind. Ich weiß jedoch nichts über die Implementierung. Außer dass es keine verknüpfte Liste sein kann, da es O (1) wahlfreien Zugriff hat.
Das .NET Framework speichert char und string Daten mit der UTF-16-Codierung. Wenn Sie annehmen, dass Ihr gesamter Text innerhalb der Basic Multilingual Plane liegt, funktioniert alles ohne speziellen Code.
Wenn Sie von Benutzern eingegebene Strings als Blobs betrachten und nicht versuchen, sie zu manipulieren (z. B. die meisten Textfelder in CRUD-Apps), wird Ihr Code angezeigt , um Zeichen außerhalb des BMP richtig zu behandeln. Weil UTF-16 sie als Ersatzpaare speichert. Solange Sie nicht mit den Ersatzpaaren herumspielen, ist alles in Ordnung.
Wenn Sie jedoch Zeichenfolgen analysieren und bearbeiten und dabei auch Zeichen außerhalb des BMP korrekt behandeln möchten, müssen Sie diese Möglichkeit explizit angeben. Informationen zur Verwendung von Ersatzpaaren finden Sie in der StringInfo -Klasse.
Ich vermute, dass Microsoft es so entworfen hat, um ein Gleichgewicht zwischen Leistung und Korrektheit zu erreichen. Die Alternativen wären:
.NET bietet außerdem vollständige Unterstützung für die Konvertierung, Vergleiche und Sortierung kulturspezifischer Fälle.
DigitalMars D hat den Datentyp dstring, der UTF32-Codepunkte verwendet, sollte für die meisten Fälle ausreichen.
Tags und Links string language-agnostic programming-languages unicode encoding