Hallo Liste, jetzt wollte ich mir schnell mal eine Ergänzung für meine Website schreiben und mein Lieblingstool recode macht mir die Datei kaputt. recode sollte mir nur die Umlaute kodieren. Zum händisch tippen bin ich zu faul. Vermutlich liegt das daran, daß die Datei unter eine SuSE 8.2 erstellt wurde und ich sie jetzt auf eine SuSE 9.2 rüberkopiert habe. Was darf ich denn jetzt auf meine Hompäjtsch schaufeln, so daß meine Besucher einen heilen Text zu sehen bekommen? Am besten dieses Mist-utf8 ausknipsen? (Dazu gibt's eine Anleitung in der SDB). Oder hab' ich da ein Stück Fortschritt verpasst? Helga -- ## OpenSource-Werkstatt in Reutlingen -- http://www.eschkitai.de/ ## Etikette - Nein Danke? -- http://www.suse-etikette.de.vu/ ## Wer hilft? -- http://hsqldb.sourceforge.net/web/openoffice.html
Hallo Liste, ich sollte vielleicht noch ein wenig ergänzen: Das ist ein neuer Text (in der ursprünglichen Datei): So siehts im Browser aus: Und es kann passieren, daß eine Liste nicht mehr zu reagieren scheint. Das Àußert sich darin, daß Deine geschriebenen Mails nicht mehr zurÃŒckkommen... Quältext so: Und es kann passieren, daà eine Liste nicht mehr zu reagieren scheint. Das ÀuÃert sich darin, daà Deine geschriebenen Mails nicht mehr Ursprünglich waren das mal ä und ß. Am Sonntag 8 Mai 2005 18:55 schrieb Helga Fischer:
recode sollte mir nur die Umlaute kodieren.
Hier habe ich wohl ein wenig geschludert, recode ist (in Quanta) ein alias auf: /usr/bin/recode -d latin9..h4. Jetzt die Preisfrage: Wenn ich eine alte Datei von SuSE 8.2 nach SuSE 9.2 rüberkopiere, welche Codierung hat die Datei denn nun? (Dem mount der alten /home-Partition habe ich keine besonderen Schalter mitgegeben). Und wenn ich jetzt auf der SuSE 9.2 drin rumarbeite, ist die Datei jetzt zweifach kodiert? Ich steig' da irgendwie nicht durch. Ich nehme auch liebend gerne ein zweckdienliches RTFM entgegen. Helga -- ## OpenSource-Werkstatt in Reutlingen -- http://www.eschkitai.de/ ## Etikette - Nein Danke? -- http://www.suse-etikette.de.vu/ ## Wer hilft? -- http://hsqldb.sourceforge.net/web/openoffice.html
Helga Fischer schrieb:
[...] Jetzt die Preisfrage: Wenn ich eine alte Datei von SuSE 8.2 nach SuSE 9.2 rüberkopiere, welche Codierung hat die Datei denn nun? (Dem mount der alten /home-Partition habe ich keine besonderen Schalter mitgegeben).
Die Kodierung bleibt dieselbe. Wäre ja auch schlimm, wenn die Bits der Dateien vom mount abhängig wären. Der Content-Type-Metatag sollte die tatsächliche Kodierung der Seite enthalten. Dann sollten auch die Character-Entity-Referenzen für Umlaute u.ä. nicht mehr nötig sein. -- Gruß, Alex
Hallo Helga, hallo Leute, Am Sonntag, 8. Mai 2005 19:20 schrieb Helga Fischer:
Das ist ein neuer Text (in der ursprünglichen Datei):
So siehts im Browser aus: Und es kann passieren, daß eine Liste nicht mehr zu reagieren scheint. Das Àußert sich darin, daß Deine geschriebenen Mails nicht mehr zurÌckkommen...
Quältext so: Und es kann passieren, daà eine Liste nicht mehr zu reagieren scheint. Das ÀuÃert sich darin, daà Deine geschriebenen Mails nicht mehr
Das erklärt die Anzeige im Browser - Du befiehlst ihm ja ausdrücklich, z. B. Ã (Ã) und Ÿ () anzuzeigen.
Ursprünglich waren das mal ä und ß.
Jepp - allerdings in utf-8.
Am Sonntag 8 Mai 2005 18:55 schrieb Helga Fischer:
recode sollte mir nur die Umlaute kodieren.
Hier habe ich wohl ein wenig geschludert, recode ist (in Quanta) ein alias auf: /usr/bin/recode -d latin9..h4. ^^^^^^ Das dürfte der Fehler sein - man latin9 bringt mich zur iso-8859-15 Manpage. Ändere das mal auf utf-8 als Quellcodierung.
Jetzt die Preisfrage: Wenn ich eine alte Datei von SuSE 8.2 nach SuSE 9.2 rüberkopiere, welche Codierung hat die Datei denn nun? (Dem mount der alten /home-Partition habe ich keine besonderen Schalter mitgegeben).
Der Datei_inhalt_ ändert sich nicht, ist also noch iso-8859-1(5)- codiert.
Und wenn ich jetzt auf der SuSE 9.2 drin rumarbeite, ist die Datei jetzt zweifach kodiert? Ich steig' da irgendwie nicht durch.
Wenn Dein Editor nicht aufpasst, bekommst Du einen Mischmasch aus iso-8859-15 und utf-8 :-/
Ich nehme auch liebend gerne ein zweckdienliches RTFM entgegen.
Ein recode-Aufruf zur Konvertierung von iso-8859-15 nach utf-8 müsste genügen. Oder Du konvertierst gleich zu HTML-Entities - das ist zeichensatz-sicher ;-) Stolperfalle: In der HTML-Datei muss im <head> bei <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> der richtige Zeichensatz eingestellt sein. (Es sei denn, Du codierst _alle_ Umlaute, dann ist es egal ;-) Ich habe übrigens ein vim-Plugin im Einsatz, das mir sämtliche Umlaute gleich beim Tippen codiert. Ich tippe "ü" und erhalte ü :-) Das w3c empfiehlt zwar die Codierung sämtlicher Umlaute nicht ("should not" [1]) - aber es ist IMHO die zuverlässigste Variante ;-) Gruß Christian Boltz PS: Trotz 9.3 verwende ich immer noch iso-8859-15 als systemweiten Zeichensatz... [1] "should not" meint beim w3c sowas wie "tu es nur, wenn Du die Folgen genau abschätzen kannst". Das kann ich, die HTML-Datei wird ein paar Byte größer ;-) -- [SuSE-Plugger] Ist auch nichts von KDE, sondern ist eine SuSE- spezifische Fehlentwicklung. [Manfred Tremmel in suse-linux]
Hallo Christian, Am Sonntag 8 Mai 2005 21:52 schrieb Christian Boltz:
Am Sonntag, 8. Mai 2005 19:20 schrieb Helga Fischer:
[...]
Das erklärt die Anzeige im Browser - Du befiehlst ihm ja ausdrücklich, z. B. Ã (Ã) und Ÿ () anzuzeigen.
Ursprünglich waren das mal ä und ß.
Jepp - allerdings in utf-8.
Ja, dem widerspreche ich nicht.
Am Sonntag 8 Mai 2005 18:55 schrieb Helga Fischer:
recode sollte mir nur die Umlaute kodieren.
Hier habe ich wohl ein wenig geschludert, recode ist (in Quanta) ein alias auf: /usr/bin/recode -d latin9..h4.
^^^^^^ Das dürfte der Fehler sein - man latin9 bringt mich zur iso-8859-15 Manpage. Ändere das mal auf utf-8 als Quellcodierung.
Gut, mache ich.
Jetzt die Preisfrage: Wenn ich eine alte Datei von SuSE 8.2 nach SuSE 9.2 rüberkopiere, welche Codierung hat die Datei denn nun? (Dem mount der alten /home-Partition habe ich keine besonderen Schalter mitgegeben).
Der Datei_inhalt_ ändert sich nicht, ist also noch iso-8859-1(5)- codiert.
Dh, wenn ich Ergänzungen reinhaue, sind die utf-8 codiert und ich erhalte einen Mischmasch.
Und wenn ich jetzt auf der SuSE 9.2 drin rumarbeite, ist die Datei jetzt zweifach kodiert? Ich steig' da irgendwie nicht durch.
Wenn Dein Editor nicht aufpasst, bekommst Du einen Mischmasch aus iso-8859-15 und utf-8 :-/
Quantalein hat gar nichts dazu gesagt. Ich befürchte aber, der paßt da nicht auf.
Ich nehme auch liebend gerne ein zweckdienliches RTFM entgegen.
Ein recode-Aufruf zur Konvertierung von iso-8859-15 nach utf-8 müsste genügen.
Ich kann ja wohl schlecht all meinen Krimskrams umcodieren? Ich habe nämlich reichlichst alte Datenbestände, weswegen ich eigentlich auch gar nicht umziehen wollte.
Oder Du konvertierst gleich zu HTML-Entities - das ist zeichensatz-sicher ;-)
Das mache ich sowieso. Da scheint's aber jetzt auch andere zu geben statt des ü und Co.
Stolperfalle: In der HTML-Datei muss im <head> bei <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> der richtige Zeichensatz eingestellt sein. (Es sei denn, Du codierst _alle_ Umlaute, dann ist es egal ;-)
Ja, ich guck' mal nach, was ich drin stehen habe. Meine Seiten sind schon etwas angegraut.
Ich habe übrigens ein vim-Plugin im Einsatz, das mir sämtliche Umlaute gleich beim Tippen codiert. Ich tippe "ü" und erhalte ü :-)
Quanta konnte das mal in Urzeiten, dann war die Funktion weg und ich habe mit recode gearbeitet. Muß mal gucken, vielleicht kann er es jetzt wieder. Was ich aber nicht glaube.
Das w3c empfiehlt zwar die Codierung sämtlicher Umlaute nicht ("should not" [1]) - aber es ist IMHO die zuverlässigste Variante ;-)
PS: Trotz 9.3 verwende ich immer noch iso-8859-15 als systemweiten Zeichensatz...
Hmmm... soll ich umstellen probieren? Bisher scheint das utf-8 sich ja nicht so grauslig negativ bemerkbar zu machen. Eine gnupg-Passphrase geht wohl deswegen nicht mehr; sie enthält Umlaute. Die andere funktioniert - keine Umlaute.
[1] "should not" meint beim w3c sowas wie "tu es nur, wenn Du die Folgen genau abschätzen kannst". Das kann ich, die HTML-Datei wird ein paar Byte größer ;-) ;))
Helga -- ## OpenSource-Werkstatt in Reutlingen -- http://www.eschkitai.de/ ## Etikette - Nein Danke? -- http://www.suse-etikette.de.vu/ ## Wer hilft? -- http://hsqldb.sourceforge.net/web/openoffice.html
Hallo Helga, hallo Leute, Am Sonntag, 8. Mai 2005 22:17 schrieb Helga Fischer:
Am Sonntag 8 Mai 2005 21:52 schrieb Christian Boltz:
Am Sonntag, 8. Mai 2005 19:20 schrieb Helga Fischer:
Am Sonntag 8 Mai 2005 18:55 schrieb Helga Fischer: [...] Jetzt die Preisfrage: Wenn ich eine alte Datei von SuSE 8.2 nach SuSE 9.2 rüberkopiere, welche Codierung hat die Datei denn nun?
Der Datei_inhalt_ ändert sich nicht, ist also noch iso-8859-1(5)- codiert.
Dh, wenn ich Ergänzungen reinhaue, sind die utf-8 codiert und ich erhalte einen Mischmasch.
Du hast das Problem erkannt... (oder einen schlechten Editor ;-)
Ich nehme auch liebend gerne ein zweckdienliches RTFM entgegen.
Ein recode-Aufruf zur Konvertierung von iso-8859-15 nach utf-8 müsste genügen.
Ich kann ja wohl schlecht all meinen Krimskrams umcodieren? Ich habe nämlich reichlichst alte Datenbestände, weswegen ich eigentlich auch gar nicht umziehen wollte.
find -type f | while read file ; do recode latin9..utf-8 "$file" done Ungetestet, daher vorher bitte an einem Verzeichnis mit nicht zu vielen Dateien ausprobieren und das Ergebnis überprüfen.
Oder Du konvertierst gleich zu HTML-Entities - das ist zeichensatz-sicher ;-)
Das mache ich sowieso. Da scheint's aber jetzt auch andere zu geben statt des ü und Co.
Nö, ü usw. stimmt weiterhin, wenn Du ein ü willst. Das à usw, das Du bekommen hast, entstand aufgrund der unerwarteten uft-8-Codierung und war ja auch in der Browser-Anzeige falsch.
Stolperfalle: In der HTML-Datei muss im <head> bei <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> der richtige Zeichensatz eingestellt sein. (Es sei denn, Du codierst _alle_ Umlaute, dann ist es egal ;-)
Ja, ich guck' mal nach, was ich drin stehen habe. Meine Seiten sind schon etwas angegraut.
Oder Du codierst _alle_ Umlaute, dann ist die Charset-Angabe eigentlich egal.
PS: Trotz 9.3 verwende ich immer noch iso-8859-15 als systemweiten Zeichensatz...
Hmmm... soll ich umstellen probieren? Bisher scheint das utf-8 sich ja nicht so grauslig negativ bemerkbar zu machen. Eine gnupg-Passphrase geht wohl deswegen nicht mehr; sie enthält Umlaute. Die andere funktioniert - keine Umlaute.
LANG=de_DE@euro gpg ...... müsste eine Änderung der Passphrase ermöglichen. Nur diesmal bitte ohne Umlaute ;-) Gruß Christian Boltz -- Und wenn du denkst dich mag niemand mehr, dann kommt der Christopher und siggt dich sehr. [Christopher Splinter in dag°]
Helga Fischer
Jetzt die Preisfrage: Wenn ich eine alte Datei von SuSE 8.2 nach SuSE 9.2 rüberkopiere, welche Codierung hat die Datei denn nun?
Diejenige, die sie auf der 8.2 hatte, denn die Dateien werden nicht automatisch konvertiert.
Und wenn ich jetzt auf der SuSE 9.2 drin rumarbeite, ist die Datei jetzt zweifach kodiert?
Ja, dann enthält sie ggfs. Zeichen, die mit latin1/latin9 kodiert sind und solche, die mit utf-8 kodiert sind. Philipp
Am Sonntag, 8. Mai 2005 18:55 schrieb Helga Fischer:
Hallo Liste,
jetzt wollte ich mir schnell mal eine Ergänzung für meine Website schreiben und mein Lieblingstool recode macht mir die Datei kaputt. recode sollte mir nur die Umlaute kodieren. Zum händisch tippen bin ich zu faul.
Vermutlich liegt das daran, daß die Datei unter eine SuSE 8.2 erstellt wurde und ich sie jetzt auf eine SuSE 9.2 rüberkopiert habe.
Was darf ich denn jetzt auf meine Hompäjtsch schaufeln, so daß meine Besucher einen heilen Text zu sehen bekommen? Am besten dieses Mist-utf8 ausknipsen? (Dazu gibt's eine Anleitung in der SDB).
Oder hab' ich da ein Stück Fortschritt verpasst?
Ich sehe keinen Grund warum utf-8 nicht auf eine Homepage sollte. Ich glaube sogar, eine Zunahme von utf-8 Webseiten zu bemerken, rein subjektiver Eindruck von mir. Vielleicht hilft Dir das bei der Entscheidung: http://de.wikipedia.org/wiki/Wikipedia:Browser-FAQ Grüße René
Hallo lga,
Helga Fischer
Hallo Liste,
jetzt wollte ich mir schnell mal eine Ergänzung für meine Website schreiben und mein Lieblingstool recode macht mir die Datei kaputt. recode sollte mir nur die Umlaute kodieren. Zum händisch tippen bin ich zu faul.
Vermutlich liegt das daran, daß die Datei unter eine SuSE 8.2 erstellt wurde und ich sie jetzt auf eine SuSE 9.2 rüberkopiert habe.
Was darf ich denn jetzt auf meine Hompäjtsch schaufeln, so daß meine Besucher einen heilen Text zu sehen bekommen? Am besten dieses Mist-utf8 ausknipsen? (Dazu gibt's eine Anleitung in der SDB).
Oder hab' ich da ein Stück Fortschritt verpasst?
Na ja, verpasst hast du den Fortschritt noch nicht, aber du stehst auf der Kippe, wenn du jetzt zurückruderst zu iso-8859-1(5). Deine Homapage sollte gültigen HTML Code enthalten, dann werden deine Besucher auch keine Probleme mit der Darstellung bekommen. :-) Also eifrig ü einfügen (lassen), dann klappt's auch mit den Besuchern. Zum Thema 'Unicode - Sinn oder Unsinn?' können wir ja mal einen gesonderten Thread einläuten. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:01443B53
Hallo Dieter, Am Sonntag 8 Mai 2005 19:30 schrieb Dieter Kluenter:
Helga Fischer
writes: [...] Was darf ich denn jetzt auf meine Hompäjtsch schaufeln, so daß meine Besucher einen heilen Text zu sehen bekommen? Am besten dieses Mist-utf8 ausknipsen? (Dazu gibt's eine Anleitung in der SDB).
Oder hab' ich da ein Stück Fortschritt verpasst?
Na ja, verpasst hast du den Fortschritt noch nicht, aber du stehst auf der Kippe, wenn du jetzt zurückruderst zu iso-8859-1(5). Deine Homapage sollte gültigen HTML Code enthalten, dann werden deine Besucher auch keine Probleme mit der Darstellung bekommen. :-) Also eifrig ü einfügen (lassen), dann klappt's auch mit den Besuchern.
Hmm... der Validator ist nicht so zufrieden und meckert 'Broken Fragments' an. So ganz stressfrei scheint das Ganze also doch nicht zu sein. Helga -- ## OpenSource-Werkstatt in Reutlingen -- http://www.eschkitai.de/ ## Etikette - Nein Danke? -- http://www.suse-etikette.de.vu/ ## Wer hilft? -- http://hsqldb.sourceforge.net/web/openoffice.html
Helga Fischer
Hallo Dieter,
Am Sonntag 8 Mai 2005 19:30 schrieb Dieter Kluenter:
Helga Fischer
writes: [...] Was darf ich denn jetzt auf meine Hompäjtsch schaufeln, so daß meine Besucher einen heilen Text zu sehen bekommen? Am besten dieses Mist-utf8 ausknipsen? (Dazu gibt's eine Anleitung in der SDB).
Oder hab' ich da ein Stück Fortschritt verpasst?
Na ja, verpasst hast du den Fortschritt noch nicht, aber du stehst auf der Kippe, wenn du jetzt zurückruderst zu iso-8859-1(5). Deine Homapage sollte gültigen HTML Code enthalten, dann werden deine Besucher auch keine Probleme mit der Darstellung bekommen. :-) Also eifrig ü einfügen (lassen), dann klappt's auch mit den Besuchern.
Hmm... der Validator ist nicht so zufrieden und meckert 'Broken Fragments' an. So ganz stressfrei scheint das Ganze also doch nicht zu sein.
Das kann eigentlich nicht sein, oder du hast zusätzlich noch weitere Code Elemente, Die ersten 128 Zeichen von Unicode und ASCII, also Byte 0x00 bis 0x7F, sind identisch, erst ab darüber hinaus, also 2 Byte und mehr, sind dann unterschiedlich, abgesehen davon dass ASCII keine 2 Byte Zeichen kennt :-) -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:01443B53
Helga Fischer schrieb:
Hmm... der Validator ist nicht so zufrieden und meckert 'Broken Fragments' an. So ganz stressfrei scheint das Ganze also doch nicht zu sein.
Wie es aussieht, hast Du die Dateien mit einem Editor bearbeitet, der UTF-8 schreibt. Wenn eine solche Seite im Browser angezeigt wird und sie <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-15"> drin stehen hat, werden manche Zeichen, z.B. Umlaute, nicht korrekt dargestellt (ö, HÃ, Ã, ...). Einen ähnlichen Effekt dürfte es geben, wenn Du recode sagst, es soll Character-Entity-Referenzen für eine ISO-8859-15-kodierte Datei erzeugen, die in Wirklichkeit aber auch UTF-8-kodierte Zeichen enthält. Am einfachsten ist es, die Seiten korrekt zu kodieren, den Content-Tpe korrekt anzugeben und recode gar nicht zu verwenden. -- Gruß, Alex
Am Sonntag, 8. Mai 2005 21:59 schrieb Alexander Veit:
(...). Am einfachsten ist es, die Seiten korrekt zu kodieren, den Content-Tpe korrekt anzugeben und recode gar nicht zu verwenden.
BTW, der Content-Type vom Server hat Priorität vor dem in der HTML-Datei. Gruß, Jan -- If you do something right once, someone will ask you to do it again.
Jan Ritzerfeld schrieb:
BTW, der Content-Type vom Server hat Priorität vor dem in der HTML-Datei.
So steht es in http://www.w3.org/TR/html4/charset.html, Abschnitt 5.2.2 ;-) -Alex
participants (7)
-
Alexander Veit
-
Christian Boltz
-
Dieter Kluenter
-
Helga Fischer
-
Jan Ritzerfeld
-
Philipp Thomas
-
René Falk