programmiert noch jemand ohne UTF-8?
-
Mit UTF-8 Funktionalität meine ich schon alles was man sonst mit Strings so anstellen kann, in einer Programmiersprache. Also da fallen mir Sachen ein wie Suche, Index, Länge, Konkatenation usw. Schließlich ist heute fast jede Textdatei eine UTF-8 Datei, also braucht man solche Funktionalität doch ständig. Das man nur ASCII hat, ist doch eher der Ausnahmefall.
Da gibt es keine Sprachen die per Default UTF-8 in ihren String-Funktionalitäten haben?
-
UTF-8 schrieb:
Mit UTF-8 Funktionalität meine ich schon alles was man sonst mit Strings so anstellen kann, in einer Programmiersprache. Also da fallen mir Sachen ein wie Suche, Index, Länge, Konkatenation usw. Schließlich ist heute fast jede Textdatei eine UTF-8 Datei, also braucht man solche Funktionalität doch ständig. Das man nur ASCII hat, ist doch eher der Ausnahmefall.
Da gibt es keine Sprachen die per Default UTF-8 in ihren String-Funktionalitäten haben?
Fürs dateilesen, muss es die Programmiersprache doch nicht können, wie Ethon schon gesagt hat. Es recht wenn man einen encodierer zum auslesen angibt und dann intern kann man ja arbeiten wie einem beliebt. Beim rausschrieben ist es dann wieder wichtig, das man die Daten wieder zurück kodiert.
Hab nochmal nachgeschaut ich C# speichert intern alles als UTF-16 und wandelt via Encodijng alles in UTF-8 wenn angegeben.
Mfg Marco
-
UTF-8 schrieb:
Da gibt es keine Sprachen die per Default UTF-8 in ihren String-Funktionalitäten haben?
Wurde zwar schon gesagt, aber da du es anscheinend immer noch nicht verstanden hast: ob UTF-8 oder UTF-16 spielt dabei keine Rolle. Was du meinst ist ein ordentlicher Unicode-Support -- welches Encoding dabei verwendet wird ist ja wohl mehr oder weniger egal.
UTF-8 schrieb:
Suche, Index, Länge, Konkatenation usw.
Suche und Konkatenation geht IMMER, dazu braucht es keinen speziellen Support.
Was du mit Index meinst verstehe ich nicht.
Bleibt also einzig noch das Ermitteln der Länge.Nochwas...
Ich denke du stellst dir die ganze Unicode-Sache auch etwas zu einfach vor. Also was das Thema Suche bzw. allgemein Vergleiche angeht... lies mal das da: http://en.wikipedia.org/wiki/Unicode_equivalence
-
UTF-Achter schrieb:
Ich dachte immer wcout usw ist Unicode, also auch UTF-8. UTF-16 macht doch keinen Sinn, das nutzt doch keiner. Wenn Unicode, dann wird doch zu 99% UTF-8 in den anderen Sprachen verwendet. Ist UTF-16 nicht die totale Platzverschwendung, im Gegensatz zu UTF-8.
Du solltest Dich mal über die Grundlagen von Unicode und UTF-8 informieren. Das klingt so, dass Du das nicht ausreichend verstanden hast.
Nur mal kurz: Unicode ist nicht UTF-8. Und Verarbeitung mit UTF-8 ist gar nicht trivial, wie hier bei der Diskussion bereits mehrfach erwähnt.
Unicode-aware Programme sollten Daten in Unicode halten und nur bei der Ein- und Ausgabe von bzw. nach UTF-8 konvertieren. Ein
std::basic_string<char32_t>wie vorgeschlagen ist hier ein wunderbarer Lösungsansatz.
-
UTF-Acht schrieb:
Welche Sprachen unterstützen denn UTF8 sowohl im Source als auch bei den Standard-String-Funktionalitäten?
D Programming Landuage kann das.
http://dlang.org/phobos/std_utf.html
http://dlang.org/library/std/utf.html
http://dlang.org/type.html
http://wiki.dlang.org/Using_UTF_on_WindowsD Strings sind in UTF-8.
UTF-16 nimmt man übrigens deswegen, weil es performanter ist.
Was auch logisch ist, wenn man beachtet, dass UTF-8 eine Lauflängenkodierung hat und es Performance kostet, wenn man die Sonderfälle bezüglich Zeichen mit mehr als 1 Byte Größe berücksichtigen muss.Wenn man UTF-16 oder UTF-32 verwendet, dann gibt es im Prinzip diese Sonderfälle nicht und somit auch keine Sonderbehandlung, da alles 2 byte bzw. 4 Byte groß ist.
Das sorgt für einen Geschwindigkeitsboost, wenn man überwiegend mit Zeichen arbeitet, die nicht mehr in den 8 Byte Raum von UTF-8 passen.UTF-8 ist sinnvoll, wenn man überwiegend Zeichen hat, die auch im ASCII Code vorkommen oder wenn man Textdateien speichern möchte. UTF-8 spart immerhin Speicherplatz.
In allen anderen Fällen, insbesondere zur Laufzeit ist UTF-16 oder UTF-32 aber schneller und einfacher und genau deswegen gibt es UTF-16 und UTF-32 überhaupt.
Und das unter Windows oder in Java UTF-16 verwendet wird und nicht UTF-32 ist so historisch gewachsen, denn damals, als man sich für UTF-16 entschieden hat, passten die bekannten Unicode Zeichen noch alle in UTF-16.
-
Ah, ich verstehe. Dann muss man also in allen Sprachen UTF-8 in einem Format umwandeln mit konstanten Länge für jeden Char und bei der Ausgabe, z.b. in eine Datei, wandelt man dann zurück in UTF-8.
-
UTF-8 schrieb:
Ah, ich verstehe. Dann muss man also in allen Sprachen UTF-8 in einem Format umwandeln mit konstanten Länge für jeden Char und bei der Ausgabe, z.b. in eine Datei, wandelt man dann zurück in UTF-8.
Exakt. Genau so würde ich das machen.
-
Es gibt kein Unicode Encoding, in dem das, was man gemeinhin als "Zeichen" bezeichnen würde (nämlich ein Graphem) konstante Länge hat...
Auskenner schrieb:
Und das unter Windows oder in Java UTF-16 verwendet wird und nicht UTF-32 ist so historisch gewachsen, denn damals, als man sich für UTF-16 entschieden hat, passten die bekannten Unicode Zeichen noch alle in UTF-16.
Insbesondere gab es UTF-8 damals noch gar nicht...
-
Rust scheint per Standard UTF-8 zu machen, oder? http://doc.rust-lang.org/book/strings.html
-
Auskenner schrieb:
Wenn man UTF-16 oder UTF-32 verwendet, dann gibt es im Prinzip diese Sonderfälle nicht und somit auch keine Sonderbehandlung, da alles 2 byte bzw. 4 Byte groß ist.
(...)
Und das unter Windows oder in Java UTF-16 verwendet wird und nicht UTF-32 ist so historisch gewachsen, denn damals, als man sich für UTF-16 entschieden hat, passten die bekannten Unicode Zeichen noch alle in UTF-16.
Du widersprichst dir da ja schon selbst.
Also lass es mich auch nochmal tun: NEIN, bei UTF-16 ist NICHT alles gleich lange.
Ob UTF-8 oder UTF-16 ist diesbezüglich völlig wurscht.
Es sei denn man scheisst auf alles ausserhalb der BMP. Bloss dann arbeitet man nicht mehr mit UTF-16, sondern mit UCS-2.
-
Insbesondere muss wohl nochmals erwähnt werden, dass selbst in UTF-32 ein Unicode Zeichen nicht einem Code Unit entspricht. Der einzige Unterschied zwischen UTF-32 und dem Rest ist, dass ein UTF-32 Code Unit im Moment direkt einem Unicode Code Point entspricht. Ein "Zeichen" kann aber immer noch aus mehreren Code Points bestehen wobei ein und das selbe "Zeichen" sogar mehr als eine mögliche Darstellung als Sequenz von Code Points haben kann. Dass UTF-32 irgendwie direkten Zugriff auf "Zeichen" bietet, ist ein leider sehr weit verbreiteter Irrglaube, der selbst bei einem einfachen ä schon nichtmehr funktioniert; nichtmal ein simpler Stringvergleich funktioniert ohne vorherige Normalisierung, ganz egal of UTF-8, UTF-16 oder UTF-32...
-
hustbaer schrieb:
Es sei denn man scheisst auf alles ausserhalb der BMP. Bloss dann arbeitet man nicht mehr mit UTF-16, sondern mit UCS-2.
Was imho auch der Standard bei Windows ist...
-
asc schrieb:
hustbaer schrieb:
Es sei denn man scheisst auf alles ausserhalb der BMP. Bloss dann arbeitet man nicht mehr mit UTF-16, sondern mit UCS-2.
Was imho auch der Standard bei Windows ist...
War so bis exklusive Windows 2000, ab Version 5.x aufwärts ist der Windows NT Kernel afaik voll UTF-16.
-
dot schrieb:
...
Hatte ich auch so in Erinnerung, konnte nur grad keine Quelle finden.
-
Der Mann mit der beigen Homepage hat das IIRC mal geschrieben. Fällt mir grad net ein wie die Seite heisst...
-
hustbaer schrieb:
Auskenner schrieb:
Wenn man UTF-16 oder UTF-32 verwendet, dann gibt es im Prinzip diese Sonderfälle nicht und somit auch keine Sonderbehandlung, da alles 2 byte bzw. 4 Byte groß ist.
(...)
Und das unter Windows oder in Java UTF-16 verwendet wird und nicht UTF-32 ist so historisch gewachsen, denn damals, als man sich für UTF-16 entschieden hat, passten die bekannten Unicode Zeichen noch alle in UTF-16.
Du widersprichst dir da ja schon selbst.
Also lass es mich auch nochmal tun: NEIN, bei UTF-16 ist NICHT alles gleich lange.
Ob UTF-8 oder UTF-16 ist diesbezüglich völlig wurscht.
Es sei denn man scheisst auf alles ausserhalb der BMP. Bloss dann arbeitet man nicht mehr mit UTF-16, sondern mit UCS-2.Ja, okay. UCS-2 habe ich eigentlich gemeint.
-
@Auskenner
Dann musst du besser aufpassen was du schreibst
hustbaer schrieb:
Der Mann mit der beigen Homepage hat das IIRC mal geschrieben. Fällt mir grad net ein wie die Seite heisst...
OK, die Seite an die ich dachte heisst "The Old New Thing". Kann den Beitrag aber nicht finden. Vielleicht bilde ich mir auch nur ein dass ich das dort gelesen habe... *hm*
-
Ich find' utf8 ja scheiße, weil es die Umwelt belastet
-
Rustiger schrieb:
Rust scheint per Standard UTF-8 zu machen, oder? http://doc.rust-lang.org/book/strings.html
Ja, aber auch mit allen Nachteilen, wie O(n) indexzugriff, kein ersetzen von zeichen innerhalb des Strings. Wenn man das braucht und Ascii reicht, sollte man Vec<u8> nehmen.
-
Zu ASCII gibt es auch jeden Menge: http://doc.rust-lang.org/std/?search=ascii
Aber ist doch toll, wenn man einfach so als Standard UTF-8 hat, das ist doch nun einmal der Standard in der heutigen Zeit. Ob das nun intern doch auf mehr Bytes erweitert wird, um eben nicht O(n) zu haben, interessiert mich jetzt als Programmierer recht wenig. Ich bin sicher, die haben das schon irgendwie gelöst, entweder über einen anderen Typ oder sonst wie.
