programmiert noch jemand ohne UTF-8?

[UTF-Acht]

Wie was Zusatzlibs für einfaches UTF-8? Sind wir in den 90er???? Ich dachte es gäbe neues C++ ISO Standards, da sollte doch mindestens mal UTF-8 mit bei gewesen sein!

[hustbaer]

UTF-Achter schrieb:

Ich dachte immer wcout usw ist Unicode, also auch UTF-8.

wcout ist für wchar_t . Was auch immer wchar_t ist - das ist nämlich dummerweise nicht definiert.

UTF-Achter schrieb:

UTF-16 macht doch keinen Sinn, das nutzt doch keiner.

Ochja bloss der gesamte Windows-Kernel, die Windows Usermode DLLs, NTFS, MS SQL-Server und zumindest tausende (vermutlich eher Millionen) Windows Anwendungen.

UTF-Achter schrieb:

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.

Ja, UTF-8 wird viel verwendet. Wenn du UTF-8 unter Windows verwenden willst, dann musst du aber jedes mal wenn du ne Windows-Funktion aufrufst erstmal nach UTF-16 konvertieren.
Also arbeiten viele Windows-Anwendungen gleich mit UTF-16. Weil's im Endeffekt für die allermeisten Anwendungen Schnuppe ist - weil die keine so grossen Textmengen im RAM halten dass es ne Rolle spielen würde.
Überall mit UTF-8 zu arbeiten hat natürlich auch Vorteile - speziell wenn man portierbaren Code schreiben möchte. Ist unter Windows aber wie gesagt super mühsam. Weil man da eben nicht UTF-8 mit den 8-Bit-Char Funktionen verwenden kann.

[Marthog]

UTF-Acht schrieb:

Wie was Zusatzlibs für einfaches UTF-8? Sind wir in den 90er???? Ich dachte es gäbe neues C++ ISO Standards, da sollte doch mindestens mal UTF-8 mit bei gewesen sein!

UTF8 hat aber eine ganz andere vorgehensweise, weil die einzelnen Zeichen variable Groessen haben. Dadurch geht das herauspicken von einzelnen Zeichen nur in O(n) und das ersetzen von Zeichen aus der Mitte eines Strings gar nicht ohne weiteres.
std::string ist fuer das Bearbeiten von bytestrings spezialisiert, aber utf-8 braucht halt noch ein bisschen mehr und das geht nachtraeglich und fehlerrei nur ziemlich schwer.

[UTF-Acht]

Also kann C++ gar kein UTF-8 out of the box, so wie Java etc.?

[Ethon]

Java verwendet gar kein utf8. Da muss immer konvertiert werden.
Kann man in C++ auch machen, immer nach utf32 konvertieren und std::basic_string<char32_t> funktioniert super.

[UTF-Acht]

Welche Sprachen unterstützen denn UTF8 sowohl im Source als auch bei den Standard-String-Funktionalitäten?

[hustbaer]

Ethon schrieb:

Java verwendet gar kein utf8. Da muss immer konvertiert werden.

Hihi, ja, hab ich ganz vergessen.
Java verwendet nämlich auch UTF-16. Wie Windows. Na sowas

[hustbaer]

UTF-Acht schrieb:

Welche Sprachen unterstützen denn UTF8 sowohl im Source als auch bei den Standard-String-Funktionalitäten?

Das kommt vermutlich drauf an was du mit "unterstützen" meinst.
Find/replace geht z.B. überall wo es 8 bittige String Typen gibt. Also auch in C, C++ etc. Dafür sorgt das ganz bewusst gewählte "Design" von UTF-8.

Das Durchgehen eines Strings "Codepoint für Codepoint" ist dann wieder ne ganz andere Sache.
Weiss nicht ob es überhaupt Sprachen gibt wo das in der Standard-Library implementiert ist.
Weil man das halt auch nicht SO oft braucht.
Bzw. wenn man es braucht, dann gibt es ja andere Möglichkeiten (Konvertierung nach UTF-32, Verwendung von Libs ala ICU, ...).

[Nathan]

hustbaer schrieb:

Ethon schrieb:

Java verwendet gar kein utf8. Da muss immer konvertiert werden.

Hihi, ja, hab ich ganz vergessen.
Java verwendet nämlich auch UTF-16. Wie Windows. Na sowas

Witzige Detail an der Sache: Intern speichert die JVM ihre Strings in nämlich in UTF-8. Nur der arme Programmierer braucht UTF-16.

[Ethon]

Eigentlich muss der Programmierer garnichts davon wissen da er ziemlich abstrahiert von der Sache ist. Halt hin und wieder das Encoding angeben wenn man etwas anderes als ascii liest oder schreibt und gut.

[SG1]

Nathan schrieb:

Witzige Detail an der Sache: Intern speichert die JVM ihre Strings in nämlich in UTF-8. Nur der arme Programmierer braucht UTF-16.

Was meinst Du damit genau? In allen mir bekannten JDKs arbeitet die String-Klasse intern mit einem Array aus chars (char ist in Java ein 16-Bit Typ).

[Nathan]

SG1 schrieb:

Nathan schrieb:

Witzige Detail an der Sache: Intern speichert die JVM ihre Strings in nämlich in UTF-8. Nur der arme Programmierer braucht UTF-16.

Was meinst Du damit genau? In allen mir bekannten JDKs arbeitet die String-Klasse intern mit einem Array aus chars (char ist in Java ein 16-Bit Typ).

Die Java Virtuelle Machine speichert in Class Files in UTF-8: http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4.7

[hustbaer]

Jo Class-Files vielleicht. Aber für Strings wäre es wohl etwas krass. Dadurch würden charAt, codePointAt etc. ja O(N) - was vermutlich viele Programme arg bremsen würde.

Ethon schrieb:

Eigentlich muss der Programmierer garnichts davon wissen da er ziemlich abstrahiert von der Sache ist. Halt hin und wieder das Encoding angeben wenn man etwas anderes als ascii liest oder schreibt und gut.

Ja, wenn man brav die codePointXxx Funktionen verwendet, dann muss einen das nicht interessieren. Ausser halt dass man darauf achten muss auch schön i = str.offsetByCodePoints(i, 1) statt i++ zu verwenden. Aber das wäre natürlich genau so der Fall wenn String intern mit UTF-8 bzw. generell irgendwas was nicht UCS-4 ist arbeiten würde.

ps: Gibt es in Java eigentlich auch nen CodePointInterator? Also damit das Ermitteln der Länge eines Codepoints nicht immer doppelt gemacht werden muss (1x in codePointAt und dann gleich nochmal im darauffolgenden offsetByCodePoints ).

[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?

[Marc-O]

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

[hustbaer]

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

[tntnet]

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.

[Auskenner]

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_Windows

D 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.

[UTF-8]

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.

[Auskenner]

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.