expertenaustausch > linux.debian.user.german

Andre Bischof (13.09.2005, 10:40)
Ulrich Fürst schrieb:
> "André Bischof" <frisco> wrote:
> Sieht nach:
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=297899>
> aus.


Wow, ja, sieht mir auch so aus, danke! Dann ignoriere ich das bis ein
Update von Spamassassin verfügbar ist, da nach dem Spamassassin-Bugzilla
die Spamerkennungsrate davon nicht beeinflußt wird.

Im Bugtracker habe ich aber sowas gefunden:

LANG=es_ES@euro, LC_CTYPE=es_ES@euro (charmap=ISO-8859-15)
(Systemumgebung von jemandem, der zum Bug committed hat)

Ich habe ja nur:
root@linux:~# cat /etc/environment

LANG=de_DE@euro

Sollte ich dort (oder woanders?) evtl. noch weitere Angaben zu LC_CTYPE
und charmap machen? Wie müßten diese Einträge dann aussehen? So?

LC_CTYPE="de_DE@euro"
CHARSET="iso8859-15"

Sind noch weitere Angaben wie

COUNTRY="de"
LANGUAGE="de"

und
LC_COLLATE
LC_MESSAGES
LC_NUMERIC
LC_MONETARY
LC_TIME
LC_ALL
LANGUAGE
LINGUAS
_XKB_CHARSET

sinnvoll?

Viele Grüße
André
Ulrich Fürst (13.09.2005, 10:50)
Andre Bischof <a.bischof> wrote:
> Im Bugtracker habe ich aber sowas gefunden:
> LANG=es_ES@euro, LC_CTYPE=es_ES@euro (charmap=ISO-8859-15)
> (Systemumgebung von jemandem, der zum Bug committed hat)
> Ich habe ja nur:
> root@linux:~# cat /etc/environment
> LANG=de_DE@euro
> Sollte ich dort (oder woanders?) evtl. noch weitere Angaben zu
> LC_CTYPE und charmap machen? Wie müßten diese Einträge dann aussehen?
> So?


Also ich habe da noch folgendes:
$ cat /etc/environment
export LANG=de_DE.UTF-8
export G_FILENAME_ENCODING=UTF-8
# weil sonst der gimp meckert
export KDE_LANG=de_DE.UTF-8
# damit's auch mit allen (möglichst vielen ;-) ) KDE-Anwendungen klappt.

Ulrich

P.S. habe mir da mal folgendes kopiert: (sind jetzt durch c&p 'n paar
Umlaute verschüttet gegangen...

1. $LC_ALL Diese Variable berschreibt alle weiter unten erläuterten.
Deshalb sollte man sie tunlichst ungesetzt lassen, und die anderen
Variablen verwenden.

2. $LC_CTYPE Diese Variable gibt an, welche Zeichen / welcher
Zeichensatz auf dem aktuellen Terminal verwendet werden kann. Wenn diese
Variable nicht korrekt gesetzt ist, geben viele Programme z.B. statt
Umlauten nur Fragezeichen aus. # wenn $LC_CTYPE auf C gesetzt, werden
auf der Konsole keine Umlaute angezeigt, wenn die resstliche Umgebung
UTF-8 ist.

3. $LC_COLLATE Damit kann man die Sortierreihenfolge beeinflussen. Im
Locale de_DE beispielsweise ist gleichwertig zu a zu behandeln.
(ab,b,ac)

4. $LANG Der hier eingestellte Wert wird fr die anderen
LC-Variablen verwendet, sofern nicht diese selbst oder LC_ALL gesetzt
sind. Einige wenige Programme wie man werten diese Variable auch direkt
aus.

5. $LC_TIME Diese Variable gibt an, in welchen Formaten Datum und
Zeit ausgegeben werden sollen.

6. $LC_NUMERIC Gibt an, wie Zahlen, die
keine Geldbeträge sind, formatiert werden sollen. (z.B. '.' oder ',' als
Dezimaltrenner)

7. $LC_MONETARY Das selbe wie vorhin, diesmal
allerdings fr Geldbeträge.

8. $LC_MESSAGES Gibt an, in welcher Sprache
Programme ihre Nachrichten ausgeben sollen. Das hat nichts mit
automatischer Übersetzung o.. zu tun, sondern ein Programm muss fr jede
Sprache die es untersttzen soll, entsprechend vorgesehen sein. Deshalb
werden durch setzen dieser Variable lngst nicht alle Nachrichten in
Deutsch ausgegeben. Teilweise sind die bersetzungen auch nicht sehr
gelungen.
Andreas Kroschel (13.09.2005, 12:10)
* Markus Meyer:

> Ich schreibe E-Mails in Vim auf einer US-Tastatur. Die Sonderzeichen
> kriege ich über die "digraphs" in Vim hin.


Die wichtigsten, wie Umlaute etc. kannst Du auch mit US-Tastatur
unabhängig von vim systemweit haben: Schau Dir mal die Variante "intl"
in /etc/X11/xkb/symbols/us an, da sind viele mit RAlt plus einfachem
Buchstaben zu haben.

Die vim-digraphs bieten allerdings, wie ich das nach dem ersten
Hinschauen überblicke, einen ungleich höheren Umfang an Zeichen, wenn es
wirklich mal exotisch wird und sind erweiterbar; danke für den Tip.

Grüße,
Andreas
Andre Bischof (13.09.2005, 12:50)
Hallo Ulrich,

> Also ich habe da noch folgendes:
> $ cat /etc/environment
> export LANG=de_DE.UTF-8
> export G_FILENAME_ENCODING=UTF-8
> # weil sonst der gimp meckert
> export KDE_LANG=de_DE.UTF-8
> # damit's auch mit allen (möglichst vielen ;-) ) KDE-Anwendungen klappt.


hier wundern mich die export-Anweisungen, sind die hier richtig (s. Bsp.
oben)?

> Ulrich
> P.S. habe mir da mal folgendes kopiert: (sind jetzt durch c&p 'n paar
> Umlaute verschüttet gegangen...
> 1. $LC_ALL ....


Danke, sehr informativ - wo hast du das her?

Viele Grüße
André
Andreas Pakulat (13.09.2005, 14:50)
On 13.09.05 12:44:49, Andre Bischof wrote:
> Hallo Ulrich,
> hier wundern mich die export-Anweisungen, sind die hier richtig (s. Bsp.
> oben)?


Nein, in environment duerfen keine export's vorkommen.

Andreas
Michael Bienia (13.09.2005, 16:00)
On 2005-09-13 00:39:42 +0200, Michael Rex wrote:
> Die einzigen Programme, die ich benutze und die Probleme mit utf-8 haben
> sind zsh und Licq.


Also bei zsh wurde vor kurzem UTF-8 Unterstützung eingebaut. zsh-beta
aus unstable soll das können.


Michael
Michael Rex (13.09.2005, 18:50)
Quoth Markus Schulz:
> hmm, welches Problem hast du denn mit licq? Setze das auch mit UTF8 ein,
> das einzige Problem was mir bekannt ist, das andere deine Umlaute dann
> nicht verstehen, da deren Client das nicht kennt?!? Daher habe ich licq


Das Problem habe ich auch, liegt aber nicht daran, daß die anderen kein UTF8
kennen, sondern irgendwo bei Licq selbst, wie ich nach einigem googlen
herausgefunden habe.

> wieder auf latin9 zurückgestellt (kann man zum Glück im Programm selbst
> wählen).


Hm, mit der Einstellung hab ich auch mal rumgespielt, brachte aber leider
keine Besserung. Muß ich mir wohl nochmal anschauen.

Bye, Michael
Michael Rex (13.09.2005, 19:20)
Quoth Andreas Pakulat:
> On 13.09.05 00:39:42, Michael Rex wrote:
> 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).


Seit wann gehört das offiziell zu KDE? ;-)

> 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...


Schlampig programmierte Software gibt es überall :-/

> 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.


Und bei mir läuft KDE 3.3 ;-). Na gut, ich sag mal: bei den KDE-Programmen,
die ich einsetze, habe ich bisher keine Probleme mit UTF-8 feststellen
können. Das ist mehr, als ich von anderen Programmen sagen kann.

>> 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.


Ja gut, die fallen für mich in dem Zusammenhang halt auch unter Window
Manager / Desktop Environment. Rein aus der Benutzersicht sieht man das
Toolkit ja nicht, bzw. nimmt es nicht als eigenständigen Teil wahr. KDE =
Qt, Gnome = GTK, Windowmaker = ... ähm, naja, was auch immer die einsetzen.

> 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.


Da liegt das Problem dann aber nicht bei KMail. Der MUA soll ja nicht raten,
was für ein Encoding benutzt wird, sondern das im Header angegebene
verwenden. Ist also IMHO kein UTF8-Problem, sondern eher ein Problem mit
kaputter Software.

> 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.


ACK.

>> 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.


Ja, aber Linux muß sich ja nicht unbedingt an Windows messen lassen ;-)

Bye, Michael
Andreas Pakulat (13.09.2005, 20:10)
On 13.09.05 18:55:26, Michael Rex wrote:
> Quoth Andreas Pakulat:
> > On 13.09.05 00:39:42, Michael Rex wrote:
> > 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...

> Schlampig programmierte Software gibt es überall :-/


Wobei da aber das Problem ist: Wenn bei einer Datei nicht angegeben ist,
welches Encoding benutzt wird, _muss_ dass Programm irgendeine Annahme
machen. Denn wie schon gesagt, aus dem Inhalt kann man leider nicht aufs
Encoding schliessen.

> > 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.

> Und bei mir läuft KDE 3.3 ;-). Na gut, ich sag mal: bei den KDE-Programmen,
> die ich einsetze, habe ich bisher keine Probleme mit UTF-8 feststellen
> können. Das ist mehr, als ich von anderen Programmen sagen kann.


Naja, kopete hatte das letzte Mal auch noch Probleme beim ICQ - aber das
ist schon ne Weile her...

> Da liegt das Problem dann aber nicht bei KMail. Der MUA soll ja nicht raten,
> was für ein Encoding benutzt wird, sondern das im Header angegebene
> verwenden. Ist also IMHO kein UTF8-Problem, sondern eher ein Problem mit
> kaputter Software.


Ja, nur hast du das Problem bei einer Latin1/9 Umgebung nicht, weil das
dann "automagisch" korrekt angezeigt wird. Aber natuerlich gehoeren
diese kaputten Programme gefixt...

Andreas
Ulrich Fürst (13.09.2005, 23:10)
Andreas Pakulat <apaku> wrote:
> On 13.09.05 12:44:49, Andre Bischof wrote:
> Nein, in environment duerfen keine export's vorkommen.


Gewirkt haben die Einträge aber. Ohne den G_FILENAME_ENCODING geht gimp
nicht und mit aber schon (trotz export)!?

Ulrich
Ulrich Fürst (13.09.2005, 23:10)
Andreas Pakulat <apaku> wrote:
> Nein, in environment duerfen keine export's vorkommen.


Danke, dann werd ich die da jetzt mal löschen...
Mal sehen was sich da dann noch so alles ändert (oder Probleme in Luft
auflösen bzw. neue entstehen *gespanntbin*)

Ulrich
Andreas Hemel (13.09.2005, 23:50)
On Tue, Sep 13, 2005 at 06:15:56PM +0200, Michael Rex wrote:
> Quoth Markus Schulz:
> Das Problem habe ich auch, liegt aber nicht daran, daß die anderen kein UTF8
> kennen, sondern irgendwo bei Licq selbst, wie ich nach einigem googlen
> herausgefunden habe.
> Hm, mit der Einstellung hab ich auch mal rumgespielt, brachte aber leider
> keine Besserung. Muß ich mir wohl nochmal anschauen.


Das ging mir genauso, bis mir aufgefallen ist, dass es nicht nur die
Einstellung in den Optionen gibt, die hatte ich auch immer umgestellt
ohne eine Veränderung zu bemerken.

Es gibt aber in dem Fenster in dem man die Nachrichten schreibt oben
rechts noch einen Button, mit dem man den Zeichensatz ändern kann. Als
ich den auf "Western European" umgestellt hab, kamen die Umlaute in
beide Richtungen wieder korrekt an.

Andreas
Markus Schulz (14.09.2005, 11:10)
On Tuesday 13 September 2005 18:15, Michael Rex wrote:
> Quoth Markus Schulz:
> Das Problem habe ich auch, liegt aber nicht daran, daß die anderen
> kein UTF8 kennen, sondern irgendwo bei Licq selbst, wie ich nach
> einigem googlen herausgefunden habe.


beziehst du dich dabei auf Fehler #203346 ?
Weil licq kann ja nicht dafür verantwortlich gemacht werden wenn der
Windows Client gegenüber die UTF8 Umlaute nicht versteht. Und genau das
Problem hatte _ich_.
Allerdings ist mir jetzt auch aufgefallen, das wenn ich Umlaute von
Windows Usern bekomme diese nicht ordentlich nach UTF8 konvertiert
werden (das ist in dem Fehler #203346 auch gemeint) wie es eigentlich
passieren müßte. Der Weg hin zum Windows Client sollte doch kein licq
Problem sein oder ist im icq Protokoll eine locale fest vorgeschrieben?

> > wieder auf latin9 zurückgestellt (kann man zum Glück im Programm
> > selbst wählen).

> Hm, mit der Einstellung hab ich auch mal rumgespielt, brachte aber
> leider keine Besserung. Muß ich mir wohl nochmal anschauen.


also das funktioniert bei mir wunderbar. Hab seitdem trotz UTF8 Umgebung
keine fehlerhaften Umlaute mehr in licq.

An anderen Stellen in KDE dagegen schon (z.B. im krusader wenn man
mehrere Dateien auf einmal löschen will hat die MsgBox mit der Abfrage
ein Umlautproblem)

Markus Schulz
Andreas Pakulat (14.09.2005, 18:10)
On 13.09.05 23:03:37, Ulrich Fürst wrote:
> Andreas Pakulat <apaku> wrote:
> Gewirkt haben die Einträge aber. Ohne den G_FILENAME_ENCODING geht gimp
> nicht und mit aber schon (trotz export)!?


Dann macht irgendeine deiner bash-configs ungefaehr das hier:

.. /etc/environment

Was aber nicht so sein sollte. /etc/environment wird von einem PAM-Modul
beim anmelden geladen und dabei darf sie keine exports enthalten,
sondern nur eine Liste von Variablen denen Werte zugewiesen werden.

Andreas
Ulrich Fürst (14.09.2005, 22:50)
Andreas Pakulat <apaku> wrote:
> On 13.09.05 23:03:37, Ulrich Fürst wrote:
> > Gewirkt haben die Einträge aber. Ohne den G_FILENAME_ENCODING geht
> > gimp nicht und mit aber schon (trotz export)!?


Ohne das export tut's aber genauso.

> Dann macht irgendeine deiner bash-configs ungefaehr das hier:
> . /etc/environment


Hab aber nichts gefunden:
# egrep -RH "/etc/environment" /etc/*
/etc/init.d/console-screen.sh:
/etc/init.d/keymap.sh:
/etc/pam.d/login:
/etc/pam.d/ssh:
/etc/rcS.d/S05keymap.sh:
/etc/rcS.d/S48console-screen.sh:
(Ausgabe nach dem Doppelpunkt jeweils gekürzt). Da ist nichts
auffälliges dieser Art.

# egrep -RH "\. /etc/environment" /etc/*
liefert gar nichts und ich gehe davon aus, das ich den Punkt escapen
muss? Ohne kommt nähmlich das gleiche wie beim ersten Befehl ;-)

Kann es sein das er das export als Variable sieht, sprich auch zwei
Variablen in einer Zeile gehen und dann halt in irgendeinem Log eine
unauffällige Fehlermeldung steht?
Wohin logt den pam?

Ulrich

Ähnliche Themen