ISO-8859-X oder UTF-X
-
froschy schrieb:
Was würdet ihr mir also raten. Soll ich meine Website und Datenbank in Latin1 belassen oder auf UTF-8 umstellen? Ich hoffe das mir endlich mal jemand Licht ins Dunkle bringen kann, mit einem einleuchtenden Grund.
also, ich verwende schon seit Jahren (auschließlich) UTF-8. Damit waren für mich alle Probleme mit unterschiedlichen Kodierungen, falsch angezeigte Sonderzeichen, usw. gelöst. Mich ärgert auch wahnsinnig, dass Leute mir Mails in latin1 schicken, leider sind das in Deutschland die meisten
-
Zum Topic: Einfach alles auf UTF umstellen, wo das keine riesigen Probleme verursacht. Spart Zeit und Nerven.
supertux schrieb:
Mich ärgert auch wahnsinnig, dass Leute mir Mails in latin1 schicken, leider sind das in Deutschland die meisten
Warum? Kannst Du doch trotzdem bestens lesen.
Und ganz ehrlich: Darum sollte sich ein 0815-User keine Gedanken machen müssen, was ja offensichtlich auch nicht passiert.
-
nman schrieb:
Und ganz ehrlich: Darum sollte sich ein 0815-User keine Gedanken machen müssen, was ja offensichtlich auch nicht passiert.
Stimmt, es sollte einfach alles auf Unicode umgestellt werden. Diese leidigen ISO-Xxxxx sollte endlich in Vergessenheit versinken.
-
Vielen Dank für euer Feedback. Wie ich merke, UTF-8 muss her. Nur eine verständigungsfrage noch: Gehe ich richtig der Annahme, dass sowohl ISO-8859-1 als auch UTF-8 jeweils 8 bits zur verfügung haben, also 1 byte und somit 256 mögliche Zeichen? Der Unterschied zu UTF-8 besteht scheinbar darin, wenn (und nur wenn) es nicht ausreicht, wird ein zweites Byte dazu gehängt, korrekt? UTF-16 müsste demnach immer gleich mit 2 bytes arbeiten, auch wenn 1 byte ausreichen würde.
Hm, dann gleich noch eine Frage: Warum gibt es dann UTF-32? UTF-16 würde dann ja über 65.000 Zeichen darstellen können. Doesn't makes sence for me
-
UTF-8 benutzt 1, 2, 3 oder 4 Bytes zur Speicherung des Zeichens.
UTF-16 benutzt 2 oder 4 Bytes zur Speicherung des Zeichens.
UTF-32 benuttzt 4 Bytes zur Speicherung.Der aktuelle Unicode Standard hat mehr als 216 (65536) Zeichen.
Ein Argument gegen UTF-8 ist übrigens, dass für asiatische Schriftzeichen oft 3 Bytes verwendet werden müssen. Deshalb kenne ich doch einige Anwendungen, welche auf UTF-16 setzen, um die Speichernutzung bei asiatischen Texten zu reduzieren. Da es allerdings bei UTF-16 eine BE und LE Version gibt (bei UTF-32 übrigens auch), verwende ich allerdings lieber UTF-8. Speicher sollte heutzutage genügend vorhanden sein
Noch ein paar Links:
http://en.wikipedia.org/wiki/Unicode_Transformation_Format
http://www.cl.cam.ac.uk/~mgk25/unicode.html
http://www.unicode.org/versions/Unicode5.0.0/Grüssli
-
nman schrieb:
supertux schrieb:
Mich ärgert auch wahnsinnig, dass Leute mir Mails in latin1 schicken, leider sind das in Deutschland die meisten
Warum? Kannst Du doch trotzdem bestens lesen.
jaein, aber das liegt eher am Thunderbird. Ich habe in der Anzaige UTF-8 als Default gesetzt und auch wenn in der Mail-Header ISO-8859-x als Kodierung steht, zeigt Thunderbird die Mail als UTF-8 an, was z.b. Umlaute falsch anzeigt.
nman schrieb:
Und ganz ehrlich: Darum sollte sich ein 0815-User keine Gedanken machen müssen, was ja offensichtlich auch nicht passiert.
richtig, ärgern darf ich mich aber trotzdem
deshalb nerve ich keinen, der mir eine Mail in nicht-UTF-8 schickt, weil es meistens an der Software liegt. Vor allem webmailer (web.de/gmx) und Outlook scheinen nur latin1 zu kennen.
-
Dravere: Das ist eben genau das was mir nicht einleuchtet. Alle UTF Formen können bis zu 4 Bytes ausschöpfen nur eben UTF-16 ab 2 Bytes und UTF-32 ab 4 Bytes. Warum also dann nicht nur UTF-8 verwenden, welches flexibel von 1-4 Bytes ausschöpft, also "nach gebrauch" und die anderen Formen hingegen ab 2 oder gar 4 Bytes. Das macht für mich keinen Sinn. Macht Daten Sinnlos aufgebläht. Wo steckt also der Sinn hinter UTF-16 und UTF-32, welche Sinnlose bits und damit Speicher verschiessen, wenn doch UTF-8 das ganze "inteligent" lösen kann?
-
[/b]Die einzigste Möglichkeit die ich mir vorstellen kann, ist "Performance". Wahrscheinlich muss man bei UTF-16 weniger rechnen und bei UTF-32 noch weniger, weil es schneller klar ist, welches Zeichen, bzw. dezimal Zahl gemeint ist. Bei UTF-8 müssen ggf. bits überprüft werden. Kommt das inetwa hin? So hätte man die Quahl der Wahl, wie es oft in der Computer Welt ist: Speicherplatz oder Performance.
BTW: Es gibt über 65.000 Zeichen!?! Bin ich der einzigste der das unglaublich findet?
-
Wikipedia sagt dazu vollgendes:
Characters U+0800 through U+FFFF use three bytes in UTF-8, but only two in UTF-16. As a result, text in (for example) Chinese, Japanese or Hindi will take more space in UTF-8 if there are more of these characters than there are ASCII characters. However, ASCII includes spaces, numbers, newlines, some punctuation, and all characters used in almost all programming and markup languages, so it is not unusual for ASCII characters to dominate. For example both the Japanese and the Korean UTF-8 article on Wikipedia take more space if saved as UTF-16 than the original UTF-8 version [18]
So ist UTF-16 platzsparender, wenn du nur z.B. Chinese, Japanese or Hindi als Text hast.
Eigentlich waere es mir weitaus lieber, wenn es nur ein Format gebe: UTF. Dann koennten alle OS und APIs einfach nur das UTF verwenden, somit sich alle Probleme mit konvertion und alle vergessenen "code=utf-xxx" in nichts aufloesen. Man braeuchte zwar ein wenig mehr Speicherplatz oder mehr Rechnungskapazitaet, aber ich denke es waere ein Vorteil.
Wenn man natuerlich nur Chinesisch braucht, dann sind alle Texte bei UTF-8 dreimal so gros, als wenn man Englisch verwendet. Aber man braucht in der I.T. eh die ASCII Zeichen und in Zukuft braucht man auch andere Sprachen mehr und mehr, weil durch das Internet werden alle Laender verbunden.
-
denk mal an z.B. asiatische Schriften, in denen einzelne Schriftzeichen ganze Wörter symbolisieren können - da kommen bei einigen Schriften 10.000 Zeichen zusammen; nähme man Zeichen aus alter Literatur hinzu, gelangte man, über alle Schriften gezählt, in den 6-stelligen Bereich.
-
froschy schrieb:
BTW: Es gibt über 65.000 Zeichen!?! Bin ich der einzigste der das unglaublich findet?
Nicht wirklich. Wenn du z.B. hier siehst: http://en.wikipedia.org/wiki/Chinese_character#Number_of_Chinese_characters
-
froschy schrieb:
Doesn't makes sence for me
Wieder so typisch. Englisch benutzen weil der Herr denkt damit "cool" zu sein, aber es nicht mal können.
-
BTW: strlen() lässt sich viel einfacher mit einer fixen Zeichenbreite berechnen. Also irgendwann in ferner Zukunft nur noch UTF-32.
MfG SideWinder
-
Freigeist11 schrieb:
froschy schrieb:
Doesn't makes sence for me
Wieder so typisch. Englisch benutzen weil der Herr denkt damit "cool" zu sein, aber es nicht mal können.
Wieder so typisch. Sich in einem Thread mit einem sinnlosen Posting äussern, nur weil der Herr denkt, damit "cool" zu sein.
An alle anderen: Vielen Dank für die guten Antworten.
-
supertux schrieb:
jaein, aber das liegt eher am Thunderbird. Ich habe in der Anzaige UTF-8 als Default gesetzt und auch wenn in der Mail-Header ISO-8859-x als Kodierung steht, zeigt Thunderbird die Mail als UTF-8 an, was z.b. Umlaute falsch anzeigt.
Das hatte ich auch mal. Damals hatte ich einfach überall UTF-8 gewählt. Dann hab ich ein wenig damit herumgespielt, und ein irgendein Feld auf automatisch gestellt, und seitdem macht er alles so wie er soll. Du kriegst das hin!
Ontopic muss noch mein Senf dazu:
Haben wir eigentlich was gewonnen, wenn wir zwar "alle Codepages abgeschafft" haben, nun aber trotzdem noch mehrere Kodierungen haben? Ich glaube nicht, weil wir immer noch auf das Format achten müssen. Also ein Pyrrhussieg?
-
SideWinder@Win7 schrieb:
BTW: strlen() lässt sich viel einfacher mit einer fixen Zeichenbreite berechnen. Also irgendwann in ferner Zukunft nur noch UTF-32.
MfG SideWinder
Deshalb benutzt man applikationsintern auch gerne wide-characters und nur zum Speichern multi-byte
Mir ist das Format eigentlich egal, Emacs kommt mit allen wunderbar zurecht
Und wenn ich mal ein Tool wie a2ps benutze, dann wandel ich die Datei schnell mit iconv in das richtige Format um.
-
µngbd schrieb:
Haben wir eigentlich was gewonnen, wenn wir zwar "alle Codepages abgeschafft" haben, nun aber trotzdem noch mehrere Kodierungen haben? Ich glaube nicht, weil wir immer noch auf das Format achten müssen. Also ein Pyrrhussieg?
Naja, man kann allerdings die verschiedenen Formate sehr gut unterscheiden, bzw. erkennen. Gibt zudem auch noch diese Bytes:
http://de.wikipedia.org/wiki/Byte_Order_MarkSideWinder@Win7 schrieb:
BTW: strlen() lässt sich viel einfacher mit einer fixen Zeichenbreite berechnen. Also irgendwann in ferner Zukunft nur noch UTF-32.
Gibt noch einen anderen Grund, um im Programm UTF-32 zu verwenden. Es ist die speicherschonendste Lösung für Random Access auf die einzelnen Zeichen. Für UTF-8 oder UTF-16 muss man entsprechende Tabellen mitführen. Zudem vermute ich, dass ein UTF-32 String etwas schneller zum Verarbeiten sein könnte.
@froschy,
Wegen der Anzahl Zeichen hier mal eine Liste der bisherigen Blöcke:
http://de.wikipedia.org/wiki/Liste_der_Unicode-Bl%F6ckeUnd es kommen noch viele mehr. Zum Beispiel sind aktuell auch die ägyptischen Hieroglyphen geplant. Es werden also auch ausgestorbene Sprachen in den Unicode Standard aufgenommen. Auch werden Zeichen aufgenommen, welche mehr der Darstellung als der Schrift dienlich sind, usw. usf.
Grüssli
