programmiert noch jemand ohne UTF-8?

[Ethon]

wcout ist gerade UTF-16 (unter Windows) bzw UTF-32 (Rest der Welt).
Na gut, verbessere ich mich mal: wcout ist für breitere Zeichendarstellungen aber genannte Kodierungen werden in der Regel dafür verwendet.

Nachdem aber utf8 wie von dir angemerkt die üblichste Kodierung ist sollte man auch cout nehmen und das Ausgabemedium, also die Konsole, auch darauf konfigurieren utf8 und kein ascii zu erwarten.

[UTF-Acht]

Dann kann ich also UTF-8 ganz normal mit std::string und std::cout nutzen? Würde ja auch Sinn machen, denn in anderen Sprachen macht man sich ja um UTF-8 auch keinen Kopf und nutzt die ganz normalen Standardfunktionen.

[Ethon]

Ja. Du musst sogar. Allerdings sind die Funktionen wie strlen, std::string::size alle nicht utf8 aware. Hierfür müsstest du eine Lib verwenden, zb. http://utfcpp.sourceforge.net/

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