Hallo,

Also ich habe da eher eine Verständnisfrage, und zwar bin ich gerade dabei einen Webshop zu konfigurieren der im großen und ganzen auf CGI (Perl) basiert. Ich habe den Shop nicht selbst enwickelt und der der technische Support ist eher mau..

Jedenfalls scheinen die Scripte bzw. die darin enthaltenen Zeichen alle nach ISO-8859-1 codiert zu sein und wenn ich versuche den Shop auf einem Kubuntu (mit Apache/CGI usw) zu installieren bei welchem locale-gen auf UTF8 gesetzt sind, dann bekomme ich immer Fehlermeldungen vom Apache.

Auf einem anderen System welches mit locale-gen ISO-8859-1 auf den deutschen Zeichenzatz geändert wurde bestehen diese Probleme nicht.

kann es also sein, dass die Spracheinstellung des Systems die Funktionalität von CGI.- oder Perl-Scripten beinflussen?

Vielen Dank schon mal.

technohead schrieb:

Jedenfalls scheinen die Scripte bzw. die darin enthaltenen Zeichen alle nach ISO-8859-1 codiert zu sein und wenn ich versuche den Shop auf einem Kubuntu (mit Apache/CGI usw) zu installieren bei welchem locale-gen auf UTF8 gesetzt sind, dann bekomme ich immer Fehlermeldungen vom Apache.

Für die Kollegen, die Apache kennen, wären vermutlich die konkreten Fehlermeldungen hilfreich.

kann es also sein, dass die Spracheinstellung des Systems die Funktionalität von CGI.- oder Perl-Scripten beinflussen?

So allgemein: ja. Beispiel: der Interpreter liest ja Textdateien. Dafür muss er ein bestimmtes Encoding annehmen. Falls der Webshop dafür nicht vorsorgt, nimmt er halt die aktuelle Einstellung aus der Umgebung. Das kann dann schon mal schiefgehen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

irb(main):002:0> io = File.open "x", "w", encoding: "ISO-8859-1"
=> #<File:x>
irb(main):003:0> io.write "föö\n"
=> 4
irb(main):006:0> io.close
=> nil
irb(main):007:0> io = File.open "x", "r", encoding: "UTF-8"
=> #<File:x>
irb(main):008:0> x = io.read
=> "f\xF6\xF6\n"
irb(main):009:0> io.close
=> nil
irb(main):010:0> puts x
f▒▒
=> nil

Ciao

robert

Vielen Dank..

das bringt mich ein ganzes Stück weiter inzwischen habe ich herausgefunden, dass man mit der Option "AddDefaultCharset ISO-8859-1" den Apache auf ISO-8859-1 einstellen kann.

Die Fehlermeldung und das error.log vom Apache2 kann ich erst posten wenn ich nach Feierabend zuhause vor dem anderen Webserver sitze der bei ansonsten gleicher Konfiguration diese Server-Fehler produziert.

Ein schönes Beispiel, wieso man innerhalb von Programmen niemals mit Bytestrings arbeiten, sondern auf Unicode setzen sollte! Damit wäre es nur eine Einstellungssache, das richtige Encoding bei I/O-Operationen zu setzen.

Evtl. würde es also auch reichen, einfach die Scriptdateien per recode in utf-8 zu konvertieren? Wenn intern eh mit Bytestrings gearbeitet wird, dann sollte es ja auch mit utf-8 klappen. Damit würde man sich die Frickelei bezüglich der Umstellung der Umgebung sparen. Wäre vielleicht einen Versuch wert.

Lysander schrieb:

Ein schönes Beispiel, wieso man innerhalb von Programmen niemals mit Bytestrings arbeiten, sondern auf Unicode setzen sollte! Damit wäre es nur eine Einstellungssache, das richtige Encoding bei I/O-Operationen zu setzen.

Ich würde es anders formulieren: womit man im Programm arbeitet, ist erst mal egal; man muss sich der Thematik Encodings bei IO bewusst sein und entsprechend arbeiten. Wenn man das beachtet, dann kommt man automatisch darauf, dass auch die interne Repräsentation von Zeichenketten eine Obermenge aller Zeichen darstellen können muss, die in den bei IO verwendeten Encodings vorkommen.

Evtl. würde es also auch reichen, einfach die Scriptdateien per recode in utf-8 zu konvertieren? Wenn intern eh mit Bytestrings gearbeitet wird, dann sollte es ja auch mit utf-8 klappen. Damit würde man sich die Frickelei bezüglich der Umstellung der Umgebung sparen. Wäre vielleicht einen Versuch wert.

Es scheint ja so zu sein, dass sich die Autoren des Webshops der Thematik nicht ganz bewusst waren, oder? Ohne die Software zu kennen würde ich von solchen Operationen lieber erst mal Abstand halten. Sowas müsste man dann z.B. auch bei jedem Upgrade manuell machen. Und das sind die Sachen, die man typischerweise vergisst.

Ciao

robert

rklm schrieb:

Ich würde es anders formulieren: womit man im Programm arbeitet, ist erst mal egal; man muss sich der Thematik Encodings bei IO bewusst sein und entsprechend arbeiten. Wenn man das beachtet, dann kommt man automatisch darauf, dass auch die interne Repräsentation von Zeichenketten eine Obermenge aller Zeichen darstellen können muss, die in den bei IO verwendeten Encodings vorkommen.

Naja, genau das ist doch Unicode Natürlich könnte ich auch ein gleich mächtiges Encoding wie utf-8, -16 oder -32 verwenden - aber aus Effizienzgründen ist das sicherlich nicht ratsam.

Es scheint ja so zu sein, dass sich die Autoren des Webshops der Thematik nicht ganz bewusst waren, oder? Ohne die Software zu kennen würde ich von solchen Operationen lieber erst mal Abstand halten. Sowas müsste man dann z.B. auch bei jedem Upgrade manuell machen. Und das sind die Sachen, die man typischerweise vergisst.

Das ist natürlich ein Argument.

Lysander schrieb:

rklm schrieb:

Ich würde es anders formulieren: womit man im Programm arbeitet, ist erst mal egal; man muss sich der Thematik Encodings bei IO bewusst sein und entsprechend arbeiten. Wenn man das beachtet, dann kommt man automatisch darauf, dass auch die interne Repräsentation von Zeichenketten eine Obermenge aller Zeichen darstellen können muss, die in den bei IO verwendeten Encodings vorkommen.

Naja, genau das ist doch Unicode

Nein, das ist nicht richtig, denn

1. wenn an allen Stellen ISO-8895-1 verwendet wird, dann ist auch ISO-8895-1 eine Obermenge aller verwendeten Encodings und man kann auch eine achtbittige interne Repräsentation wählen; Unicode würde dann mehr bieten als man braucht.

2. es gibt - insbesondere im asiatischen Raum - Encodings, die nicht komplett in Unicode darstellbar sind, d.h. Unicode definiert nicht für alle Zeichen dieser Encodings einen Codepoint.

Hier im Westen kommt man mit Unicode recht weit. Aber m.E. ist es wichtiger, sich der Thematik I18N bewusst zu sein, um dann seine Software entsprechend zu schreiben. Nur dann wird man z.B. auch in der Dokumentation auf Beschränkungen hinweisen können.

Ciao

robert

rklm schrieb:

Nein, das ist nicht richtig, denn

1. wenn an allen Stellen ISO-8895-1 verwendet wird, dann ist auch ISO-8895-1 eine Obermenge aller verwendeten Encodings und man kann auch eine achtbittige interne Repräsentation wählen; Unicode würde dann mehr bieten als man braucht.

Du hast Recht; Unicode wäre (fast) die Potenzmenge aller Encodings. Die Frage wäre dann: Wieso drauf verzichten wollen?

1. es gibt - insbesondere im asiatischen Raum - Encodings, die nicht komplett in Unicode darstellbar sind, d.h. Unicode definiert nicht für alle Zeichen dieser Encodings einen Codepoint.

Ok, das ist mir in der Tat neu. Wobei das ja nicht an der Begrenztheit an Unicode liegen sollte, sondern eher an fehlender Zertifizierung? Und sobald diese Sprachen / Zeichen aufgenommen sind, kann mein Programm dann ohne Anpassung damit umgehen

Aber m.E. ist es wichtiger, sich der Thematik I18N bewusst zu sein, um dann seine Software entsprechend zu schreiben. Nur dann wird man z.B. auch in der Dokumentation auf Beschränkungen hinweisen können.

Hm... ich sehe den kausalen Nexus da ehrlich gesagt nicht. Ich kann im einfachsten Falle eine README oder man-Page auf Englisch verfassen - das ist eh universell. Die fixen Strings innerhalb des Codes sind eine Sache - der Umgang mit Daten eine ganz andere und mithin durchaus wichtigere; oder benutzt Du eingedeutschte Unix-CLI-Tools?

Lysander schrieb:

rklm schrieb:

Nein, das ist nicht richtig, denn

1. wenn an allen Stellen ISO-8895-1 verwendet wird, dann ist auch ISO-8895-1 eine Obermenge aller verwendeten Encodings und man kann auch eine achtbittige interne Repräsentation wählen; Unicode würde dann mehr bieten als man braucht.

Du hast Recht; Unicode wäre (fast) die Potenzmenge aller Encodings. Die Frage wäre dann: Wieso drauf verzichten wollen?

Muss man nicht. Ich wollte lediglich den Blick der Mitlesenden schärfen und weg von diesem dumpfen "nimm UTF-8 und alles ist in Butter". Das stimmt nämlich nicht. Man muss z.B. auch dafür sorgen, dass man die Encodings anwendet etc.

1. es gibt - insbesondere im asiatischen Raum - Encodings, die nicht komplett in Unicode darstellbar sind, d.h. Unicode definiert nicht für alle Zeichen dieser Encodings einen Codepoint.

Ok, das ist mir in der Tat neu. Wobei das ja nicht an der Begrenztheit an Unicode liegen sollte, sondern eher an fehlender Zertifizierung? Und sobald diese Sprachen / Zeichen aufgenommen sind, kann mein Programm dann ohne Anpassung damit umgehen

Es gibt zwei Aspekte:

1. Die Definition des Unicode-Standards wie sie vom Unicode Consortium vorgenommen wird.

2. Die Implementierung bzw. der Umfang der Unterstützung in einzelnen Sprachen / Libraries. Java speichert z.B. Zeichen mit 16 Bit. Das reicht nicht für Unicode komplett, weswegen sie später üble HacksFeatures hinzugefügt haben, bei denen dann ein Codepoint als int repräsentiert wird.

Aber m.E. ist es wichtiger, sich der Thematik I18N bewusst zu sein, um dann seine Software entsprechend zu schreiben. Nur dann wird man z.B. auch in der Dokumentation auf Beschränkungen hinweisen können.

Hm... ich sehe den kausalen Nexus da ehrlich gesagt nicht. Ich kann im einfachsten Falle eine README oder man-Page auf Englisch verfassen - das ist eh universell. Die fixen Strings innerhalb des Codes sind eine Sache - der Umgang mit Daten eine ganz andere und mithin durchaus wichtigere; oder benutzt Du eingedeutschte Unix-CLI-Tools?

Eben um den Umgang mit Daten geht es im Wesentlichen. Wichtig ist, sich mit dem Thema zu beschäftigen. Meiner Erfahrung nach machen es die meisten nicht, die es eigentlich sollten, da sie in einer stabilen Umgebung arbeiten.

Ciao

robert

rklm schrieb:

Muss man nicht. Ich wollte lediglich den Blick der Mitlesenden schärfen und weg von diesem dumpfen "nimm UTF-8 und alles ist in Butter".

Wobei utf-8 != Unicode - das verwechselt anscheinend die Mehrzahl von Anfängern.

Eben um den Umgang mit Daten geht es im Wesentlichen.

Ok, beim Stichwort I18N habe ich weniger die Daten (genauer: deren Encoding) im Fokus:-) Aber ich denke wir stimmen schon darin überein, dass man sich rund um das Thema Encoding Gedanken machen muss.

Lysander schrieb:

rklm schrieb:

Muss man nicht. Ich wollte lediglich den Blick der Mitlesenden schärfen und weg von diesem dumpfen "nimm UTF-8 und alles ist in Butter".

Wobei utf-8 != Unicode - das verwechselt anscheinend die Mehrzahl von Anfängern.

Ja, auch ein beliebter Fehler.

Eben um den Umgang mit Daten geht es im Wesentlichen.

Ok, beim Stichwort I18N habe ich weniger die Daten (genauer: deren Encoding) im Fokus:-)

Warum nicht? Das gehört doch auf jeden Fall dazu. Dazu gehört natürlich noch mehr - "Zeitzonen und Tageslichtrettungszeit" ist auch so ein schönes Thema...

Aber ich denke wir stimmen schon darin überein, dass man sich rund um das Thema Encoding Gedanken machen muss.

Unbedingt!

robert