Re: auf UTF-8 umsteigen, Folgen?
Hi! Am Wed, 12 Jul 2006 10:48:30 +0200 schrieb Jochen Schulz [EMAIL PROTECTED]: (wenn es das Ziel-System kann) oder du stellst dein Terminal passend ein. Im gnome-terminal z.B. kannst du den Zeichensatz einstellen. Nutze ich wenn ich mich zu Rechnern verbinde, die noch keine UTF-8 Locales haben. Werd mal schauen, ob xcfe4-terminal das auch kann. Oder ich versuche, das mit screen zu lösen. Ich nutze dafür: xfterm4 +u8 -bg black -fg white -cr white LG, Ace -- () ASCII Ribbon Campaign - against HTML mail /\- against Microsoft attachments http://www.efn.no/html-bad.html http://www.goldmark.org/netrants/no-word/attach.html signature.asc Description: PGP signature
Re: auf UTF-8 umsteigen, Folgen?
Hallo Ulrich, Ulrich Fürst [EMAIL PROTECTED] wrote: cat /etc/environment # Fuer Gimp export G_FILENAME_ENCODING=UTF-8 /etc/environment ist kein Shellskript! Die Datei wird von einem PAM-Modul verarbeitet, dass nur die Syntax Variable=Wert kennt. Schöne Grüße, Jörg. -- Definiere Demokratie... ... eine Mehrheit beweist einer Minderheit, dass Widerstand zwecklos ist. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
Andreas Pakulat wrote: On 11.07.06 22:34:27, Ulrich Fürst wrote: Andreas Pakulat [EMAIL PROTECTED] wrote: On 11.07.06 19:22:03, Ulrich Fürst wrote: Manche Programme benötigen extra Optionen. Mein Gimp braucht z. B. cat /etc/environment # Fuer Gimp export G_FILENAME_ENCODING=UTF-8 Komisch, hier brauchts das nicht. Aber s.o. ich fahre auch unstable, moeglich das der schon etwas besser ist als der aus Sarge. Gimp startete nicht mehr und meldete, dass er diese Variable gesetzt haben möchte. Wie gesagt, kann ich nicht nachvollziehen. Hab auch keine Probleme damit, aber ich vermeide auch non-ASCII in Filenamen. Hab jetzt extra probiert, ein jpg in testäöü.jpg umzubenennen - öffnet problemlos in GIMP. Helmut Wollmersdorfer -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
On Wed, Jul 12, 2006 at 02:02:15AM +0200, Steffen Schulz wrote: [EMAIL PROTECTED] ~]$ echo $TERM, $LANG rxvt-unicode, en_US.utf8 Warum LANG=en_US.utf8 und nicht LC_CTYPE=de_DE.UTF-8 ohne LANG? -- Nicht Absicht unterstellen, wenn auch Dummheit ausreicht! pgpa2lNI7iSub.pgp Description: PGP signature
Re: auf UTF-8 umsteigen, Folgen?
On 12.07.06 02:02:15, Steffen Schulz wrote: On 060711 at 21:20, Andreas Pakulat wrote: Ein Problem stellen auch zB Dateinamen dar. Die sind ja auch irgendwie kodiert, verfuegbare Codings sind im Kernel zu konfigurieren. Also damit habe ich eigentlich auch keinerlei Probleme. Wenn ein User mit de_DE locale eine Datei mit Umlauten auf einem *nix-Dateisystem ablegt kann ich die auch korrekt in UTF-8 locale sehen. Hm. Ich hoffe mein ü kommt korrekt an, sonst wird das jetzt etwas wirr: Ja, passt schon. [EMAIL PROTECTED] ~]$ 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. [EMAIL PROTECTED] ~]$ touch tür [EMAIL PROTECTED] ~]$ 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) [EMAIL PROTECTED] ~]$ rm tür [EMAIL PROTECTED] ~]$ export LANG=en_US [EMAIL PROTECTED] ~]$ urxvt - 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. - touch tür; exit [EMAIL PROTECTED] ~]$ rm tür rm: cannot remove `tür': No such file or directory [EMAIL PROTECTED] ~]$ ls tür ls: tür: No such file or directory [EMAIL PROTECTED] ~]$ ls t?r tür Das Terminal ist aber noch im UTF-8 Modus. So wie du das machst kann ich das auch nachvollziehen, wobei konsole mir bei einem ls dann nur tr ausgibt. Wenn ich aber dann konsole sage dass die Locale auf latin1 geaendert wurde, wird bei ls wieder alles korrekt dargestellt. Und ich kanns mit rm tür auch loeschen. Kurz: Die Kodierung im Dateisystem ist immer diesselbe, nur die Anzeige durchs Terminal ist u.U. kaputt. Nachdem convmv den Dateinamen von 8859-1 nach utf-8 convertiert hat, kann ich den Dateinamen korrekt eintippen. Vorher hats dann auf Dateisystemebene nicht gepasst, weil die ü unterschiedlich kodiert werden. Hier irrst du dich. Auf Dateisystemebene ist alles korrekt gewesen, nur dein Terminal wusste nicht dass es das High-Byte nicht als erstes von 2 UTF-8 Bytes interpretieren muss. Nerviges Problem ist, dass man fuer unicode modifizierte terminals benutzt, die dann auch anders heissen. z.B. rxvt-unicode oder uxterm. Bloedsinn, deine Howtos sind hoffnungslos veraltet. Solange LANG korrekt gesetzt ist, funktionieren xterm, gnome-terminal, konsole und xfce4-terminal wunderbar. Ich vermute aber das bei dir einfach LANG falsch gesetzt ist. Nun, als ich damals die entsprechenden terminals probiert habe, wurde halt auf die unicode-varianten verwiesen. Das is nu mind. nen Jahr her, okay...aber meine Howtos erzaehlen noch immer was von Dateinamen: 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. Oh, und rate was ich eben in der muttrc fand... set send_charset=UTF-8:ISO-8859-15:ISO-8859-1 Da ist wohl was schiefgelaufen.. ^^ Ja, genau falschherum. Andreas -- Someone whom you reject today, will reject you tomorrow. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
Michael Bienia: On 2006-07-11 22:45:07 +0200, Jochen Schulz wrote: Ich habe aufgrund des kürzlich erwähnten Datenverlustes den Etch-Installer ausprobiert (mit GUI!!elf) und der stellt ja automatisch UTF-8 ein. Ich hatte aber dann das Problem, dass eine SSH-Session auf ein ISO-8859-1-System furchtbar kaputt aussah. Ich vermute auch, dass mein mutt auf ebendiesem System falsch kodierte Mails rausgeschickt hat (UTF-8 als ISO-8859-1), wenn ich die per SSH vom UTF-System geschrieben habe. Muß ich da irgendwas machen, damit ich keine Probleme kriege? Liegt das am Terminal, oder hätte ich screen (in dem mutt läuft) neu starten müssen? Das liegt daran, dass dein Terminal noch im UTF-8 Modus war, die Gegenseite jedoch in ISO-8859-1 (siehe locale auf dem Zielrechner): dein Terminal hat UTF-8 geschickt und die Gegenseite hat es als ISO-8859-1 intepretiert = kaputte Umlaute (in beide Richtungen). Klingt logisch, danke. Entweder sagst du dem Zielsystem, dass du eine UTF-8 Locale nutzt (wenn es das Ziel-System kann) oder du stellst dein Terminal passend ein. Im gnome-terminal z.B. kannst du den Zeichensatz einstellen. Nutze ich wenn ich mich zu Rechnern verbinde, die noch keine UTF-8 Locales haben. Werd mal schauen, ob xcfe4-terminal das auch kann. Oder ich versuche, das mit screen zu lösen. J. -- In an ideal world I would cure poverty and go to the gym at least three days a week. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: auf UTF-8 umsteigen, Folgen?
On 060712 at 10:10, Martin Reising wrote: On Wed, Jul 12, 2006 at 02:02:15AM +0200, Steffen Schulz wrote: [EMAIL PROTECTED] ~]$ echo $TERM, $LANG rxvt-unicode, en_US.utf8 Warum LANG=en_US.utf8 und nicht LC_CTYPE=de_DE.UTF-8 ohne LANG? Aehm...weil bei mir alles en_US ist und sein soll? Aber stimmt, die LC-Variablen hab ich bei dem Experiment uebersehen. Wenn ich LC_ALL statt LANG benutze(LC_ALL hat Prioritaet) und Erwaehntes ausprobiere, tritt der Fehler in dem nicht-unicode-terminal nicht mehr auf. Also dass er irgendwie nen 2byte-Zeichen zu editieren versucht und nen einzelnes ü anzeigt. Dafuer kann man jetzt dort den Unicode-Dateinamen nicht mehr lesen. Man sieht die 2 byte Sondermuell statt dem Umlaut. Wenn man im nicht-unicode-term die datei tür nochmal erstellt und sich das im unicode-term anschaut, hat man dort 2 dateinamen, die gleich aussehen. Wenn man rm tür eintippt, kann man nur einen davon loeschen, naemlich halt den unicode-namen. Es sind halt doch verschiedene Codings. Die selben eingetippten Zeichen resultieren auf FS-Ebene in verschiedene Bitstrings und wenn man den unicode-umlaut nach latin1 ausgibt gibts dann halt Muell. mfg pepe -- Hi, I'm a unix-virus. Please copy me into your .signature to help me spread! signature.asc Description: Digital signature
Re: auf UTF-8 umsteigen, Folgen?
Steffen Schulz: On 060711 at 23:10, Jochen Schulz wrote: UTF-8 ein. Ich hatte aber dann das Problem, dass eine SSH-Session auf ein ISO-8859-1-System furchtbar kaputt aussah. Ich vermute auch, dass mein mutt auf ebendiesem System falsch kodierte Mails rausgeschickt hat (UTF-8 als ISO-8859-1), wenn ich die per SSH vom UTF-System geschrieben habe. Muß ich da irgendwas machen, damit ich keine Probleme kriege? Liegt das am Terminal, oder hätte ich screen (in dem mutt läuft) neu starten müssen? Ich benutz zwar kein Screen, aber der setzt im Gegensatz zu SSH meines Wissens die Kodierungen um. Dh. den haettest du wohl mindestens mal neustarten oder ihm das anders beibringen muessen, weil der Input fuer Screen nun utf8-codiert ist.. Hm. Es gibt screen -U: -U Run screen in UTF-8 mode. This option tells screen that your terminal sends and understands UTF-8 encoded characters. It also sets the default encoding for new windows to `utf8'. Stelle ich mein lokales PuTTY auf UTF-8 ein und mache auf dem Zielrechner ein neues screen mit -U auf, werden Umlaute zB in mutt als die berühmten Kästchen dargestellt. In der Shell selbst kann ich aber welche eingeben. In vim geht das wiederum gar nicht, da kommen zwar Umlaute raus, aber immer gefolgt von einem Leerzeichen oder Murks. J. -- Nothing is as I planned it. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: auf UTF-8 umsteigen, Folgen?
On 060712 at 10:40, Andreas Pakulat wrote:
On 12.07.06 02:02:15, Steffen Schulz wrote:
[EMAIL PROTECTED] ~]$ 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)
[EMAIL PROTECTED] ~]$ touch tür
[EMAIL PROTECTED] ~]$ 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:
[EMAIL PROTECTED] ~]$ echo tür tür
[EMAIL PROTECTED] ~]$ hexdump -C tür
74 c3 bc 72 0a|t..r.|
0005
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:
[EMAIL PROTECTED] ~]$ export LC_ALL=en_US
[EMAIL PROTECTED] ~]$ xterm
-
[EMAIL PROTECTED] ~]$ export LC_ALL=en_US
[EMAIL PROTECTED] ~]$ echo tür test
[EMAIL PROTECTED] ~]$ ls -l test
-rw-r--r-- 1 pepe pepe 4 2006-07-12 11:14 test
[EMAIL PROTECTED] ~]$ hexdump -C test
74 fc 72 0a |tür.|
0004
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
[EMAIL PROTECTED] ~]$ rm tür
rm: cannot remove `tür': No such file or directory
[EMAIL PROTECTED] ~]$ ls tür
ls: tür: No such file or directory
[EMAIL PROTECTED] ~]$ 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
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
Andreas Pakulat: On 11.07.06 22:45:07, Jochen Schulz wrote: Ich habe aufgrund des kürzlich erwähnten Datenverlustes den Etch-Installer ausprobiert (mit GUI!!elf) und der stellt ja automatisch UTF-8 ein. Achja? Ich war bisher der Meinung dass er dpkg-reconfigure locales ausfuehrt und du dann waehlen kannst. Aber ich hab auch noch nie Etch installiert... IIRC war da nur am Anfang das Menü mit der Auswahl von Sprache und Keyboard-Layout. Ich habe Englisch mit deutschem Layout gewählt und bekam en_US.UTF8. Ist aber natürlich im Nachhinein leicht umzustellen. Ich hatte aber dann das Problem, dass eine SSH-Session auf ein ISO-8859-1-System furchtbar kaputt aussah. Kannst du das etwas genauer beschreiben? IIRC sah es nach UTF8 als ISO interpretiert aus. Umlaute oder Ähnliches wurden als zwei merkwürdige Zeichen dargestellt. Ich kann das grade nicht wiederholen, weil mein Notebook noch in Holland ist (und ich momentan an einem Windows sitze). Ich vermute auch, dass mein mutt auf ebendiesem System falsch kodierte Mails rausgeschickt hat (UTF-8 als ISO-8859-1), Deine Mail auf die ich geantwortet habe war UTF-8 deklariert und soweit ich das gesehen habe auch genauso kodiert. Nur das das eben nicht unbedingt immer sinnvoll ist, insbesondere wenn man mit Leuten kommuniziert die kaputte Mailclients oder Webmailer benutzen. Hm? Wo genau war die Deklaration? Ich sehe hier nur MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary=+SfteS7bOf3dGlBC Content-Disposition: inline Kann sein, dass GnuPG irgendwas umkodiert. Eine unsignierte Mail sieht bei mir so aus: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Die gpg manpage ist nicht so furchtbar aufschlussreich, was das angeht. Some strings werden nach UTF-8 konvertiert. Die Signatur kanns aber eigentlich nicht sein, die ist ja US-ASCII. Vielleicht passiert das auf Deiner Seite? wenn ich die per SSH vom UTF-System geschrieben habe. Muß ich da irgendwas machen, damit ich keine Probleme kriege? Liegt das am Terminal, oder hätte ich screen (in dem mutt läuft) neu starten müssen? Aenderungen an Umgebungsvariablen werden erst nach einem Re-Login erkannt. Ich habe ja keine Variablen geändert. Ich möchte nur eine Terminalsession von einem UTF-System auf ein ISO-System. :) (Hintergrund: auf dem ISO-System laufen Anwendungen, die immer noch kein UTF-8 können. Slrn zum Bleistift. Sonst würde ich alles umstellen.) Ich hab grad mal getestet: Eine mit vim erzeugte Datei auf dem Server (auf dem LANG=de_DE) kriegt als Kodierung trotzdem UTF-8 (auf dem Client ist LANG=de_DE.UTF-8). Eine in mutt verfasste Mail (mit vim als Editor) wird in Latin1 kodiert und verschickt. Klingt merkwürdig. Aber das wird daran liegen, dass mutt nochmal rekodiert. Ist ja auch vernünftig. Ansonsten werden Meldungen von Programmen wohl auch in Latin1 ausgegeben, ssh scheint das hier nicht korrekt zu konvertieren (also sehe ich Rauten statt Umlaute und es fehlt das nachfolgende Zeichen). Ich weiß auch nicht, ob das die Aufgabe von ssh, dem Terminal, screen oder sonstwem ist. Zeichensätze und Kodierungen sollen bitte einfach funktionieren. :) J. -- When standing at the top of beachy head I find the rocks below very attractive. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: auf UTF-8 umsteigen, Folgen?
Hi, Andreas Pakulat wrote: On 11.07.06 20:49:08, Kai Hildebrandt wrote: Wundere dich aber nach dem Umstieg nicht, dass alles (was mit Codierung zu tun hat) etwas langsamer wird. Du meinst in TB? Wieso dass denn? Hast du Zahlen dazu? die Performance kann leiden, wenn man UTF-8-Zeichenketten intern auch als UTF-8 speichert. Da UTF-8 ja eine Kodierung variabler Zeichenlänge ist, ist dann beispielsweise ein simples substr()/splice() (ab Zeichen #n m Zeichen extrahieren) O(n+...), da die Zeichenkette von Beginn an durchsucht werden muss. (IIRC) Auch ist bei bekannter Anzahl von Bytes die Längenbestimmung in Zeichen nicht O(1). Kodiert man aber UTF-8 intern nach UCS-4, so entfallen die Probleme -- substr() ist wieder O(1+...), und auch die Längenbestimmung bei bekannter Anzahl von Bytes ist wieder O(1). (Nachteil natürlich: Alle Zeichen benötigen bei UCS-4 vier Bytes; Kompromiss: Man kodiert zu UCS-2 und rekodiert nach UCS-4, wenn man ein Zeichen findet, dass in UCS-2 vier Bytes benötigen würde.) Zusätzlich muss man noch betrachten, dass Thunderbird -- als Mail-Client -- die meiste Zeit sowieso a) idle oder b) im IO hängt. Der ganze Kodierungskram ist also nahezu vollständig vernachlässigbar, IMHO. Insofern teile ich deinen Skeptizismus vollkommen. :) --Ingo -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
Ingo Blechschmidt wrote: die Performance kann leiden, wenn man UTF-8-Zeichenketten intern auch als UTF-8 speichert. Der Effekt ist aber z.B. bei Perl minimal (~27% bei REGEX). Kodiert man aber UTF-8 intern nach UCS-4, so entfallen die Probleme -- AFAIK tun das eh einige Programmiersprachen. Helmut Wollmersdorfer -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
Helmut Wollmersdorfer [EMAIL PROTECTED] wrote: Hab auch keine Probleme damit, aber ich vermeide auch non-ASCII in Filenamen. Hab jetzt extra probiert, ein jpg in testäöü.jpg umzubenennen - öffnet problemlos in GIMP. Das ist auch nicht das Problem. Gimp startete auch nicht ohne Datei, bevor ich die zusätzliche Variable definierte. Ich werd' mal meine Hacks herausnehmen (hoffentlich finde ich noch alle) und dann in neuem Thread berichten. Ulrich
Re: auf UTF-8 umsteigen, Folgen?
Hi, Helmut Wollmersdorfer wrote: die Performance kann leiden, wenn man UTF-8-Zeichenketten intern auch als UTF-8 speichert. Der Effekt ist aber z.B. bei Perl minimal (~27% bei REGEX). jep (unter der Annahme, dass du Perl = 5.8 meinst). (Und die Unicode-Unterstützung in Perl 5.9 soll IIRC auch noch mal einiges bringen.) Kodiert man aber UTF-8 intern nach UCS-4, so entfallen die Probleme -- AFAIK tun das eh einige Programmiersprachen. Richtig. :) (So beispielsweise auch bei Parrot (http://www.parrotcode.org/), der designierten virtuellen Maschine für Perl 6 und viele andere Sprachen.) --Ingo -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
Ingo Blechschmidt wrote: jep (unter der Annahme, dass du Perl = 5.8 meinst). perldoc perlhist [...] 5.8.0 2002-Jul-18 Wir schreiben das Jahr 2006;-) Helmut Wollmersdorfer -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
Hi, Helmut Wollmersdorfer wrote: Ingo Blechschmidt wrote: jep (unter der Annahme, dass du Perl = 5.8 meinst). perldoc perlhist [...] 5.8.0 2002-Jul-18 Wir schreiben das Jahr 2006;-) ...und jetzt sag' das nochmal in einer Debian-Liste ;) (Woody hat 5.6.1. Viele gratis Webhoster haben *mutmaß* wahrscheinlich auch noch -- wenn überhaupt -- ein altes Perl...) (SCRN) --Ingo -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
On 12.07.06 11:31:53, Steffen Schulz wrote: - touch tür; exit [EMAIL PROTECTED] ~]$ rm tür rm: cannot remove `tür': No such file or directory [EMAIL PROTECTED] ~]$ ls tür ls: tür: No such file or directory [EMAIL PROTECTED] ~]$ 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. Falsch. Ich hab also grad mal ein xterm aus einer Latin1-Locale gestartet, ein vi /tmp/testäf gemacht, ein paar Zeichen, u.a. Umlaute, eingegeben, abgespeichert und Xterm beendet. Die Datei enthält Latin1-Kodierten Text. Jetzt wieder als ich selbst in einer UTF-8 Umgebung mit konsole: [EMAIL PROTECTED]:~/tempsudo chown andreas /tmp/testäf [EMAIL PROTECTED]:~/temprm -i /tmp/testäf rm: reguläre Datei »/tmp/testäf« entfernen? y [EMAIL PROTECTED]:~/templs -l /tmp/test* ls: /tmp/test*: Datei oder Verzeichnis nicht gefunden Und ich habe testäf so eingegeben, keine Komplettierung benutzt. Das ganze natuerlich auf einem *nix-FS (ext3 in dem Fall). Wenn genau dies bei dir nicht funktioniert (wichtig ist, ein sauberes Terminal aus einer Shell mit Latin1-locale zu starten), wuerde ich darauf tippen wollen, das es evtl. an dem en_US liegt - ich habe hier de_DE... 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..) Das Problem bekommst du nur, wenn du die Dateien von einem Dateisystem das falsch gemountet wurde runterziehst (sie also beim ls -l schon falsch angezeigt werden). Andreas -- Everything will be just tickety-boo today. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
Hi. Andreas Pakulat wrote: Falls du Ordner mit Umlauten verwendest, werden diese falsch angezeigt. In TB? Dann ist das ein Bug in TB. Nein, eigentlich in KMail in Verbindung mit IMAP-Konten. Ich denke, dass es bei TB aber ähnlich sein wird. Wundere dich aber nach dem Umstieg nicht, dass alles (was mit Codierung zu tun hat) etwas langsamer wird. Du meinst in TB? Wieso dass denn? Hast du Zahlen dazu? Nein, ich meinte allgemein. Zahlen habe ich nicht, aber seit ich meine beiden Rechner wieder auf [EMAIL PROTECTED] umgestellt habe, sind sie fühlbar schneller geworden. Gruß Kai -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
auf UTF-8 umsteigen, Folgen?
Hallo, ich bekomme in der nächsten Zeit einen neuen Computer und überlege auf den Zeichensatz UTF-8 umzusteigen. Nun habe ich aber von meinem alten System tausende Dateien die mit normalen ISO-8859-15 codiert sind. Was hat es jetzt für Folgen, wenn ich meine Dateien auf den neuen Rechner kopiere? Was muss man beachten? Was passiert beispielsweise mit meinen Mails in meinem Thunderbirdkonto? Vielen Dank für Antworten, Peter -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
Peter Jordan [EMAIL PROTECTED] wrote: Nun habe ich aber von meinem alten System tausende Dateien die mit normalen ISO-8859-15 codiert sind. Wenn Du in Text-Dateien Umlaute hast musst Du die umändern (lassen). Für die Config-Dateien sollte das kein Problem darstellen, weil ja eigentlich alles auf englisch ist und somit keine Umlaute enthalten. Zumindest habe ich bei mir da keine Probleme festgestellt (mit evtl. vorkommenden anderen Sonderzeichen). Je nachdem was Du so installiert hast können natürlich noch Probleme auftreten. KDE interressiert sich z. B. weder für die .bashrc noch für .profile etc. Manche Programme benötigen extra Optionen. Mein Gimp braucht z. B. cat /etc/environment # Fuer Gimp export G_FILENAME_ENCODING=UTF-8 [...] Es gibt zumindest in sarge auch Programme, die gar nicht mit UTF-8 können. Der dort enthaltene Sylpheed-Claws MUA bleistiftsweise. Was passiert beispielsweise mit meinen Mails in meinem Thunderbirdkonto? Die Mails haben ja den Zeichensatz der verwendet wurde im Header stehen (sollte zumindest so sein). Das dürfte also kein Problem sein. Falls ich mich da irre, bitte korrigieren. Ulrich
Re: auf UTF-8 umsteigen, Folgen?
On 11.07.06 19:22:03, Ulrich Fürst wrote: Peter Jordan [EMAIL PROTECTED] wrote: Nun habe ich aber von meinem alten System tausende Dateien die mit normalen ISO-8859-15 codiert sind. Wenn Du in Text-Dateien Umlaute hast musst Du die umändern (lassen). Noe muss man nicht, jedenfalls solange man einen vernuenftigen Editor verwendet. Der kann mit etwas Magie u.U. die Kodierung feststellen und dann fuers Editieren/Anzeigen das ganze intern Umkodieren und beim Abspeichern wieder in latin9 ablegen. Vim kann das, KDE's kate/kwrite ebenso. Evtl. muss man ihm sagen welche Kodierung die Datei hat, wenn Umlaute kaputt sind (aka die Magie hat nicht funktioniert). Je nachdem was Du so installiert hast können natürlich noch Probleme auftreten. KDE interressiert sich z. B. weder für die .bashrc noch für .profile etc. KDE hat damit ja auch nun ueberhaupt nichts zu tun. Die Shells die Konsole startet lesen uebrigens sehr wohl .bashrc aus. Was das einloggen betrifft: kdm aus testing/unstable liest auch die Shell-Configs, nicht nur .profile/.bashrc auch .zsh und was es sonst noch gibt. Manche Programme benötigen extra Optionen. Mein Gimp braucht z. B. cat /etc/environment # Fuer Gimp export G_FILENAME_ENCODING=UTF-8 Komisch, hier brauchts das nicht. Aber s.o. ich fahre auch unstable, moeglich das der schon etwas besser ist als der aus Sarge. Andreas -- A vivid and creative mind characterizes you. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
Hi, On 060711 at 19:30, Ulrich F�rst wrote: Peter Jordan [EMAIL PROTECTED] wrote: Nun habe ich aber von meinem alten System tausende Dateien die mit normalen ISO-8859-15 codiert sind. Ich hab vor ein paar Monaten spassenshalber mal komplett auf Unicode/UTF8 umgestellt. Meinen Mailserver (und -Client), auf den ich nur per ssh zugreife, sowie meinen Desktop-Rechner. Ich hab mich dabei an die UTF-Howtos gehalten, die man im Netz so findet. Wirklich Ahnung hab ich von diesem Codierungskram aber nicht, wie man vllt gleich sieht. Also mit Konfigurationsdateien hatte ich hier erstmal gar keine Probleme, man kann problemlos auf Unicode umstellen und an verschiedenen Ecken noch tunen, ohne dass Programme nicht mehr starten oder der Rechner nicht mehr booten will oder so. Einziges Problem waren bei mir Nutzerdaten. Mail ist nen bissl doof. Entweder weil ich noch immer was falsch mache, oder viele Clients nicht mit utf8 klar kommen. (�,�,�,�,�,�,�, anyone?) Ein Problem stellen auch zB Dateinamen dar. Die sind ja auch irgendwie kodiert, verfuegbare Codings sind im Kernel zu konfigurieren. Mit convmv kann man die Codierungen aendern. Aber ich hab noch immer Probleme, wenn zB der p2p-Client gegenueber anderen Clients Dateien fehlerhaft anzeigt(UTF wird nicht beachtet) oder beim runterladen die Datei zwar f�b�r heist und korrekt angezeigt wird, aber irgendwie trotzdem anders/falsch codiert ist. Wenn ich dann zB auf der Tastatur rm f�b�r eingebe, wird diese Datei nicht geloescht, weil die Umlaute verschieden kodiert sind. Erst wenn ich den Namen konvertiere kann ich ihn auch richtig eintippen.(in der Praxis behilft man sich sinnvoller Weise wildcards/bash-completation) Meines Wissens hat man bei Unicode wohl schon darauf geachtet, dass viele Zeichen gleich codiert sind wie in anderen Zeichensaetzen, aber bei Umlauten hoert es anscheinend schon auf. Nun mag man sagen, wer Sonderzeichen in Dateinamen nimmt ist selbst schuld. Aber bei mp3-Sammlungen aus fernen Laendern wird das dann schon doof... Nerviges Problem ist, dass man fuer unicode modifizierte terminals benutzt, die dann auch anders heissen. z.B. rxvt-unicode oder uxterm. Diese Namen als TERM-Variable kennt dann irgendwie auch kaum ein Rechner, sodass bei der Arbeit mit SSH die Zeile TERM=xterm bei mir inzwischen ziemlich flink von der Hand geht, sobald das Terminal mal nicht aussieht wie erwartet. Das laesst sich sicher zB in der ~/.bash_profile permanent loesen, aber ich will eigentlich lieber wissen, aus welchen Gruenden man hier die Kompatibilitaet aufgibt. Offenbar geht mir irgendwas verloren, wenn ich TERM=xterm mache.. Zusammenfassend werd ich wohl wieder iso-8859-15 nehmen, wenn ich mal dazu komme, das Gentoo hier durch Debian zu ersetzen. So tolle Sonderzeichen eingeben koennen ist nett, aber wenn die dann nicht ankommen und man sich diverse andere Probleme einhandelt, ist das dann nicht mehr so toll... mfg pepe -- Um sich in einer Schafherde wohlzuf�hlen, muss man vor allem Schaf sein. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
Hey. Peter Jordan wrote: ich bekomme in der nächsten Zeit einen neuen Computer und überlege auf den Zeichensatz UTF-8 umzusteigen. Nun habe ich aber von meinem alten System tausende Dateien die mit normalen ISO-8859-15 codiert sind. Was hat es jetzt für Folgen, wenn ich meine Dateien auf den neuen Rechner kopiere? Was muss man beachten? Konvertieren, z.B. mit uni2ascii (konvertiert in beide Richtungen) Was passiert beispielsweise mit meinen Mails in meinem Thunderbirdkonto? Falls du Ordner mit Umlauten verwendest, werden diese falsch angezeigt. Mit den Mails passiert nichts, die Kodierung ist normalerweise enthalten (us-ascii, iso8859-1, etc.) und wird vom Mailclient entsprechend interpretiert. Wundere dich aber nach dem Umstieg nicht, dass alles (was mit Codierung zu tun hat) etwas langsamer wird. Gruß Kai -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
On 11.07.06 20:58:41, Steffen Schulz wrote: Mail ist nen bissl doof. Entweder weil ich noch immer was falsch mache, oder viele Clients nicht mit utf8 klar kommen. (?,?,?,?,?,?,?, anyone?) Hae? Mutt kann wunderbar UTF-8, sofern das korrekt in der Shell gesetzt ist. Aber das ist noch lange kein Grund seine latin1/latin9 Mails als UTF-8 zu verschicken, dafuer gibts sowas: set send_charset = us-ascii:iso-8859-1:iso-8859-15:utf-8 Damit nimmt mutt das kleinstmoegliche Charset beim verschicken. Also hier meistens iso-8859-1. Ein Problem stellen auch zB Dateinamen dar. Die sind ja auch irgendwie kodiert, verfuegbare Codings sind im Kernel zu konfigurieren. Also damit habe ich eigentlich auch keinerlei Probleme. Wenn ein User mit de_DE locale eine Datei mit Umlauten auf einem *nix-Dateisystem ablegt kann ich die auch korrekt in UTF-8 locale sehen. Und Default-Kodierung fuer FS im Kernel ist hier latin1. Solange der Kernel weiss welche Kodierung das Dateisystem nutzt ist das alles kein Problem. Problematisch wirds bei FAT/NTFS und evtl. SMB/CIFS, aber dort gibts Optionen um dem Kernel auf die Spruenge zu helfen. Mit convmv kann man die Codierungen aendern. Wie gesagt hier unnoetig. Aber ich hab noch immer Probleme, wenn zB der p2p-Client gegenueber anderen Clients Dateien fehlerhaft anzeigt(UTF wird nicht beachtet) oder beim runterladen die Datei zwar f?b?r heist und korrekt angezeigt wird, aber irgendwie trotzdem anders/falsch codiert ist. Dann ist irgendwas bei dir kaputt, evtl. auch einfach nur der Client. Meines Wissens hat man bei Unicode wohl schon darauf geachtet, dass viele Zeichen gleich codiert sind wie in anderen Zeichensaetzen, Da ist schon dein 1. Denkfehler: Unicode != UTF-8. Unicode ist etwas sehr abstraktes, IIRC einfach nur ein Mapping von sog. Codepoints auf Glyphen. UTF-8 ist eine Zeichenkodierung fuer Byte-Streams die alle Unicode-Zeichen darstellen kann. Dadurch das UTF-8 variable Lange Byte-Folgen fuer 1 Zeichen nutzt kann es den ASCII-Zeichensatz direkt nutzen. Also alle UTF-8 1-Byte-Zeichenfolgen sind mit demselben Integerwert im ASCII-Zeichensatz zu finden. Umlaute liegen aber oberhalb von 127 und werden deswegen mit 2 Bytes kodiert. Daneben gibts noch UTF-16 oder UTF-32 die jeweils die entsprechende Mindestanzahl an Bytes fuer 1 Zeichen nutzen. Dadurch sind damit kodierte Dateien wirklich nur mit einem Editor/Viewer zu betrachten der UTF-16/32 auch beherrscht. Nerviges Problem ist, dass man fuer unicode modifizierte terminals benutzt, die dann auch anders heissen. z.B. rxvt-unicode oder uxterm. Bloedsinn, deine Howtos sind hoffnungslos veraltet. Solange LANG korrekt gesetzt ist, funktionieren xterm, gnome-terminal, konsole und xfce4-terminal wunderbar. Ich vermute aber das bei dir einfach LANG falsch gesetzt ist. Zusammenfassend werd ich wohl wieder iso-8859-15 nehmen, wenn ich mal dazu komme, das Gentoo hier durch Debian zu ersetzen. So tolle Sonderzeichen eingeben koennen ist nett, aber wenn die dann nicht ankommen und man sich diverse andere Probleme einhandelt, ist das dann nicht mehr so toll... Also ich habe 0 Probleme. Hoechstens mal wenn eine Mail anders kodiert ist, als im Header angegeben, aber das liegt dann meistens am OP und seinem Mailclient... Andreas -- You are always busy. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
Andreas Pakulat [EMAIL PROTECTED] wrote: On 11.07.06 19:22:03, Ulrich Fürst wrote: Peter Jordan [EMAIL PROTECTED] wrote: Nun habe ich aber von meinem alten System tausende Dateien die mit normalen ISO-8859-15 codiert sind. Wenn Du in Text-Dateien Umlaute hast musst Du die umändern (lassen). Noe muss man nicht, jedenfalls solange man einen vernuenftigen Editor verwendet. Eben, aber wenn ich mit cat und less arbeite fehlen die Umlaute... Je nachdem was Du so installiert hast können natürlich noch Probleme auftreten. KDE interressiert sich z. B. weder für die .bashrc noch für .profile etc. KDE hat damit ja auch nun ueberhaupt nichts zu tun. Die Shells die Konsole startet lesen uebrigens sehr wohl .bashrc aus. Die Konsole ist so ziemlich das einzige was hier keine Probleme gemacht hat. Viele andere Anwendungen haben Probleme. Was das einloggen betrifft: kdm aus testing/unstable liest auch die Shell-Configs, nicht nur .profile/.bashrc auch .zsh und was es sonst noch gibt. kdm schon aber offensichtlich nicht alle kde-Anwendungen und auch nicht alle gtk2 Anwendungen. Manche Programme benötigen extra Optionen. Mein Gimp braucht z. B. cat /etc/environment # Fuer Gimp export G_FILENAME_ENCODING=UTF-8 Komisch, hier brauchts das nicht. Aber s.o. ich fahre auch unstable, moeglich das der schon etwas besser ist als der aus Sarge. Gimp startete nicht mehr und meldete, dass er diese Variable gesetzt haben möchte. Ulrich
Re: auf UTF-8 umsteigen, Folgen?
Andreas Pakulat: Also ich habe 0 Probleme. Hoechstens mal wenn eine Mail anders kodiert ist, als im Header angegeben, aber das liegt dann meistens am OP und seinem Mailclient... Da das Thema mal wieder angesprochen wird und Du Dich scheinbar damit auskennst... :) Ich habe aufgrund des kürzlich erwähnten Datenverlustes den Etch-Installer ausprobiert (mit GUI!!elf) und der stellt ja automatisch UTF-8 ein. Ich hatte aber dann das Problem, dass eine SSH-Session auf ein ISO-8859-1-System furchtbar kaputt aussah. Ich vermute auch, dass mein mutt auf ebendiesem System falsch kodierte Mails rausgeschickt hat (UTF-8 als ISO-8859-1), wenn ich die per SSH vom UTF-System geschrieben habe. Muß ich da irgendwas machen, damit ich keine Probleme kriege? Liegt das am Terminal, oder hätte ich screen (in dem mutt läuft) neu starten müssen? J. -- The news at ten makes me peevish but animal hospital makes me cry. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: auf UTF-8 umsteigen, Folgen?
On 2006-07-11 22:45:07 +0200, Jochen Schulz wrote: Ich habe aufgrund des kürzlich erwähnten Datenverlustes den Etch-Installer ausprobiert (mit GUI!!elf) und der stellt ja automatisch UTF-8 ein. Ich hatte aber dann das Problem, dass eine SSH-Session auf ein ISO-8859-1-System furchtbar kaputt aussah. Ich vermute auch, dass mein mutt auf ebendiesem System falsch kodierte Mails rausgeschickt hat (UTF-8 als ISO-8859-1), wenn ich die per SSH vom UTF-System geschrieben habe. Muß ich da irgendwas machen, damit ich keine Probleme kriege? Liegt das am Terminal, oder hätte ich screen (in dem mutt läuft) neu starten müssen? Das liegt daran, dass dein Terminal noch im UTF-8 Modus war, die Gegenseite jedoch in ISO-8859-1 (siehe locale auf dem Zielrechner): dein Terminal hat UTF-8 geschickt und die Gegenseite hat es als ISO-8859-1 intepretiert = kaputte Umlaute (in beide Richtungen). Entweder sagst du dem Zielsystem, dass du eine UTF-8 Locale nutzt (wenn es das Ziel-System kann) oder du stellst dein Terminal passend ein. Im gnome-terminal z.B. kannst du den Zeichensatz einstellen. Nutze ich wenn ich mich zu Rechnern verbinde, die noch keine UTF-8 Locales haben. Michael -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
* Ulrich Fürst: Wenn Du in Text-Dateien Umlaute hast musst Du die umändern (lassen). Noe muss man nicht, jedenfalls solange man einen vernuenftigen Editor verwendet. Eben, aber wenn ich mit cat und less arbeite fehlen die Umlaute... lv als Substitut für less ist im Raten der Codierung recht gut. Mir fällt damit nicht auf, wenn es eine iso-8859-Datei anzuschauen gilt. kdm schon aber offensichtlich nicht alle kde-Anwendungen und auch nicht alle gtk2 Anwendungen. Welche GTK2-Anwendungen denn nicht? Andreas -- You have been selected for a secret mission. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
On 11.07.06 22:34:27, Ulrich Fürst wrote: Andreas Pakulat [EMAIL PROTECTED] wrote: On 11.07.06 19:22:03, Ulrich Fürst wrote: Peter Jordan [EMAIL PROTECTED] wrote: Nun habe ich aber von meinem alten System tausende Dateien die mit normalen ISO-8859-15 codiert sind. Wenn Du in Text-Dateien Umlaute hast musst Du die umändern (lassen). Noe muss man nicht, jedenfalls solange man einen vernuenftigen Editor verwendet. Eben, aber wenn ich mit cat und less arbeite fehlen die Umlaute... Jupp. Je nachdem was Du so installiert hast können natürlich noch Probleme auftreten. KDE interressiert sich z. B. weder für die .bashrc noch für .profile etc. KDE hat damit ja auch nun ueberhaupt nichts zu tun. Die Shells die Konsole startet lesen uebrigens sehr wohl .bashrc aus. Die Konsole ist so ziemlich das einzige was hier keine Probleme gemacht hat. Viele andere Anwendungen haben Probleme. Also ich hab bisher keine Anwendungen gefunden die Probleme machen, insbesondere keine KDE-Anwendungen. Allerdings setzt das vorraus dass die LANG-Variable beim Starten der X11-Sitzung aktiv ist. Was eben nur fuer kdm aus Testing gilt, nicht fuer den aus Sarge. Dort muss man das ganze entweder ueber .xsession loesen, oder direkt die kdm-Xsession-Skripte abaendern. Was das einloggen betrifft: kdm aus testing/unstable liest auch die Shell-Configs, nicht nur .profile/.bashrc auch .zsh und was es sonst noch gibt. kdm schon aber offensichtlich nicht alle kde-Anwendungen Rueck doch mal bitte mit konkreten Beispielen raus. Hier verhalten sich _alle_ von mir eingesetzten KDE-Anwendungen korrekt, sofern LANG korrekt und auch in der unsichtbaren session-shell gesetzt ist. und auch nicht alle gtk2 Anwendungen. Auch damit habe ich bisher keinerlei Probleme, aber ausser grip und gelegentlich easytag brauch ich da nichts. Manche Programme benötigen extra Optionen. Mein Gimp braucht z. B. cat /etc/environment # Fuer Gimp export G_FILENAME_ENCODING=UTF-8 Komisch, hier brauchts das nicht. Aber s.o. ich fahre auch unstable, moeglich das der schon etwas besser ist als der aus Sarge. Gimp startete nicht mehr und meldete, dass er diese Variable gesetzt haben möchte. Wie gesagt, kann ich nicht nachvollziehen. Andreas -- You will be Told about it Tomorrow. Go Home and Prepare Thyself. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
On 11.07.06 22:45:07, Jochen Schulz wrote: Andreas Pakulat: Also ich habe 0 Probleme. Hoechstens mal wenn eine Mail anders kodiert ist, als im Header angegeben, aber das liegt dann meistens am OP und seinem Mailclient... Ich habe aufgrund des kürzlich erwähnten Datenverlustes den Etch-Installer ausprobiert (mit GUI!!elf) und der stellt ja automatisch UTF-8 ein. Achja? Ich war bisher der Meinung dass er dpkg-reconfigure locales ausfuehrt und du dann waehlen kannst. Aber ich hab auch noch nie Etch installiert... Ich hatte aber dann das Problem, dass eine SSH-Session auf ein ISO-8859-1-System furchtbar kaputt aussah. Kannst du das etwas genauer beschreiben? Ich vermute auch, dass mein mutt auf ebendiesem System falsch kodierte Mails rausgeschickt hat (UTF-8 als ISO-8859-1), Deine Mail auf die ich geantwortet habe war UTF-8 deklariert und soweit ich das gesehen habe auch genauso kodiert. Nur das das eben nicht unbedingt immer sinnvoll ist, insbesondere wenn man mit Leuten kommuniziert die kaputte Mailclients oder Webmailer benutzen. wenn ich die per SSH vom UTF-System geschrieben habe. Muß ich da irgendwas machen, damit ich keine Probleme kriege? Liegt das am Terminal, oder hätte ich screen (in dem mutt läuft) neu starten müssen? Aenderungen an Umgebungsvariablen werden erst nach einem Re-Login erkannt. Ich hab grad mal getestet: Eine mit vim erzeugte Datei auf dem Server (auf dem LANG=de_DE) kriegt als Kodierung trotzdem UTF-8 (auf dem Client ist LANG=de_DE.UTF-8). Eine in mutt verfasste Mail (mit vim als Editor) wird in Latin1 kodiert und verschickt. Ansonsten werden Meldungen von Programmen wohl auch in Latin1 ausgegeben, ssh scheint das hier nicht korrekt zu konvertieren (also sehe ich Rauten statt Umlaute und es fehlt das nachfolgende Zeichen). Das mit dem nicht-konvertieren von vim koennte eine Einstellungssache sein, auf dem Server mache ich derlei kaum... Andreas -- Be careful! Is it classified? -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
On 11.07.06 20:49:08, Kai Hildebrandt wrote: Peter Jordan wrote: ich bekomme in der nächsten Zeit einen neuen Computer und überlege auf den Zeichensatz UTF-8 umzusteigen. Nun habe ich aber von meinem alten System tausende Dateien die mit normalen ISO-8859-15 codiert sind. Was hat es jetzt für Folgen, wenn ich meine Dateien auf den neuen Rechner kopiere? Was muss man beachten? Konvertieren, z.B. mit uni2ascii (konvertiert in beide Richtungen) Wie soll dass denn helfen? Latin1-Kodierte Dateien enthalten 8bit Zeichen, nicht 7Bit Ascii. 7Bit Ascii braucht man nicht in UTF-8 zu wandeln, weil es in UTF-8 auf diesselbe Weise kodiert wird, als 1 Byte mit 7 signifikanten Bits. Umkodierungen von latin1 zu utf-8 fuehrt recode zuverlaessig durch: recode latin1..utf-8 foobar Und sagt dir dabei auch gleich ob die Datei ueberhaupt latin1 ist. Was passiert beispielsweise mit meinen Mails in meinem Thunderbirdkonto? Falls du Ordner mit Umlauten verwendest, werden diese falsch angezeigt. In TB? Dann ist das ein Bug in TB. Wundere dich aber nach dem Umstieg nicht, dass alles (was mit Codierung zu tun hat) etwas langsamer wird. Du meinst in TB? Wieso dass denn? Hast du Zahlen dazu? Andreas -- A few hours grace before the madness begins again. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
On Tue, Jul 11, 2006 at 06:31:09PM +0200, Peter Jordan wrote: Nun habe ich aber von meinem alten System tausende Dateien die mit normalen ISO-8859-15 codiert sind. Die Rekodierung Latin9-Unicode ist problemlos. Aufpassen muss man nur bei CP125[0-2] kodierten Dateien welche unter Windows als standard-kodierung verwendet wird. Die sieht den Latin-Codes aehnlich, muss aber als Ausgangskodierung richtig benannt werden damit die Kodierung in Unicode erfolgen kann. UTF-8 ist nur ein encoding Schema. http://www.unicode.org/faq/utf_bom.html#2 Peter -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: auf UTF-8 umsteigen, Folgen?
On 060711 at 23:10, Jochen Schulz wrote: UTF-8 ein. Ich hatte aber dann das Problem, dass eine SSH-Session auf ein ISO-8859-1-System furchtbar kaputt aussah. Ich vermute auch, dass mein mutt auf ebendiesem System falsch kodierte Mails rausgeschickt hat (UTF-8 als ISO-8859-1), wenn ich die per SSH vom UTF-System geschrieben habe. Muß ich da irgendwas machen, damit ich keine Probleme kriege? Liegt das am Terminal, oder hätte ich screen (in dem mutt läuft) neu starten müssen? Ich benutz zwar kein Screen, aber der setzt im Gegensatz zu SSH meines Wissens die Kodierungen um. Dh. den haettest du wohl mindestens mal neustarten oder ihm das anders beibringen muessen, weil der Input fuer Screen nun utf8-codiert ist.. mfg pepe -- No matter where you are... Everyone is always connected. - Serial Experiments Lain signature.asc Description: Digital signature
Re: auf UTF-8 umsteigen, Folgen?
On 060711 at 21:20, Andreas Pakulat wrote: Ein Problem stellen auch zB Dateinamen dar. Die sind ja auch irgendwie kodiert, verfuegbare Codings sind im Kernel zu konfigurieren. Also damit habe ich eigentlich auch keinerlei Probleme. Wenn ein User mit de_DE locale eine Datei mit Umlauten auf einem *nix-Dateisystem ablegt kann ich die auch korrekt in UTF-8 locale sehen. Hm. Ich hoffe mein ü kommt korrekt an, sonst wird das jetzt etwas wirr: [EMAIL PROTECTED] ~]$ echo $TERM, $LANG rxvt-unicode, en_US.utf8 [EMAIL PROTECTED] ~]$ touch tür [EMAIL PROTECTED] ~]$ ls tür tür [EMAIL PROTECTED] ~]$ rm tür [EMAIL PROTECTED] ~]$ export LANG=en_US [EMAIL PROTECTED] ~]$ urxvt - 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. :-/ - touch tür; exit [EMAIL PROTECTED] ~]$ rm tür rm: cannot remove `tür': No such file or directory [EMAIL PROTECTED] ~]$ ls tür ls: tür: No such file or directory [EMAIL PROTECTED] ~]$ ls t?r tür - Unter anderem locale erzeugte Dateien werden hier korrekt angezeigt, aber wenn ich den Namen eingebe passt er nicht auf den im FS vorhandenen. Default-Kodierung fuer FS im Kernel ist hier latin1. Solange der Kernel weiss welche Kodierung das Dateisystem nutzt ist das alles kein Problem. Problematisch wirds bei FAT/NTFS und evtl. SMB/CIFS, aber dort gibts Optionen um dem Kernel auf die Spruenge zu helfen. Mit convmv kann man die Codierungen aendern. Wie gesagt hier unnoetig. Von oben weiter, also mit kaputter Datei tür(man entschuldige meine Kreativitaet..) [EMAIL PROTECTED] ~]$ convmv --notest -f iso-8859-1 -t utf-8 t?r mv ./tür ./tür Ready! [EMAIL PROTECTED] ~]$ rm tür Nachdem convmv den Dateinamen von 8859-1 nach utf-8 convertiert hat, kann ich den Dateinamen korrekt eintippen. Vorher hats dann auf Dateisystemebene nicht gepasst, weil die ü unterschiedlich kodiert werden. Sieht man auch daran, dass ich so 2x die gleiche Datei erstellen kann, einmal wird sie auf FS-Ebene mit iso-8859-1 und einmal mit utf-8 kodiert, der Dateiname unterscheidet sich dort also. Oda aba da is noch wat andret falsch... Aber ich hab noch immer Probleme, wenn zB der p2p-Client gegenueber anderen Clients Dateien fehlerhaft anzeigt(UTF wird nicht beachtet) oder beim runterladen die Datei zwar f?b?r heist und korrekt angezeigt wird, aber irgendwie trotzdem anders/falsch codiert ist. Dann ist irgendwas bei dir kaputt, evtl. auch einfach nur der Client. Der p2p-Client, ja, weil er die Namen nicht entsprechend der locale abspeichert. Nerviges Problem ist, dass man fuer unicode modifizierte terminals benutzt, die dann auch anders heissen. z.B. rxvt-unicode oder uxterm. Bloedsinn, deine Howtos sind hoffnungslos veraltet. Solange LANG korrekt gesetzt ist, funktionieren xterm, gnome-terminal, konsole und xfce4-terminal wunderbar. Ich vermute aber das bei dir einfach LANG falsch gesetzt ist. Nun, als ich damals die entsprechenden terminals probiert habe, wurde halt auf die unicode-varianten verwiesen. Das is nu mind. nen Jahr her, okay...aber meine Howtos erzaehlen noch immer was von Dateinamen: http://de.gentoo-wiki.com/Utf8#Dateinamen Oh, und rate was ich eben in der muttrc fand... set send_charset=UTF-8:ISO-8859-15:ISO-8859-1 Da ist wohl was schiefgelaufen.. ^^ mfg pepe -- Hi, I'm a unix-virus. Please copy me into your .signature to help me spread! -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
