Ich weiß, ich wollte Klugscheißern vermeidenkeppla hat geschrieben:In mindestens 2 bytes. utf-8 kann pro zeichen bis zu 4 bytes nutzen, afaik (http://de.wikipedia.org/wiki/Utf-8)
Welches Encoding ist für Deutschland am sinnvollsten?
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
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 VerwendungLeonidas hat geschrieben:Wenn du alle Zeichen problemlos in eine Datei speichern kannst ist es durchaus ein Vorteil. Verstehe nicht, wo du da ein Problem sehen würdestHyperion 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?
Ich gebe zu, dass ich mich da nicht auskenne - daher meine Frage!
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*
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*
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
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
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
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.jens hat geschrieben: Langsam ist relativ. Weiß jemand wie groß die Unterschiede sind?
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.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.
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.
Ich frage mich gerade wie ein Text langsam sein kann. Oder schnell.
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.
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.
-
- User
- Beiträge: 1790
- Registriert: Donnerstag 28. Oktober 2004, 16:33
- Wohnort: Graz, Steiermark - Österreich
- Kontaktdaten:
Intern nutzt Python UCS2 oder UCS4jens 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.
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.btw. die gewonnenen Erkenntnisse würde sich gut im Wiki machen
TUFKAB – the user formerly known as blackbird