[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: auf UTF-8 umsteigen, Folgen?



On 060712 at 10:40, Andreas Pakulat wrote:
> On 12.07.06 02:02:15, Steffen Schulz wrote:
> > [pepe@goofy ~]$ echo $TERM, $LANG
> > rxvt-unicode, en_US.utf8
> 
> Ich mag mich da jetzt irren, aber en_US.utf8 ist keine korrekte locale,
> denke ich. Richtig ist en_US.UTF-8, schau mal in deine /etc/locale.gen.

/etc/locales.build, hier ist gerade gentoo. Hm. Stimmt, es heisst
UTF-8, aber das erzeugt hier noch immer das gleiche Problem. (bashrc
angepasst und komplett ausgeloggt, ohne kdm/gdm/whatever sondern
startx)

> > [pepe@goofy ~]$ touch tür
> > [pepe@goofy ~]$ ls tür
> > tür
> 
> Da waere mal interesant wie es mit einem Hexeditor aussieht, also
> 
> ls tür >datei; hexedit datei
> 
> Da sollten dann 4 Bytes drin stehen (alternativ auch ls -l datei)

Na hoffentlich nicht, das war nur ein touch :)

mit LC_ALL=en_US.UTF-8:

[pepe@goofy ~]$ echo tür > tür
[pepe@goofy ~]$ hexdump -C tür
00000000  74 c3 bc 72 0a                                    |t..r.|
00000005

Sieht fuer mich okay aus. Und wenn ich, wie in der anderen Mail zu
lesen, nun auch mal LC_* beachte und das auf latin1 stelle und dann nen
xterm oder urxvt starte, kann ich da 2 Sonderzeichen statt dem ü sehen.

ohne unicode:

[pepe@goofy ~]$ export LC_ALL=en_US
[pepe@goofy ~]$ xterm
->
  [pepe@goofy ~]$ export LC_ALL=en_US
  [pepe@goofy ~]$ echo tür > test
  [pepe@goofy ~]$ ls -l test
  -rw-r--r-- 1 pepe pepe 4 2006-07-12 11:14 test
  [pepe@goofy ~]$ hexdump -C test 
  00000000  74 fc 72 0a                                       |tür.|
  00000004


Sieht fuer mich korrekt aus.

> > -> touch tür;ls tür; rm tür; geht in dem terminal ebenso. Allerdings
> > faellt auf, dass das terminal irgendwie der Meinung ist, ein Zeichen
> > anzuzeigen(ü) und 2 zeichen zu editieren, xterm das selbe. :-/
> 
> Ja, weil das Terminal denkt es benutzt eine UTF-8 locale, du aber in
> Wirklichkeit eine latin1-Kodierung nutzt.

Ajo, Weil innerhalb des neuen term wieder auf utf gesetzt wird. Wenn
man dort auch nochmal LC_ALL=en_US macht, wie oben geschehen, tritt das
nicht auf.


> > -> touch tür; exit
> > 
> > [pepe@goofy ~]$ rm tür
> > rm: cannot remove `tür': No such file or directory
> > [pepe@goofy ~]$ ls tür
> > ls: tür: No such file or directory
> > [pepe@goofy ~]$ ls t?r
> > tür
> 
> Das Terminal ist aber noch im UTF-8 Modus.

Ja, darum gehts ja. Wenn ich normal in utf-8 arbeite und jmd mit
latin1/9 ne Datei mit zB Umlauten erstellt, wie ich es oben gemacht
habe, dann kann ich diese Datei im UTF-8-term zwar "zufaellig" korrekt
anzeigen, aber meine Umlaute unterscheiden in der Codierung von denen
in der Datei, daher funktioniert zB "rm tür" dann nicht.

Das bedeutet um auf utf8 zu wechseln muessen die Dateinamen und Inhalte
ggf. umkodiert werden. Und wenn mir spaeter einer ne Datei unterschiebt,
die mit latin1/9 erstellt wurde, bekomm ich ggf Probleme, deren
Dateinamen einzugeben, weil meine Umlaute 2 Byte lang sind, die im
Dateinamen nur ein Byte...(und auch nen anderes codewort haben..)

> > http://de.gentoo-wiki.com/Utf8#Dateinamen
> 
> Ich hab doch gesagt, die Howtos sind veraltet und das gilt fuer fast
> alle UTF-8 Howtos. Glaub mir einfach wenn ich dir sage xterm erkennt ob
> es aus einer UTF-8 oder non-UTF-8 locale heraus gestartet wird.

Jo, tut es auch oben. Und die aktuelle Einstellung innerhalb der
dortigen Shell ist auch wichtig, um diesen Fehler zu beheben, dass sich
das Terminal nicht sicher ist, ob das Zeichen nun 1 oder 2 Byte lang
ist.



mfg
pepe
-- 
Zeit ist das, was man an der Uhr abliest.	-- Albert Einstein



Reply to: