Seite 1 von 2
Welches Encoding ist für Deutschland am sinnvollsten?
Verfasst: Dienstag 4. März 2008, 17:50
von Pythonierer
Hallo, ich hätte mal wieder eine Frage, welche jedoch nicht von allzu großer Dringlichkeit ist.
Welches Encoding ist für mich als Windows User aus Deutschland am geeignetsten? Am liebsten würde ich so viele Sonderzeichen wie möglich verwenden können, also auch € usw. Bisher verwende ich entweder 'latin-1' oder 'iso-8859', allerdings hat auch 'utf-8' mein Interesse geweckt.
Danke schonmal für euer Interesse und bis zum nächsten Posting,
Pythonierer!
Verfasst: Dienstag 4. März 2008, 17:51
von Leonidas
UTF-8 ist am sinnvollsten. Meine Systeme laufen fast durchgängig damit.
Verfasst: Dienstag 4. März 2008, 18:02
von Pythonierer
Dankeschön, sofern es dem nichts mehr zuzufügen gibt, verbleibe ich mit freundlichen Grüßen und frohen Mutes,
Pythonierer!
@Leonidas: Wie schaffst du es, derart schnell zu antworten?
Verfasst: Dienstag 4. März 2008, 19:20
von Filb
also für deutschland ganz klar: iso-8859-1
das ganz normales ansi mit deutschen umlauten usw.
ich sehe in UTF-8 keinen sin, ausser man möchte in speziellen sprachen wie z.b. russisch schreiben.
Verfasst: Dienstag 4. März 2008, 19:32
von gerold
Filb hat geschrieben:ich sehe in UTF-8 keinen sin
Hallo Filb!
Der Sinn ist, dass sich endlich alle auf UTF-8 einigen und die Programmierung dadurch einfacher wird.
Zumindest im westlichen Raum ist UTF-8 die beste Wahl.
Einzig für Anfänger unter Windows, die noch keine Ahnung von den verschiedenen Encodings haben, ist ISO-8859-15 besser geeignet, da dieses Encoding **jeder** Windows-Texteditor standardmäßig anzeigen kann. Aber so bald man einen Editor gefunden hat, der mit UTF-8 gut umgehen kann, steht dem **gemeinsamen Encoding** UTF-8 nichts mehr im Weg.
Mein einziges Problem mit UTF-8 unter Windows ist, dass ich noch keinen intelligenten HTML-Editor (also einer, der auch die Attribute der verschiedenen Tags kennt und vorschlägt) gefunden habe, der mit UTF-8 umgehen kann.
mfg
Gerold

Verfasst: Dienstag 4. März 2008, 20:03
von Leonidas
Filb hat geschrieben:also für deutschland ganz klar: iso-8859-1
Perfekt geeignet um '€' abzuspeichern.
Hint: Latin-1 enthält kein Eurozeichen.
Nein, UTF-8 ist schon die beste Wahl, wie Gerold sagte - im Westen werden die Dateien nicht sonderlich größer als sie vorher mit landesspezifischen Codecs waren. Im Osten ist das natürlich etwas problematischer, aber ich denke nicht, dass es an der Dateigröße scheitern sollte. Doc-Dokumente sind ja auch um ein vielfaches größer, als der Text den sie beinhalten. Was den Wire-Transfer angeht ist es zwar größer, aber richtig große Dateien bei denen das einen Unterschied macht sind sowieso binär.
Verfasst: Dienstag 4. März 2008, 20:38
von veers
In den Fällen wo der Overhead von UTF-8 eine Rolle spielt kann man immer noch Komprimieren. Dann ist der unterschied nur noch minimal.
Verfasst: Dienstag 4. März 2008, 21:44
von Darii
Filb hat geschrieben:also für deutschland ganz klar: iso-8859-1
das ganz normales ansi mit deutschen umlauten usw.
ich sehe in UTF-8 keinen sin, ausser man möchte in speziellen sprachen wie z.b. russisch schreiben.
Und UTF-8 ist ganz normales ASCII mit allen Sonderzeichen. iso-8859-1 scheitert ja schon an „“ ‘ und €, Zeichen die in der deutschen Sprache durchaus vorkommen.

Verfasst: Mittwoch 5. März 2008, 08:19
von burli
Filb hat geschrieben:also für deutschland ganz klar: iso-8859-1
Also wenn überhaupt dann ISO-8859-15. Aber wenn ich jetzt etwas neues anfange dann nur in UTF-8 da Python3000, Linux und einige andere Systeme schon per Default damit arbeiten.
Verfasst: Mittwoch 5. März 2008, 08:35
von Hyperion
ganz leicht off-topic: 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?
Verfasst: Mittwoch 5. März 2008, 10:37
von Leonidas
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

Verfasst: Mittwoch 5. März 2008, 12:03
von mitsuhiko
Anders rum. Was hat es als nicht Japaner/Chinese/Koreaner für einen Vorteil *nicht* eines der utf Encodings zu nehmen?
Verfasst: Mittwoch 5. März 2008, 14:36
von keppla
Ich glaube, hier werden zwei Fragen vermischt, nämlich die Fragen, ob ascii oder unicode, und welches encoding für unicode.
Für nicht-unicode gibt es keinen Grund, auch in Deutschland können dir Leute über den Weg laufen, deren Namen Zeichen enthält, die nicht in ISO-8859-15 drinstehen, oder du must in € oder anderen Währungen handeln, etc.
Bleibt die Frage: welches Encoding für Unicode.
Und ich sehe mit der Fragstellung "...für Deutschland..." eigentlich keine Argumente gegen utf-8. Gegen utf-16 und utf-32 spricht, dass sie mit einem nicht-unicode-texteditor nicht sinnvoll bearbeitet werden können.
Verfasst: Mittwoch 5. März 2008, 14:39
von burli
Eben, der Vorteil von UTF-8 ist ja das alle Zeichen bis 127 wie normales ASCII behandelt werden. Die kann jeder Editor bearbeiten. Alles was >127 wird dann in 2 Bytes abgespeichert. Dafür braucht man dann einen Editor der damit etwas anfangen kann
Verfasst: Mittwoch 5. März 2008, 14:44
von keppla
Verzeih mir mein Klugscheissen, aber
burli hat geschrieben:...Alles was >127 wird dann in 2 Bytes abgespeichert.
In mindestens 2 bytes. utf-8 kann pro zeichen bis zu 4 bytes nutzen, afaik (
http://de.wikipedia.org/wiki/Utf-8)
Verfasst: Mittwoch 5. März 2008, 14:46
von burli
Ich weiß, ich wollte Klugscheißern vermeiden

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.