Seite 2 von 2

Verfasst: Mittwoch 5. März 2008, 14:46
von burli
keppla hat geschrieben:In mindestens 2 bytes. utf-8 kann pro zeichen bis zu 4 bytes nutzen, afaik (http://de.wikipedia.org/wiki/Utf-8)
Ich weiß, ich wollte Klugscheißern vermeiden :wink:

Verfasst: Mittwoch 5. März 2008, 14:56
von Hyperion
Leonidas hat geschrieben:
Hyperion hat geschrieben:Wie sieht es eigentlich mit Internationalisierung aus? Ok, die Sprach-Daten werden ja sicherlich außerhalb des eigentlichen Codes gespeichert, aber ist da UTF-8 auch von Vorteil, oder wäre das deswegen eher kein Pluspunkt für utf-8?
Wenn du alle Zeichen problemlos in eine Datei speichern kannst ist es durchaus ein Vorteil. Verstehe nicht, wo du da ein Problem sehen würdest :?:
Ich wollte da kein Problem sehen, sondern nur abklopfen, ob es in Hinblick auf eine Internationalisierung eben auch sinnvoll ist, sofort auf utf-8 zu setzen! Quasi als weiteres Argument für die Verwendung ;-)

Ich gebe zu, dass ich mich da nicht auskenne - daher meine Frage!

Verfasst: Mittwoch 5. März 2008, 15:04
von burli
Ich denke es wurde alles wichtige aufgezählt. UTF-8 hat, wenn überhaupt, zwei winzige Nachteile.

1. UTF-8 kann bei üblichen westeuropäischen Texten minimal größer sein (was bei den heutigen Speicherkapazitäten und Rechenleistungen aber nicht auffallen wird)

2. reine ASCII Editoren können UTF-8 nicht vollständig darstellen, aber das wichtigste können sie editieren und es gibt doch eigentlich keine Editoren mehr die UTF-8 nicht können

Ich sehe also keinen Grund UTF-8 nicht zu verwenden. Ich für meinen Teil ärgere mich immer über das Kauderwelsch in den IRC Chats. Der eine meint er müsse unbedingt UTF-8 nehmen, der andere verwendet einen Client der noch mit latin1 um sich wirft *grr*

Verfasst: Mittwoch 5. März 2008, 15:08
von jens
Da wir schon mal beim Thema sind. Eigentlich spricht ja alles für UTF-8. Allerdings soll das wohl wegen der variablen Länge langsamer als UTF-32, welches ja für alle Zeichen 4 Bytes verbraucht.

Langsam ist relativ. Weiß jemand wie groß die Unterschiede sind?
Ich gehe mal davon aus, das es auch davon abhängig ist, wie viele Zeichen >127 sind, oder?
Gibt es Empfehlungen wann es Sinn macht UTF-32 zu nutzten?

btw. die gewonnenen Erkenntnisse würde sich gut im Wiki machen ;)

Verfasst: Mittwoch 5. März 2008, 15:13
von burli
jens hat geschrieben: Langsam ist relativ. Weiß jemand wie groß die Unterschiede sind?
Das kann kein merklicher Unterschied sein. Es muss ja nur abgefragt werden ob das jeweils höchstwertige Bit gesetzt ist um festzustellen um wieviele Bytes es sich handelt.

Verfasst: Mittwoch 5. März 2008, 15:21
von keppla
jens hat geschrieben:Da wir schon mal beim Thema sind. Eigentlich spricht ja alles für UTF-8. Allerdings soll das wohl wegen der variablen Länge langsamer als UTF-32, welches ja für alle Zeichen 4 Bytes verbraucht.

Langsam ist relativ.
definitv. Die Frage ist hier auch "langsam wobei"? Bei der Übermittlug über netze dürfte utf8 mit "höchstens genausoviel wie 32" wohl nahezu immer schneller sein. Bei Zugriff auf Zeichen x dürften die meisten algorithmen bei 32 schneller als bei 8 sein.
Im Speicher des Pythonprogramms sind Strings eh so dargestellt, wie die python-vm das gerade möchte.
Im Endeffekt ist das ganze Premature Optimisation (and, therefore the root of all evil, um mal zu Zitieren).
Wir verwenden in python Arrays mit dynamischen Größen, Dictionaries, Garbage Collection, "Late Binding", kurz, nahezu all das, wo man für etwas performance extrem viel Bequemlichkeit bekommt. Ich glaube nicht, dass wir bei encodings auf einmal anfangen sollten, wie irgendwelche c-kiddies "Performance, Performance" zu schreien.

Verfasst: Mittwoch 5. März 2008, 18:24
von BlackJack
Ich frage mich gerade wie ein Text langsam sein kann. Oder schnell. :roll:

Es geht ja auch nur um die externe Kodierung. Wie die Laufzeitbibliotheken von Programmiersprachen dass dann intern darstellen, darauf hat man in der Regel doch sowieso keinen grossen Einfluss.

Und für Die *interne* Darstellung gibt's wohl noch ganz andere Datenstrukturen als die üblichen, relativ einfachen UTF-Kodierungen. Zum Beispiel für effiziente Verarbeitung von Texten in denen beide Schreibrichtungen vorkommen, oder Sprachen wo regelmässig Zeichen aus verschiedenen Symbolen zusammengesetzt werden, die es nicht "pre-composed" im Unicode-Zeichensatz gibt.

@keppla: Um die Frage ASCII oder Unicode ging es hoffentlich nicht, denn ASCII halte ich für Deutschland als recht ungeeignete Kodierung.

Verfasst: Donnerstag 6. März 2008, 11:23
von mitsuhiko
jens hat geschrieben:Da wir schon mal beim Thema sind. Eigentlich spricht ja alles für UTF-8. Allerdings soll das wohl wegen der variablen Länge langsamer als UTF-32, welches ja für alle Zeichen 4 Bytes verbraucht.
Intern nutzt Python UCS2 oder UCS4
btw. die gewonnenen Erkenntnisse würde sich gut im Wiki machen ;)
Sinnlos weil diese Erkentnisse sind nicht über das "nutz unicode" hinausgekommen und das kann man sich auch ergooglen. Es gibt genug Seiten die über Unicode reden, das braucht unser Wiki nicht auch noch, wo es eh schon einen guten Eintrag über Encodings gibt.