Re: Locale falsch?
On 13.09.05 00:39:42, Michael Rex wrote:
> Das kann ich verschmerzen, vor allem, da KDE ansonsten mit utf-8
> perfekt zurecht kommt.
Haha, der war gut. K3b kann/konnte keine CD's mit CD-TEXT erstellen,
wenn der CD-Künstler Umlaute enthaelt. k3b hat(te) die ID3-Informationen
aus mp3-Dateien nicht korrekt ausgelesen - wenn die ID3-Tags
UTF-8 kodiert sind (was durchaus normal ist in einer UTF-8 Umgebung).
Auch sonst gibts hier und da kleinere Problemchen, vor allem dann wenn
Programme annehmen eine Datei haette ein bestimmtes Encoding und das ist
dann doch nicht so...
Aber ich gebe zu: Die Situation in KDE3.3 und 3.4 ist deutlich besser
als in 2.2 oder 3.0. Nur von "perfekt" sind wir immernoch weit entfernt.
> > Ich bin v.a. aus Faulheit noch nicht
> > zurückgewechselt. Die wenigsten Internet-Seiten sind in UTF-8. Soweit
> > nicht schlimm. Aber sehr viele haben kein Charset angegeben, sodass die
> > Seite dann etwas unschön aussieht, weil halt das defaultcharset utf-8
> > ist.
> > Ähnlich bei e-Mails.
>
> Damit hatte ich bisher nun wirklich keine Probleme. Wie gesagt, ich setze
> KDE ein, sicherlich hängt das also auch davon ab, wie gut der Window
> Manager / die Desktop Environment utf-8 unterstützt.
Eher weniger, mehr ob die zugrundeliegende Widget-Bibliothek mit UTF-8
umgehen kann. GTK1 kann das nicht. Qt konnte das schon immer und
dennoch, sobald Programme diese Widget-Bibliotheken verlassen kann es zu
Problemen kommen. Mails in KMail koennen auch falsch angezeigt werden,
wenn der Sender reinschreibt die Mail ist us-ascii kodiert und dabei
enhaelt sie eigentlich latin1/latin9 - passiert Oje-Nutzern haeufig.
Oder wenn ein Client eine Mail als utf-8 deklariert obwohl sie nur
latin1 kodiert ist. Das Problem ist ja, dass man nicht aus dem
Byte-Strom ablesen kann welche Kodierung benutzt wurde und somit auf
solche Metadaten angewiesen ist - wenn die falsch sind, dann hat man
Pech.
Aehnlich ist das mit o.g. Beispiel fuer ID3-Tags, wenn im Tag kein
Encoding angegeben ist (was meiner Erfahrung nach _kein_ Tag-Editor
macht) dann nimmt k3b, kid3 usw. an es waere latin1 kodiert - selbst in
einer UTF-8 Umgebung. Das fuehrt dann zu Problemen. Einzig id3v2 macht
es "richtig" und gibt die Bytes unkodiert aus, sprich wenn die ID3-Tags
UTF-8 sind, kann ichs lesen, wenn sie latin1 kodiert sind fehlen die
Umlaute.
Solange Unicode (intern in den Programmiersprachen) und eine
Unicode-Kodierung (egal ob UTF-8, UTF-16, UTF-32 oder sonstwas) nicht
ueberall Standard sind, wirds immer irgendwo haken.
BTW: Hab grad keine Lust die UTF-16 und -32 Specs durchzusehen: Kann man
UTF-16 von UTF-8 und UTF-32 unterscheiden - nur anhand der Bytefolgen?
> > Davon abgesehen können diverser Programme nicht mit UTF-8. Mir bekannt
> > z.B. sylpheed-(claws) und irgendein Scan-Programm* (sarge-versionen).
> > Wie viele das aber insgesamt sind, weiß ich nicht.
> >
> > aktuell kann ich jetzt natürlich dem Programm das nicht mit utf-8 kann
> > eine andere lokale beim Start mitgeben. Wenn ich dann von diesem
> > Programm wieder auf die Festplatte speichere bekomme ich aber wieder
> > Probleme. Also alles (noch?) nicht so das gelbe vom Ei...
>
> Ja, leider. Linux behandelt utf-8 leider noch etwas stiefmütterlich.
Naja, Windows ist auch nicht viel besser - da gibts UCS2 nur intern,
extern wird latin1-?? koi oder sonstwas benutzt.
Andreas
--
Your motives for doing whatever good deed you may have in mind will be
misinterpreted by somebody.
Reply to: