Unicode auf Build-System vs. ISO-8859-1 auf Fritz!Box

kriegaex

Aktives Mitglied
Mitglied seit
7 Nov 2006
Beiträge
2,927
Punkte für Reaktionen
3
Punkte
36
Wir sind in diesem Thema nicht ganz on-topic, aber ich möchte es dennoch aus aktuellem Anlaß (siehe diesen und Folgebeiträge) eröffnen, da es in der täglichen Arbeit am und mit dem DS-Mod eine Rolle spielt:

Die meisten aktuellen Linux-Distributionen verwenden in der Konsole und in den GUI-Editoren inzwischen Unicode (meistens [noparse]UTF-8)[/noparse] als Standard-Zeichensatz. Das bewirkt, daß z.B. Umlaute und andere Sonderzeichen als zwei Bytes kodiert werden. Genau das passiert aber auch, wenn Dateien für den Einsatz auf der Fritz!Box editiert oder neu erzeugt werden.

Nun läuft aber auf der Fritz!Box standardmäßig alles in ISO-8859-1 (meinetwegen auch 8859-15, der Unterschied ist ja nur das Euro-Zeichen bei -15) ab. Zeigt man daher Unicode-Textdateien mit Sonderzeichen auf der Box an, sehen sie nicht aus, wie man es erwartet.

Kann mir ein Linux-Guru mal erklären, wie man das am elegantesten löst? Ich habe vor Monaten mit viel Mühe - es gibt viele Stellen, an denen man etwas umstellen muß und kaum sinnvolle Dokumentation, wie das geht - meine Distribution komplett von UTF-8 auf ISO-8859-15 umgestellt, denn ich verwende sie innerhalb einer VM sowieso nur, um an ds26 zu entwickeln. Vorher mußte ich immer aufpassen, daß der Editor im richtigen Zeichensatz abspeichert, wobei nicht jeder Editor mir die Wahl ließ. Entweder sahen die Dateien an der Konsole falsch aus oder im Editor oder auf der Box.

Patentrezepte zum korrekten Umgang mit dem Zeichensatz-Problem wären mir an dieser Stelle willkommen. :D Ich selbst bin mit meinem ISO-8859-15 glücklich, weil ich auch auf dem PC-Linux keinen Unicode-Bedarf habe. Wenn aber jemand Linux mit Unicode täglich nutzt und auf demselben System nur nebenbei mal am DS-Mod herumschrauben möchte, kann ich mir gut vorstellen, daß dieser Jemand ungern vorher alles von Unicode auf ISO-8859-15 umstellen möchte, wie ich das getan habe.
 
Zuletzt bearbeitet:
Ein Patentrezept kann ich leider nicht liefern, aber ein paar Tools aufzeigen:
Mit dem file-Kommando, was in gängigen Distributionen enthalten ist, kann man sich anzeigen lassen, um welche Dateityp es sich bei den enthaltenen Daten handelt. Bei Textdateien zeigt dieses Tool auch an, ob es sich um UTF-8-, ISO-codierte oder reine ASCII-Dateien handelt.
Code:
tonne:/srv/smb/daten# file ISO.txt UTF8.txt
ISO.txt:  ISO-8859 text
UTF8.txt: UTF-8 Unicode text
Mit dem iconv-Tool kann man eine Kodierung in eine andere überführen - falls dies möglich ist, d.h. eine Abbildungsregel existiert. Dabei muss man als Parameter -f (--from) die Ausgangskodierung und die Zielkodierung angeben -t (--to), sowie das Inputfile. Der Output kommt traditionell auf stdout, oder in das via -o spezifizierte File. (Da kann man sich ja einen Wrapper basteln, der das noch einen Tick komfortabler macht.)
Code:
tonne:/srv/smb/daten# iconv -f ISO-8859-1 -t UTF-8 ISO.txt -o ISO-conv-UTF8.txt
tonne:/srv/smb/daten# iconv -f UTF-8 -t ISO-8859-1 UTF8.txt -o UTF8-conv-ISO.txt
tonne:/srv/smb/daten# file *.txt
ISO-conv-UTF8.txt: UTF-8 Unicode text
ISO.txt:           ISO-8859 text
OhneUmlaute.txt:   ASCII text
UTF8-conv-ISO.txt: ISO-8859 text
UTF8.txt:          UTF-8 Unicode text
 
Ich verwende für den ds-mod ein SUSE Linux 10.1 System. UTF-8 ist bei SUSE schon länger Standard, ich weiß nicht mehr genau, seit wann. Ich habe mit dem UTF-8 und dem ds-mod bisher nie ein Problem gehabt.

Wenn ich das System auf ISO-Zeichensatz umstellen wollte, würde ich nachschauen, wo die Einstellung
Code:
LANG=de_DE.UTF-8
herkommt. Anscheinend ist es /etc/sysconfig/language:RC_LANG="de_DE.UTF-8". Das würde ich dann auf "LANG=de_DE" ändern, entweder in der oben genannten Datei oder in /etc/profile oder in ~/.profile. Wichtig ist auch, daß Putty auf die gleiche Kodierung eingestellt ist, die auch das Linux System erwartete / erzeugt.

Als Editor verwende ich Emacs, der richtet sich nach dem Wert von LANG.

Wie bereits angedeutet, habe ich mit aber bisher keine Gedanken darüber gemacht. UTF-8 und ISO-8859-x sind in der ersten Hälfte (0-127) beide gleich und beide gleich mit dem ASCII Zeichensatz (und mit fast allen anderen außer EBCDIC). Solange man also keine Umlaute oder andere spezielle Zeichen verwendet, gibt es keinen Unterschied zwischen UTF-8, ISO-8859-x und ASCII. Die meisten Programme und Skripte beschränken sich auf den ASCII Zeichensatz, so daß es keinen Unterschied gibt.

Es wäre jetzt schön zu wissen, wo es tatsächlich ein Problem mit UTF-8 gegeben hat. Anscheinend hat jemand in einem Skript das Paragrafen-Zeichen '§' für IFS verwendet. Da zumindest in der Anlage aus Beitrag #474 sonst nirgends ein Paragrafen-Zeichen vorkommt und ich auch sonst keinen Sinn darin erkennen kann, an IFS zweimal das gleiche Zeichen zuzuweisen, gehe ich eher davon aus, daß es sich hier um ein Versehen handelt oder um etwas, was von einem Editor ungefragt eingebaut wurde. Falls das Zeichen dagegen mit Absicht als Trennzeichen verwendet wurde, ist es wegen der Zeichensatz-Problematik eine schlechte Wahl.

Generell ist es aber kein Problem, auch Dateien im ISO-8859-1 Kodierung zu erstellen. Dies ist sogar die Standard-Einstellung beim Emacs bei meinem System, obwohl die Kodierung des Terminals UTF-8 ist. Dafür braucht man natürlich einen Editor, der UTF-8 unterstützt. Dies sollte aber bei den Editoren, die auf einem UTF-8 System vorhanden sind, der Fall sein.

Daher die Frage:
Wo genau liegt das Problem?
 
Ich habe kein Problem, da ich auch einem 8859-15-System arbeite. Aber auch an der Konsole auf der Box will ich evtl. mal Umlaute sehen, und wenn ich plötzlich eine UTF-8-Datei auf der Box habe, sehe ich Müll.

Weitere (frühere) Probleme, die ich hatte waren:
  • Ich wollte nicht manuell mittels iconv immer wieder umwandeln müssen, das hätte ich sowieso zu oft vergessen.
  • Nicht alle Editoren - ich verwende, je nach Situation, vier unterschiedliche (Nano, SciTE, vi, mcedit) - achten auf dieselben Einstellungen. Wie das genau war, kriege ich nicht mehr auswendig zusammen, aber ich weiß noch, es war unterschiedlich.
  • Einfach nur die genannten Umgebungsvariablen umzustellen, hat definitiv nicht gereicht. Es gibt ziemlich viele Variablen, die in unterschiedlichen Situationen von unterschiedlichen Programmen abgefragt und/oder (auch nicht) interpretiert werden, weil - da ist Linux einfach mal im Nachteil gegenüber einem proprietären System aus einem Guß wie Windows - vieles historisch gewachsen, manches nachträglich angeflanscht und alles von unterschiedlichen Autoren ohne gemeinsames Konzept gebastelt wurde.

Man kann all dem widersprechen (nach dem Motto "Linux ist gut durchdacht, alles ist einfach, wenn man weiß wie"), aber die Argumente sind alle zahnlos aus meiner Sicht, denn ich hatte zu kämpfen trotz aktueller Distribution. Und einen zentralen Schalter, der das gesamte System inkl. aller Anwendungen von ISO auf Unicode oder umgekehrt umstellt, gibt es definitiv nicht. Diverse dpkg-reconfigure-Aufrufe, Editieren von ~/.bashrc u.ä. Tricks waren notwendig. Und als ob das nicht genug wäre, würde mein Vorgehen auf nicht debian-basierenden Systemen wieder anders laufen.

P.S.: Daß Unicode- und 8-Bit-Zeichensätze eben nicht ganz friedlich koexistieren bzw. sich Unicode noch nicht überall durchgesetzt hat (inkl. Fritz!Box), sieht man ja gerade an solchen Argumenten wie "dann verwenden wir eben nur die ersten 128 ASCII-Zeichen, die anderen werden ja sowieso nicht gebraucht". ;-) Mir ist schon klar, daß z.B. Webseiten nicht das große Problem darstellen, weil sie am Client interpretiert werden und man den Zeichensatz direkt hinein schreiben kann, aber es gibt ja auch Templates, die durch Shellskripten ergänzt werden - gerade im DS-Mod-UI ist das der Fall.
 
Zuletzt bearbeitet:
Ich würde nicht behaupten, daß bei Linux alles gut durchdacht ist und zusammen paßt.

Aber auch der Satz "Windows - vieles historisch gewachsen, manches nachträglich angeflanscht und alles von unterschiedlichen Autoren ohne gemeinsames Konzept gebastelt" trifft meiner Meinung nach zu, auch wenn es nicht das ist, was Du damit sagen wolltest. Es trifft meiner Meinung nach sogar auf Windows selbst zu und nicht nur auf die ganzen Programme, die es für Windows gibt. Und mit einem Windows ganz ohne zusätzliche Anwendungsprogramme kann man noch fast nichts machen.

Ich weiß auch nicht, ob es mit dieser einen genannten Umstellung getan wäre, wie gesagt, habe ich mir bisher nie groß Gedanken darüber gemacht, weil die UTF-8 Unterstützung bei meinem System mir bisher keine Probleme gemacht hat. Beim Emacs, den ich für die meisten Dateien verwende, kann ich das Kodierungssystem für jede Datei einstellen, Default ist ISO-8859-1. Emacs und vi und less richten sich nach der Variable LANG, mehr habe ich jetzt nicht ausprobiert, aber das sind auch die wichtigsten Programme, die mir jetzt einfallen, was die Kodierung betrifft. Beim Emacs kann die Kodierung der Datei von der Kodierung an der Konsole abweichen, bei vi und less habe ich nicht derartiges gefunden, was aber nichts heißen muß.

Ich habe nicht gesagt, daß UTF-8 und ISO-8859 Zeichensätze das gleiche sind. Wenn das so wäre, wäre UTF-8 ja unnötig, und ich finde es gut, daß das System UTF-8 unterstützt, auch wenn ich es selten brauche.

Aber in Shell-Skripten und Programmen wird selten mehr als der ASCII-Zeichensatz verwendet, weil die wenigsten Shells und Compiler Umlaute akzeptieren, weder in UTF-8 noch in ISO-8859.

Für die Box würde ich auch nicht mit UTF-8 anfangen. Allenfalls bei den Webseiten könnte das sinnvoll sein, wenn man mehrere Sprachen unterstützen wollte, und das ist derzeit nicht vorgesehen.

Daher braucht man dafür entweder einen Editor, der ISO-8859 in der Datei unterstützt, unabhängig vom Terminal, oder man stellt das Terminal auf ISO-8859 ein.
 
RalfFriedl schrieb:
Anscheinend hat jemand in einem Skript das Paragrafen-Zeichen '§' für IFS verwendet. Da zumindest in der Anlage aus Beitrag #474 sonst nirgends ein Paragrafen-Zeichen vorkommt und ich auch sonst keinen Sinn darin erkennen kann, an IFS zweimal das gleiche Zeichen zuzuweisen, gehe ich eher davon aus, daß es sich hier um ein Versehen handelt oder um etwas, was von einem Editor ungefragt eingebaut wurde.
Ich bekenne mich schuldig. Ich hatte (auf dei Schnelle, ohne ganau zu lesen) die irrige Annahme, dass nicht jedes Zeichen sondern das "Wort" als Trenner genutzt wird (ich brauchte an der Stelle etwas "garantiert nicht im Sting vorkommendes" als Trennzeichen). Im Resultat ist es egal (das "Â" ist genauso "unwahrscheinlich" wie ein "§") nur die mehrfache Einführung macht nicht wirklich Sinn zumal, (dann soll die Schande auch offenbar werden) ich ja "§*§" genommen hatte, und das "*" ja durchaus möglich wäre. Aber, man ist ja lernfähig...

Jörg

EDIT:
Kann mal jemand folgende Testen:
Auf der Box:

echo "äöüßÄÖÜ" > /tmp/sonderz.txt

und diese Datei auf den PC holen? Das konnte ich (weder auf der Box noch im PC) micht korrekt anzeigen. Die Datei mit gleichem Inhalt im "vi" auf der Box erzeugt war als "ANSI" / ISO 8859-1 korrekt lesbar
 
Zuletzt bearbeitet:
Seht Ihr, genau darum habe ich bei mir umgestellt. ;-)

Was bei Dir passiert sein kann, ist Folgendes: Dein Terminal-Programm - vermutlich von Linux aus gestartet - denkt, auf der Box sei der Zeichensatz auch UTF-8, und wenn Du mit Kopieren & Einfügen oder evtl. auch per Tastatur dort etwas schreibst, werden falsch kodierte Zeichen hinüber gesandt. Ich nehme an, daß eine korrekte Einstellung des Programms helfen könnte (unter Putty ist das einfach, wie oben von jemand anderem erwähnt), aber anstatt eines Problems beim Senden der Daten könnte es im Terminalprogramm auch ein Problem der Anzeige sein. Da muß man sich tatsächlich ein bißchen auskennen, um das sauber hinzukriegen.

Wenn man auf beiden Systemen ISO-8859-1/15 statt UTF-8 hat, besteht das Problem nicht - darum habe ich das so gelöst. Ich wollte einfach aufhören, ständig darüber nachzudenken.

Schreib doch mal, welches Programm Du benutzt, dann kann einer der Linux-Experten Dir vermutlich sagen, wie man das regelt.
 
How-To: Linux von Unicode (UTF-8) auf ISO-8859-15 umstellen

In meinem Postausgang fand ich gerade wieder eine Nachricht, die ich jemandem als Zusammenfassung geschickt habe, nachdem er mir Tips zur Umstellung meines debian-basierenden Linux von Unicode auf ISO gegeben hatte. Ob die Beschreibung auf jedem System funktioniert, weiß ich nicht, es ist das Ergebnis eines Versuch-Und-Irrtum-Marathons. (Auf nicht debian-basierenden Distributionen kann es wohl mangels dpkg-reconfigure nicht gehen, dort gibt es dafür aber bestimmt andere Werkzeuge ähnlicher Art, um Pakete neu zu konfigurieren.)


x[noparse]How-To: Linux von Unicode (UTF-8) auf ISO-8859-15 umstellen[/noparse]

von Alexander Kriegisch, 29.06.2007


Ich fasse nochmals zusammen, was wir gemacht haben, um das zu erreichen. Ob jeder Schritt notwendig ist, weiß ich nicht, aber Folgendes hat zumindest nicht geschadet:

1. Locales einrichten:

Code:
dpkg-reconfigure locales
Dabei folgende Locales auswählen:
  • de_DE@euro ISO-8859-15 (als Default wählen auf Seite 2)
  • de_DE ISO-8859-15
  • de_DE ISO-8859-1
  • de_DE.UTF-8 UTF-8 (optional, evtl. weglassen)
Anschließend sollte die /etc/locale.gen die obigen vier Strings enthalten, andernfalls selbst erzeugen.

2. Bash-Profile pflegen

In die ~/.bashrc von relevanten Benutzern und root Folgendes eintragen:

Code:
# We want to have ISO-8859-15 (Latin 1 with umlauts and Euro character)
export LANG="de_DE@euro"
export LC_CTYPE="de_DE@euro"
export LC_COLLATE="de_DE@euro"
export LC_ALL="de_DE@euro"

3. Tastaturbelegung einstellen

Code:
dpkg-reconfigure console-data
Passende qwertz-Belegung (deutsch) mit latin1-nodeadkeys auswählen

4. Fenstermanager und Terminals neu starten

Alt-Strg-Rücktaste (engl. Alt-Ctrl-Backspace)

5. Test-Sequenz

An der Konsole Text mit Sonderzeichen in eine Datei schreiben, diese in mehreren Text- und GUI-Editoren anzeigen und verändern, zum Schluß nochmals auf der Konsole ausgeben. Besonders mcview, der ungern Unicode anzeigt (zeigt bei "ß" z.B. zwei Stellvertreterzeichen an, was auf 16-Bit-Kodierung hindeutet), ist ein guter Prüfstein.

Code:
echo "Désirée Müllers Baßgitarre tönt schräg" > testfile
mcview testfile
mcedit testfile
vi testfile
nano testfile
scite testfile
cat testfile
Man kann auch iconv verwenden, um die vermeintlich in ISO-8859-15
gespeicherte Test-Datei in UTF-8 und wieder zurück zu wandeln:

Code:
iconv -f ISO8859-15 -t UTF-8 testfile > testfile-utf8
iconv -t ISO8859-15 -f UTF-8 testfile-utf8 > testfile-iso
Wenn nun testfile und testfile-iso gleich groß sind und sich im Diff
nicht unterscheiden, hat es wohl funktioniert:

Code:
$ [B]ls -l testfile*ls -l testfile*[/B]
-rw-r--r-- 1 kriegaex kriegaex 39 2007-06-29 01:26 testfile
-rw-r--r-- 1 kriegaex kriegaex 39 2007-06-29 01:26 testfile-iso
-rw-r--r-- 1 kriegaex kriegaex 45 2007-06-29 01:26 testfile-utf8

$ [B]diff -Nau testfile testfile-iso[/B]
# Ausgabe sollte leer sein
Man kann darüber hinaus noch weitere Kontrollen durchführen. Folgende Befehle und Ausgaben hatte ich noch auf meinem System:

Code:
$ [B]locale[/B]
LANG=de_DE@euro
LC_CTYPE="de_DE@euro"
LC_NUMERIC="de_DE@euro"
LC_TIME="de_DE@euro"
LC_COLLATE="de_DE@euro"
LC_MONETARY="de_DE@euro"
LC_MESSAGES="de_DE@euro"
LC_PAPER="de_DE@euro"
LC_NAME="de_DE@euro"
LC_ADDRESS="de_DE@euro"
LC_TELEPHONE="de_DE@euro"
LC_MEASUREMENT="de_DE@euro"
LC_IDENTIFICATION="de_DE@euro"
LC_ALL=de_DE@euro
Code:
$ [B]locale -a[/B]
C
de_DE
de_DE@euro
de_DE.iso88591
de_DE.iso885915
de_DE.iso885915@euro
deutsch
german
POSIX
Code:
$ [B]cat /etc/locale.gen[/B]
de_DE@euro ISO-8859-15
de_DE ISO-8859-15
de_DE ISO-8859-1
Code:
$ [B]find /etc -type f | xargs grep de_DE > find-de_DE.txt[/B]
/etc/environment:LANG=de_DE@euro
/etc/environment:de_DE
/etc/environment:de_DE
/etc/default/locale:LANG=de_DE@euro
/etc/locale.gen:de_DE@euro ISO-8859-15
/etc/locale.gen:de_DE ISO-8859-15
/etc/locale.gen:de_DE ISO-8859-1
/etc/entrance_lang:LANG=de_DE@euro

6. Sich freuen

Nach Abschluß der Arbeiten haben bei mir alle Terminals (Textkonsolen 1-8 sowie X-Terminals) Umlaute bei Ein- und Ausgabe verstanden und angezeigt und, ebenso wie sämtliche getesteten Editoren und Viewers (mcview, mcedit, vi, nano, SciTE), den gewünschten 8-Bit-Zeichensatz Latin1 ISO-8859-15 verwendet. Dabei war die Tastaturbelegung jeweils wie erwartet, sogar in den Textkonsolen bei Anmeldung waren schon Umlaute verfügbar.
 
MaxMuster schrieb:
Kann mal jemand folgende Testen:
Auf der Box:

echo "äöüßÄÖÜ" > /tmp/sonderz.txt

und diese Datei auf den PC holen?
Putty ist auf UTF-8 eingestellt:
Code:
/var/tmp $ echo "äöüßÄÖÜ" > /tmp/sonderz.txt
/var/tmp $ cat /tmp/sonderz.txt
äöüßÄÖÜ
/var/tmp $ hexdump -c /tmp/sonderz.txt
0000000 303 244 303 266 303 274 303 237 303 204 303 226 303 234  \n
000000f
Putty ist auf ISO-8859-15 eingestellt:
Code:
/var/tmp $ echo "äöüßÄÖÜ" > /tmp/sonderz.txt
/var/tmp $ cat /tmp/sonderz.txt
äöüßÄÖÜ
/var/tmp $ hexdump -c /tmp/sonderz.txt
0000000 344 366 374 337 304 326 334  \n
0000008
Das funktioniert beides, weil die Ausgabe in der gleichen Kodierung wie die Eingabe kommt und daher immer paßt. Die erzeugte Datei ist aber unterschiedlich, wie man am hexdump sieht.

Die zweite Datei, die mit ISO-8859-15 erstellt wurde, kann ich auf den PC übertragen und zum Beispiel im Notepad öffnen, die Umlaute werden richtig angezeigt.

Wenn die Datei am PC nicht richtig angezeigt wird, gibt es einen Unterschied zwischen dem Kodierungssystem im Terminal-Programm und der Kodierung auf dem PC.


Wenn man also Dateien mit Umlauten auf der Box editieren will, sollte das Terminal-Programm also auf ISO-8859 eingestellt sein, da UTF-8 Unterstützung auf der Box nur unnötig Platz wegnehmen würde.
Wenn man diese Dateien auf dem PC erstellt, muß man dafür sorgen, daß die Dateien in ISO-8859 erstellt werden. Dazu kann man entweder das Terminal auf ISO einstellen oder einen Editor nehmen, der die Umwandlung selbst vornimmt.

@kriegaex
Mit Debian kenne ich mich nicht so gut aus, aber ich vermute Folgendes:
1. Hiermit werden die nötigen Locales installiert und ein Default ausgewählt.
2. Wählt ein locale für den Benutzer aus. Idealerweise würde die Auswahl des Defaults aus 1. das schon übernehmen.
3. Damit wird vermutlich der Zeichensatz auf der Konsole eingestellt, also der Text-Bildschirm am Rechner, nicht die grafische Oberfläche. Wenn man die Konsole nicht verwendet, ist diese Einstellung nicht weiter wichtig.
Die weiteren Punkte sind dann nur noch aktivieren und testen der Einstellungen.

Zum Umkodieren kann man auch das Programm recode verwenden. Damit kann man auch eine Datei ohne Ausgabeumlenkung direkt umkodieren:
Code:
recode utf8..latin1 /tmp/sonderz.txt
 
Danke für die Paraphrase. Ich weiß inzwischen, was da passiert, nur bis ich soweit war...
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.