utf8 oder iso8859-15?

[mase76]

Hallo!
Bis jetzt hab ich bei meiner Installation immer iso8859-15 als Zeichensatz gewählt.
Sollte ich stattdessen utf8 wählen? Klappt das dann noch mit den Umlauten?
Oder muss ich beide locales auswählen, und de_DE.UTF-8 UTF-8 als Standard nehmen?

Ich hab das jetzt mal probiert. In Terminalmeldungen hab ich keine Umlaute mehr.

[utkin]

Ich hab das jetzt mal probiert. In Terminalmeldungen hab ich keine Umlaute mehr.

Ich benutze UTF-8 ohne Probleme. Gibt aber auch andere, die anderes berichten. Was ist das denn für ein Terminal? Ist das unter X? Dann kann es sein, dass es mit UTF-8 nicht kann...

Gruß, utkin

[Lohengrin]

Lies dir mal durch was utf8 ist, zB bei Wikipedia.
Willst du wirklich etwas anderes nehmen? Schon bei Polnisch hast du mit ISO 8859-15 ein Problem.

[Hoshpak]

Falls du hauptsächlich mit Debian arbeitest, würde ich auf utf8 umstellen. Wenn du parallel mit Windows arbeitest, würde ich es bei iso lassen. Windows macht leider häufig Probleme mit utf8 und sich immer Workarounds zu suchen, nervt nach einer gewissen Zeit.

[mase76]

Ich nutze kein Windows. Konsole von KDE hat ein paar Probleme gemacht. Allerdings
hab ich nur den Clienten umgestellt und über nfs auf den Server zugegriffen. Da hatte
ich ein paar ? anstatt der Umlaute.
Wie ist das mit den vorhandenen Dateinamen? Kann's da Probleme geben?
Und weitere Locales unterstützen bei dpkg-reconfigure locales? Ich hatte utf8 und 8859-15,
aber utf8 als Default.
Ich weiss, das sind viele Fragen, aber bevor ich mir alles versaue.

[KBDCALLS]

Bei einigen Programmen und auch Manpages stellt man fest das die noch nicht richtig UTF-8 geeignet sind. Habe zwar als Standard UTF-8 eingestellt, manchmal mus doch

Code: Alles auswählen

export LC_ALL=POSIX

ran

[Hoshpak]

Mit den dateinamen kanns schon Probleme geben, es gibt aber ein Migrationstool (ich habe den Namen gerade nicht im Kopf), das einem alle Dateinamen in utf8 konvertiert. Das einmal durchlaufen lassen, dann gibts keine Probleme mehr. Das mit dem utf8-default und iso daneben mache ich auch so, ich hatte damit bis jetzt keine Probleme. Bei nfs kenne ich mich jetzt nicht aus, eventuell unterstützt das utf8 gar nicht. Vielleicht muss man das aber auch irgendwie umstellen. Wie gesagt, nicht gerade mein Fachgebiet.

[LessWire]

Ich würde eine Neuinstallation nur noch mit UTF-8 vornehmen.
Sicherlich kann es mühsam sein, wenn viele Dateinamen oder Texte noch ISO-Umlaute beinhalten, die Tools dafür helfen leider nicht immer und man muß dann manuell nachbearbeiten.

Jedenfalls: Es führt künftig kein Weg an UTF-8 vorbei!

vg, L.W.

[deadeye]

Ich bin auch der Meinung, UTF-8 und nix anderes. Es it a) einfach besser, b) neuer und c) sobald alle UTF-8 benutzen gibt's keine Zeichensatz-Probleme mehr. Bzw. statt UTF-8 generell Unicode.

Das Windows mit UTF-8 Probleme hat, kenne ich. Wenn das auch total prardox ist, weil Windows schon seit Ewigkeiten intern UTF-16 für Dateinamen benutzt(Stichwort Wide-Character-API). Komischerweise sind zum. FAT-Dateisysteme irgendwie in ISO.8859-15 kodiert. Windows mag verstehen wer will.
Richtig Spaß macht das, wenn man Anwendungen schreibt, die Dateinamen lesen und in UTF-8 ausgeben, das ist jedes Mal ein Rätselraten, unter Linux wie unter Windows, wenn auch bei letzterem wesentlich extremer.

Deine Probleme auf der Konsole mit NFS rühren sicher daher, dass der Server sicher noch ISO spricht und wenn Dein Client auf UTF-8 läuft, dann krachts halt. Ich vermute, in Deiner Konsole lokal hast Du normal alle Umlaute ohne Probleme?

Gruß
dead - der seit 2 Jahren UTF-8 für seine Systeme benutzt -eye

[MarcM]

Mit den dateinamen kanns schon Probleme geben, es gibt aber ein Migrationstool (ich habe den Namen gerade nicht im Kopf), das einem alle Dateinamen in utf8 konvertiert.

Danke für den Hinweis.....ich hab sowas gerade gesucht.

Und damit ich halbwegs im Thema bin....:
das Tool heißt convmv

Greetz
Marc

[Lohengrin]

Das Windows mit UTF-8 Probleme hat, kenne ich. Wenn das auch total prardox ist, weil Windows schon seit Ewigkeiten intern UTF-16 für Dateinamen benutzt(Stichwort Wide-Character-API).

UTF-16? Warum benutzt man denn sowas? Das ist doch völlig bescheuert.
Der größte Pluspunkt von UTF-8 ist, dass ASCII ASCII bleibt. Mit UTF-16 werden ASCII-Texte doppelt so lang.

Ich glaube dass Microsoft nicht auf UTF-8 gehen will. Nicht-Kompatibilität ist für den Monopolisten gut.

[hupfdule]

Der größte Pluspunkt von UTF-8 ist, dass ASCII ASCII bleibt.

Das ist der größte Schwachpunkt. Denn, im Gegensatz zu UTF-16, werden UTF-8 Dateien nicht als solche kenntlich gemacht. Die Kompatibilität mit reinen ASCII-Texten ist damit gewährleistet, das Zusammenspiel mit ISO-8859 Dateien jedoch zugrunde gerichtet. Es ist einer Datei nun nicht mehr klar ersichtlich, in welchem Encoding sie gespeichert ist. Entsprechend miserabel funktioniert dadurch auch der Datenaustausch mit Dateien, die Umlaute beinhalten. Man erreicht dadurch nur, dass einem die Dateien nun kaputt gehen, ohne dass man es mitbekommt....

Laut der Unicode FAQ soll ein BOM für UTF-8 Dateien zwar zulässig sein, jedoch ist mir noch keiner derartige Datei untergekommen...

[deadeye]

Der größte Pluspunkt von UTF-8 ist, dass ASCII ASCII bleibt.

Das ist der größte Schwachpunkt. Denn, im Gegensatz zu UTF-16, werden UTF-8 Dateien nicht als solche kenntlich gemacht.

Full ACK.

Entsprechend miserabel funktioniert dadurch auch der Datenaustausch mit Dateien, die Umlaute beinhalten.

Oh ja! Es ist reines Rätsel-Raten wenn man eine Datei bekommt und soll diese Öffnen. Die gängige[1] und trotzdem IMO total suboptimale Lösung die Kodierung einer Datei herauszufinden ist, die Datei der Reihe nach mittels iconv in bekannte Kodierungen zu konvertieren, und sobald kein Fehler dabei auftritt, nimmt man an, man hat das Richtige gefunden.
Das ist eigentlich totaler Blödsinn, weil a) sehr ineffektiv und b) fehleranfällig.
Solang irgendwas reines ASCII (0..127) ist, ist alles gut, das wird dann als UTF-8 erkannt und fertig. Wenn es echtes UTF-8 ist, also auch mit nicht ASCII-Zeichen, klappt auch noch alles. Die Probleme gehen bei allem nicht ASCII- und nicht Unicode-Text los. Z.B. ist es soweit ich weiß nicht möglich, eine Datei mit ISO-8859-1 und ISO-8859-15 zu unterscheiden. Ähnliches gilt für die verschiedenen kyrillischen Kodierungen. Das ist alles ein einziger Krampf, zum. aus Sicht von Anwendungsentwicklung.

Laut der Unicode FAQ soll ein BOM für UTF-8 Dateien zwar zulässig sein, jedoch ist mir noch keiner derartige Datei untergekommen...

"soll" ist das richtige Wort. Die Sache mit dem BOM(Byte-Order-Mark, sozusagen eine Notiz am Anfang der Datei wie die folgenden Daten kodiert sind) ist an sich eine gute Idee. Schade nur, dass sich Notwendigkeit dafür überhaupt ergeben hat. Aber die Amis haben halt anfang der 70er Jahre nicht drüber nachgedacht, dass es vielleicht noch Leute gibt, die etwas anderes sprechen als Englisch, als sie ASCII eingeführt haben. Typische Sache das.
Nunja, zurück zum BOM: wie gesagt, an sich ne feine Sache, nur dass viele Programme damit nicht klarkommen(shells, gcc, php, ...). Aber ich kann mit ruhigem Gewissen sagen, der Editor Geany kann mit BOMs umgehen (hab mich lange genug damit rumgeschlagen).

UTF-16? Warum benutzt man denn sowas? Das ist doch völlig bescheuert.

Nee, völlig geil. Das ist wenigstens eindeutig und einfach. UTF-8 war ja anfangs auch nur als provisorische Übergangslösung gedacht(daher auch die ASCII-Kompatibilität) aber irgendwie scheint es mehr und mehr Standard zu werden.
Nunja, hoffen wir, dass wenigstens aktuelle Programme, die sich UTF-8 Unterstützung auf die Fahne schreiben dann auch Unicode im Ganzen unterstützen, wenigstens UTF-16.

Mit UTF-16 werden ASCII-Texte doppelt so lang.

Who cares. Speicherplatz ist heutzutage sooooo billig. Und auch mit UTF-8 werden Texte länger, wenn auch nur für nicht-ASCII Zeichen.

Das folgende nicht falsch verstehen, ich bin alles andere als ein M$-Freund.

Ich glaube dass Microsoft nicht auf UTF-8 gehen will. Nicht-Kompatibilität ist für den Monopolisten gut.

Blödsinn. Die Frage ist, warum nicht alle anderen endlich auf UTF-16 gehen.
UTF-16 ist besser als UTF-8(nicht nur wegen der höheren Zahl *g*). Ich hab das bei Windows noch nicht so richtig durchschaut, warum irgendwie intern dort alles auf UTF-16 arbeitet, die Dateinamen im FAT irgendwie als ISO-8859-15 rumliegen und warum GTK's GLib-Bibliothek unter Windows Dateinamen in UTF-8 behandelt.
Womöglich hängt das mit der abartigen Abwärtskompatibilität von Windows zusammen, weil AFAIK gibt's die Wide Character API seit Windows 2000, vorher war's irgendwie ASCII. Wie auch immer, UTF-16 ist ne feine Sache, nutzt nur sogut wie keiner.

[1] zum. in mir bekannten Editoren wie anjuta, gedit, geany.

Gruß
deadeye

[mase76]

Na jedenfalls war die Umstellung erfolgreich.
Mein Mailserver macht da nur nicht so ganz mit. Da sind alle Umlaute kaputt.
Liegt das an cyrus?
Ich verwende fetchmail, cyrus, postfix

Nochwas: Muss oder soll ich trotzdem noch set-language-env ausführen, wenn
das System mit utf8 installiert wird?

[Lohengrin]

Der größte Pluspunkt von UTF-8 ist, dass ASCII ASCII bleibt.

Das ist der größte Schwachpunkt. Denn, im Gegensatz zu UTF-16, werden UTF-8 Dateien nicht als solche kenntlich gemacht.

Full ACK.
...

UTF-16? Warum benutzt man denn sowas? Das ist doch völlig bescheuert.

Nee, völlig geil. Das ist wenigstens eindeutig und einfach.

Wie unterscheidest man ISO-8859-15 von UTF-16? Das ist doch dasselbe Problem wie die Unterscheidung von ISO-8859-15 von UTF-8.

[mase76]

Das ein oder andere KDE-Programm scheint noch Probleme damit zu haben.

[uwepr]

Wie unterscheidest man ISO-8859-15 von UTF-16? Das ist doch dasselbe Problem wie die Unterscheidung von ISO-8859-15 von UTF-8.

Hauptunterschied ist die Anzahl der enthaltenen Zeichen:
ASCII: 127 Zeichen (7 bit)
ISO-Zeichensätze: 127 ASCII-Zeichen + 128 Sonderzeichen (8 bit)
Unicode (16 bit) wurde ursprünglich entwickelt, um das 8-bit-Durcheinander in ISO-n zu lösen.
===> Unicode UTF-16 als 16-bit-Zeichensatz.====>Verdopplung des Speicherbedarfs, auch wenn ein Text nur aus ASCII-Zeichen besteht. Zweites Problem: 0 tritt an beliebigen Stellen in Unicode-Zeichenketten auf, 'ne Menge Programme, u.a. in C setzen voraus, das das Byte 0 das Ende einer Zeichenkette markiert. Außerdem gibt es bei UTF-16 je nach Byte-Reihenfolge zwei Formen:Big-Endian und Little-Endian===>UTF-8: ASCII-Zeichen werden durch 1 Byte dargestellt, mit 0 als obersten bit, alle anderen durch zwei bis vier Byte lange Ketten.
Und um das Problem perfekt zu machen: Windows benutzt "Code-Pages", wobei 1252 große Ähnlichkeit zu ISO-8859-1 hat. Vermutlich um eine Etage tiefer als die Code-Pages wird dann möglicherweise intern UTF-16 benutzt. [Quelle u.a. M. Kofler:Linux...]
Man erkennt an dieser Problematik sehr gut, welcher Herrausforderung sich die Debian-Entwickler stellen, um Debian auf so vielen Architekturen verwenden zu können sihe:
http://de.wikipedia.org/wiki/Little_Endian
http://de.wikipedia.org/wiki/Big_Endian
http://de.wikipedia.org/wiki/UTF-16
http://de.wikipedia.org/wiki/UTF-8
http://de.wikipedia.org/wiki/ISO-8859-15
http://de.wikipedia.org/wiki/ASCII
wobei bei der ASCII-Verwendung schon die Unterschiede zwischen den Betriebssystemen zu Tage treten.
Viele Grüße! Uwe Pr.

P.S.: vor unseren Entwicklern!

[Lohengrin]

Wie unterscheidest man ISO-8859-15 von UTF-16? Das ist doch dasselbe Problem wie die Unterscheidung von ISO-8859-15 von UTF-8.

Hauptunterschied ist die Anzahl der enthaltenen Zeichen:
ASCII: 127 Zeichen (7 bit)
ISO-Zeichensätze: 127 ASCII-Zeichen + 128 Sonderzeichen (8 bit)
Unicode (16 bit) wurde ursprünglich entwickelt, um das 8-bit-Durcheinander in ISO-n zu lösen.

Missverständnis!
Eine Datei in UTF-16 fängt mit dem BOM FFFE an. Das könnte aber auch ÿþ in ISO-8859-15 sein. Man kann der Datei nicht ansehen, dass es UTF-16 ist.
Ok, man kann einfach mal davon ausgehen, dass keine (ISO-8859)-Datei mit FFFE anfängt. Dasselbe kann man aber auch mit dem BOM für UTF-8 machen.
Weil aber das BOM für UTF-8 Probleme in Skripten macht, sollte man Skripte ohne BOM schreiben. Und weil man sowieso nicht zwischen den verschiedenen ISO-8859 unterscheiden kann, kann man auch gleich von UTF-8 ausgehen. ISO-8859 ist Altlast und gehört konvertiert.

[uwepr]

Hallo Lohengrin,

Eine Datei in UTF-16 fängt mit dem BOM FFFE an.

ist, wenn ich's richtig verstehe, nur die halbe Wahrheit, je nachdem, ob Big Endian(FE FF) oder Little Endian (FF FE), was natürlich nichts an den Problemen ändert.

Ok, man kann einfach mal davon ausgehen, dass keine (ISO-8859)-Datei mit FFFE anfängt. Dasselbe kann man aber auch mit dem BOM für UTF-8 machen.

Leider eben nicht,

da in den 8-Bit-Zeichensätzen alle Bytesequenzen erlaubt sind, auch die UTF-8-Kodierung des BOM.

sihe http://de.wikipedia.org/wiki/Byte_Order_Mark
Viele Grüße!

[Tutti]

Ich nutze kein Windows. Konsole von KDE hat ein paar Probleme gemacht. Allerdings
hab ich nur den Clienten umgestellt und über nfs auf den Server zugegriffen. Da hatte
ich ein paar ? anstatt der Umlaute.
Wie ist das mit den vorhandenen Dateinamen? Kann's da Probleme geben?
Und weitere Locales unterstützen bei dpkg-reconfigure locales? Ich hatte utf8 und 8859-15,
aber utf8 als Default.
Ich weiss, das sind viele Fragen, aber bevor ich mir alles versaue.

Wegen der Konsole in KDE, das Probleme habe ich auch: Home PC UTF-8, auf der Arbeit alles in ISO8859-15. Wenn ich mich dann per SSH einlogge, um schnell ein paar Daten zu kopieren oder ähnliches, muss ich auch aufpassen:
Du kannst in der KDE Konsole oben im Menü die Kodierung einstellen, wie die Zeichen _angezeigt_ werden. Da dein System UTF-8 als Standard hat, ist dies auch da eingestellt. Loggst du dich jetzt per Konsole auf einem PC ein, der zB ISO8859-15 eingestellt hat, so sendet dieser PC auch die Dateinamen in der Kodierung, deine Konsole nimmt aber UTF-8 an. Dadurch kommt natürlich Murks raus, ist übrigens bei der Eingabe genauso.

Abhilfe: Konsole, wenn auf einem solchen PC eingeloggt, eben umstellen. (Einstellungen -> Kodierung).

[Leonidas]

Also ich benutze schon seit einigen Jahren UTF-8 und bin damit recht zufrieden. Klappt auch eigentlich in allen Programmen die ich nutze, aber das sind meist GTK-Sachen, da scheints auch generell wenige Probleme zu geben.