(mod_)perl und Unicode

(mod_)perl und Unicode

am 13.09.2005 19:58:51 von andreas.hoehmann

Hallo NG,

ich suche Informationen zum Thema:

Unicode-Unterstützung für mod_perl Applikation mit Sybase-DB-Anbindung

Was muss ich beachten, Wie kann ich sowas in eine existierende
ISO-8859-* Applikation einbasteln (Daten umkonvertieren oder sind die
Unicode-Informationen unwiederbringlich futsch) usw.

Momentan hab ich halt eine stinknormale Perlanwendung, die eintreffende
Daten so wie sie sind in die DB schiebt (Class::DBI). Jetzt wäre es
halt mal an der Zeit auch != ASCII abzuspeichern, anzuzeigen usw. Ihr
merkt vielleicht schon an meiner Fragestellung, dass ich nicht genau
weiß WIE ich sowas machen kann bzw. wonach ich genau suchen müßte ;)

Viele Grüße
Andreas

Re: (mod_)perl und Unicode

am 14.09.2005 09:06:39 von Christian Kirsch

Andreas Höhmann wrote:
> Hallo NG,
>
> ich suche Informationen zum Thema:
>
> Unicode-Unterstützung für mod_perl Applikation mit Sybase-DB-Anbindung
>

Christian hat Dich in der anderen Gruppe doch schon auf die
Dokumentation zu Perl hingewiesen.

Welche konkreten Fragen bleiben nach deren Lektüre offen?

Re: (mod_)perl und Unicode

am 14.09.2005 10:10:26 von andreas.hoehmann

Christian Kirsch schrieb:
> Andreas Höhmann wrote:
>
>>Hallo NG,
>>
>>ich suche Informationen zum Thema:
>>
>>Unicode-Unterstützung für mod_perl Applikation mit Sybase-DB-Anbindung
>
> Christian hat Dich in der anderen Gruppe doch schon auf die
> Dokumentation zu Perl hingewiesen.
>

Auja. Sorry .. hab eben gelesen. Gestern war noch keine Antwort da.

> Welche konkreten Fragen bleiben nach deren Lektüre offen?

1. Gibt es durch den Einsatz von Unicode irgendwelche
"Performance-Verluste"? Die ganze Encoderrei in Perl
sieht irgendwie nach "aufgefropft" aus?!

2. Gibt es eine Möglich mit Hilfe von ein paar Befehlen, an zentraler
Stelle, eine bisher nicht-Unicode-fähige Perl-Applikation Unicode-
fähig zu machen. Ich möchte vermeinden, dass ich für jede Variable
einen "eigenen" En/Decoding-Aufruf starten muss (so ließt sich dass
jedenfalls für mich - bitte berichtigt mich wenn ich falsch liege)

Die Daten kommen ja (theoretisch) immer nur über CGI-Schnittstellen
in eine Webapp, dann werden sie irgendwie bearbeitet und landen
in der DB.

2.1. Muß ich an der DB etwas "besonderes" einstellen um meine
Applikation Unicode-fähig zu machen?

Später werden sie dann wieder aus der DB gelesen, verarbeitet und
an den Browser zurückgegeben.

2.2. Wie verhält es sich bei der Ausgabe per HTML (Ich verwende den
Template-Toolkit) - Muß ich hier die DB-Daten wieder in Unicode
verwandeln oder bleiben die im Unicode-Format, wenn ich sie
einmal encodiert habe?

Die beste Möglichkeit wäre es ja, wenn der User bestimmt, wie er die
Daten haben möchte oder? Wäre dass ein brauchbarer Ansatz aus Eurer
Sicht? (So nach dem Motto: Der Browser hat das Encoding XXXX
eingestellt, okay dann Encodieren wir mal alle "Ausgabedaten" in
dieses Format.

Und dann nochmal allgemeiner gefragt: gibt es irgendwo eine
Perl-basiernde Multilanguage-und-Unicode-unterstützende Applikation
von der man sich den Sourcecode reinziehen kann?? :D

Viele Grüße
Andreas

Re: (mod_)perl und Unicode

am 14.09.2005 11:06:20 von Christian Kirsch

Andreas Höhmann wrote:
> Christian Kirsch schrieb:
>
>>Andreas Höhmann wrote:
>>
>>
>>>Hallo NG,
>>>
>>>ich suche Informationen zum Thema:
>>>
>>>Unicode-Unterstützung für mod_perl Applikation mit Sybase-DB-Anbindung
>>
>>Christian hat Dich in der anderen Gruppe doch schon auf die
>>Dokumentation zu Perl hingewiesen.
>>
>
>
> Auja. Sorry .. hab eben gelesen. Gestern war noch keine Antwort da.
>
>
>>Welche konkreten Fragen bleiben nach deren Lektüre offen?
>
>
> 1. Gibt es durch den Einsatz von Unicode irgendwelche
> "Performance-Verluste"? Die ganze Encoderrei in Perl
> sieht irgendwie nach "aufgefropft" aus?!
>

Definiere "Einsatz". Ich verstehe nicht, was Du erreichen willst. Wenn
Du nur Unicode-Daten zwischen einer Datenbank und Perl hin- und
herschiebst (etwa für eine CGI-Anwendung), dann sollte das völlig egal
sein. Wenn Du REs benutzen willst, um in Unicode-Strings nach etwas zu
suchen, dann könnte es anders aussehen.

Andererseits: Warum fragst Du nach Performance? Ist sie schlecht?

> 2. Gibt es eine Möglich mit Hilfe von ein paar Befehlen, an zentraler
> Stelle, eine bisher nicht-Unicode-fähige Perl-Applikation Unicode-
> fähig zu machen. Ich möchte vermeinden, dass ich für jede Variable
> einen "eigenen" En/Decoding-Aufruf starten muss (so ließt sich dass
> jedenfalls für mich - bitte berichtigt mich wenn ich falsch liege)
>

Waf ift "Unicode-fähig"?

> Die Daten kommen ja (theoretisch) immer nur über CGI-Schnittstellen
> in eine Webapp, dann werden sie irgendwie bearbeitet und landen
> in der DB.
>
> 2.1. Muß ich an der DB etwas "besonderes" einstellen um meine
> Applikation Unicode-fähig zu machen?
>

Keine Ahnung. Das solltest Du Deinen Datenbank-Hersteller fragen.

> Später werden sie dann wieder aus der DB gelesen, verarbeitet und
> an den Browser zurückgegeben.
>
> 2.2. Wie verhält es sich bei der Ausgabe per HTML (Ich verwende den
> Template-Toolkit) - Muß ich hier die DB-Daten wieder in Unicode
> verwandeln oder bleiben die im Unicode-Format, wenn ich sie
> einmal encodiert habe?
>

Was hat das mit Perl zu tun?

> Die beste Möglichkeit wäre es ja, wenn der User bestimmt, wie er die
> Daten haben möchte oder?

That way lies madness.

> Wäre dass ein brauchbarer Ansatz aus Eurer
> Sicht? (So nach dem Motto: Der Browser hat das Encoding XXXX
> eingestellt,

Browser haben eigentlich kein Encoding eingestellt. Wozu auch? Das
Encoding ist eine Eigenschaft der HTML-Dokumente, die sie darstellen.

> okay dann Encodieren wir mal alle "Ausgabedaten" in
> dieses Format.
>

Tolle Idee. Und wie gehst Du damit in Deiner Datenbank um? Wenn
Lieschen ihre Daten als Latin-1, Karlchen seine als UTF-8 und Marek
seine als Latin-2 ablegt - wie möchtest Du dann ein
SELECT id, name FROM kunden ORDER BY name
in der Datenbank ausführen lassen?

> Und dann nochmal allgemeiner gefragt: gibt es irgendwo eine
> Perl-basiernde Multilanguage-und-Unicode-unterstützende Applikation
> von der man sich den Sourcecode reinziehen kann?? :D

Definiere "unterstützen".

In erster Linie solltest Du Dich vielleicht fragen, ob Du überhaupt
Unicode *brauchst*. Wenn Deine Anwendung nämlich nur Daten aus dem
mitteleuropäischen Sprachraum verarbeitet (das geht von Portugal über
Island, Finnland bis Lettland, schließt aber Griechenland, Polen,
Ex-Jugoslawien aus), dann ist Unicode doch völlig überflüssig.

Wenn Du aber darauf angewiesen bist, Daten aus mehreren Sprachräumen
zu verwenden (also etwa Mitteleuropa, Griechenland, Israel), dann
führt ohnehin kein Weg an Unicode vorbei. Folglich stellst Du sowohl
Deine HTML-Ausgabe per charset passend ein als auch Deine Datenbank
(sodass das Sortieren vernünftig funktioniert). Ob dann in Deinen
Perl-Scripts am Anfang noch "use utf8;" stehen muss oder nicht,
entnimmst Du am besten der Dokumentation (AFAIK hängt das auch von der
Perl-Version ab).

Re: (mod_)perl und Unicode

am 14.09.2005 12:49:07 von eck

Andreas Höhmann schrub im Jahre 14.09.2005 10:10:

> 1. Gibt es durch den Einsatz von Unicode irgendwelche
> "Performance-Verluste"? Die ganze Encoderrei in Perl
> sieht irgendwie nach "aufgefropft" aus?!

Eigentlich nicht. Ich benutze Perl 5.8, habe vorn use encoding 'utf8';
drin stehen und der Rest geht vollautomatisch als UTF8. Intern ist dann
sowieso alles utf8. Fertig.

Wenn man nicht-utf-8-Dateien einlesen will, dann setzt man halt per
binmode ":encoding(iso-8895-1)" oder was man gerade braucht.

Mehr ist da eigentlich nicht zu tun.

Die HTML::Entities haben noch ein paar kleinere Problemchen, aber
ansonsten bin ich selbst bei komplexeren Dingen auf keinerlei
Schwierigkeiten gestossen.

--
B.Eckstein, eck@ivu.de Cheap, Fast, Good - pick any two of them
Die FAQ zu de.comp.hardware.netzwerke: http://how.to/dchn
Mozilla-Tips: http://mozilla-anleitung.de/ http://www.holgermetzger.de/

Re: (mod_)perl und Unicode

am 14.09.2005 19:04:07 von andreas.hoehmann

Christian Kirsch schrieb:
>>
>>1. Gibt es durch den Einsatz von Unicode irgendwelche
>> "Performance-Verluste"? Die ganze Encoderrei in Perl
>> sieht irgendwie nach "aufgefropft" aus?!
>
> Definiere "Einsatz". Ich verstehe nicht, was Du erreichen willst. Wenn
> Du nur Unicode-Daten zwischen einer Datenbank und Perl hin- und
> herschiebst (etwa für eine CGI-Anwendung), dann sollte das völlig egal
> sein. Wenn Du REs benutzen willst, um in Unicode-Strings nach etwas zu
> suchen, dann könnte es anders aussehen.
>

Hab eine auf mod_perl basierende Webanwendung. Über CGI-Schnittstellen
kommen Daten rein und die (so wie es scheint) in unterschiedlichen
Codierungen und mit denen komme ich irgendwie nicht klar. Ich vermute
zumindest, dass es an Unicode (UTF8) liegt ... den folgender Effekt ist
zu beobachten.

Sagen wir mal ein User (aus Norwegen) hat in seinem Namen ein
paar "andere" Zeichen (ich kann die jetzt hier irgendwie gerade
nicht eingeben :D) ... okay ... er registriert sich bei mir ...
der Datensatz landet in der DB. Jetzt kuck ich als Admin (ebenfalls
Webfrontend) in meine Applikation und sehen nur "kommische"
Zeichen statt dieser "anderen" Zeichen.

> Andererseits: Warum fragst Du nach Performance? Ist sie schlecht?

Ich hatte da nur was gelesen ... dass Perl pro Unicode-Variable noch
ein zusätzliches Flag (intern) setzt. Und da frag ich mir halt ob das
irgendwie mehr Rechenleistung braucht, wenn es intern 2 unterschiedliche
Variablen-Typen verarbeiten muss.

>
>
>>2. Gibt es eine Möglich mit Hilfe von ein paar Befehlen, an zentraler
>> Stelle, eine bisher nicht-Unicode-fähige Perl-Applikation Unicode-
>> fähig zu machen. Ich möchte vermeinden, dass ich für jede Variable
>> einen "eigenen" En/Decoding-Aufruf starten muss (so ließt sich dass
>> jedenfalls für mich - bitte berichtigt mich wenn ich falsch liege)
>
> Waf ift "Unicode-fähig"?
>

Gute Frage :) Halt eine Web-Applikation die Eingaben aus aller Herren
Länder schön einheitlich in der DB ablegt und sie dann jedem User so
wieder darstellt, wie er es gewohnt ist.

>
> Browser haben eigentlich kein Encoding eingestellt. Wozu auch? Das
> Encoding ist eine Eigenschaft der HTML-Dokumente, die sie darstellen.
>

Ich meine "Ansicht->Zeichencodierung" usw.

>
>>okay dann Encodieren wir mal alle "Ausgabedaten" in
>> dieses Format.
>>
>
>
> Tolle Idee. Und wie gehst Du damit in Deiner Datenbank um? Wenn
> Lieschen ihre Daten als Latin-1, Karlchen seine als UTF-8 und Marek
> seine als Latin-2 ablegt - wie möchtest Du dann ein
> SELECT id, name FROM kunden ORDER BY name
> in der Datenbank ausführen lassen?

Genau! Du hast es erfaßt :) Irgendwie muss es doch einen bewährte
Möglichkeit geben wie man sowas macht. Dass mach ich doch nicht als
erster (hoff ich doch!). Man müßte die Daten in der DB in einem
einheitlichen Format speichern. Dabei sollte natürlich auch nix
an Information verloren gehen (damit meine ich diese 1 Byte / 2 Byte
ASCII/Unicode Geschichte).

> In erster Linie solltest Du Dich vielleicht fragen, ob Du überhaupt
> Unicode *brauchst*. Wenn Deine Anwendung nämlich nur Daten aus dem
> mitteleuropäischen Sprachraum verarbeitet (das geht von Portugal über
> Island, Finnland bis Lettland, schließt aber Griechenland, Polen,
> Ex-Jugoslawien aus), dann ist Unicode doch völlig überflüssig.

Genau mit den Norwegern habe ich eben ein Problemchen ... da hat jeder
zweite in seinem Namen ein "durchgestrichendes O" ;) Wie kann ich sowas
einheitlich abspeichern und dann auch wieder so anzeigen wie ER es
eingegeben hat?? Da kam mir der Sinn nach Unicode - wollte halt mal
wissen ob einer von Euch Spezialisten hier, mit sowas Erfahrung hat.

> Wenn Du aber darauf angewiesen bist, Daten aus mehreren Sprachräumen
> zu verwenden (also etwa Mitteleuropa, Griechenland, Israel), dann
> führt ohnehin kein Weg an Unicode vorbei. Folglich stellst Du sowohl

Drum.

> Deine HTML-Ausgabe per charset passend ein als auch Deine Datenbank
> (sodass das Sortieren vernünftig funktioniert). Ob dann in Deinen
> Perl-Scripts am Anfang noch "use utf8;" stehen muss oder nicht,
> entnimmst Du am besten der Dokumentation (AFAIK hängt das auch von der
> Perl-Version ab).

Also so in die Richtung dachte ich halt auch ... demnach müßte ich halt
immer vorm Versenden der HTML-Seite an den Kunden rausbekommen, was für
ein Encoding der gerade eingestellt hat und dementsprechend die Seite
"umcodieren" ODER liege ich da falsch und DER USER muss MEINE
Encodierung (die sich NIEMALS ändert) bei SICH einstellen - dass ist des
Puddels Kern denke ich :)


Viele Grüße

Andreas (der noch nie was mit Unicode gemacht hat *g*)

Re: (mod_)perl und Unicode

am 14.09.2005 19:07:00 von andreas.hoehmann

B.Eckstein schrieb:
> Andreas Höhmann schrub im Jahre 14.09.2005 10:10:
>
>
>>1. Gibt es durch den Einsatz von Unicode irgendwelche
>> "Performance-Verluste"? Die ganze Encoderrei in Perl
>> sieht irgendwie nach "aufgefropft" aus?!
>
>
> Eigentlich nicht. Ich benutze Perl 5.8, habe vorn use encoding 'utf8';
> drin stehen und der Rest geht vollautomatisch als UTF8. Intern ist dann
> sowieso alles utf8. Fertig.

Naja ... da bin ich mir halt ned so sicher ... aus der Perldoc:

encoding - allows you to write your script in non-ascii or non-utf8
^^^^^^^^^^^^^^^^^

Wie mein Skript programmiert ist, hat (so denke ich jedenfalls) doch nix
mit den Daten die ich verarbeiten muss zu tun oder?

Viele Grüße
Andreas

Re: (mod_)perl und Unicode

am 14.09.2005 19:09:17 von eck

Andreas Höhmann schrub im Jahre 14.09.2005 19:07:

> Wie mein Skript programmiert ist, hat (so denke ich jedenfalls) doch nix
> mit den Daten die ich verarbeiten muss zu tun oder?

ich habe ein ca. 2000 Zeilen grosses CGI-Script, das früher nur
ISO-8859-1 konnte. Das habe ich mit obigen einfachen Änderungen komplett
auf die Bearbeitung und Auslieferung von utf-8 umgestellt. Und wenn ich
Dateien einlesen muss, die nicht utf-8 sind, dann eben bein einlesen der
Datei mit binmode das encoding umstellen. Das war schon alles und läuft
bis dato einwandfrei.

--
B.Eckstein, eck@ivu.de Cheap, Fast, Good - pick any two of them
Die FAQ zu de.comp.hardware.netzwerke: http://how.to/dchn
Mozilla-Tips: http://mozilla-anleitung.de/ http://www.holgermetzger.de/

Re: (mod_)perl und Unicode

am 14.09.2005 19:29:04 von andreas.hoehmann

B.Eckstein schrieb:
> Andreas Höhmann schrub im Jahre 14.09.2005 19:07:
>
>
>>Wie mein Skript programmiert ist, hat (so denke ich jedenfalls) doch nix
>>mit den Daten die ich verarbeiten muss zu tun oder?
>
>
> ich habe ein ca. 2000 Zeilen grosses CGI-Script, das früher nur
> ISO-8859-1 konnte. Das habe ich mit obigen einfachen Änderungen komplett
> auf die Bearbeitung und Auslieferung von utf-8 umgestellt. Und wenn ich
> Dateien einlesen muss, die nicht utf-8 sind, dann eben bein einlesen der
> Datei mit binmode das encoding umstellen. Das war schon alles und läuft
> bis dato einwandfrei.
>

Krazz. Danke Dir für die Info ... muss ich einfach mal ausprobieren :D

Re: (mod_)perl und Unicode

am 18.09.2005 12:48:59 von hjp-usenet2

On 2005-09-14 19:04:07 +0200, Andreas Höhmann wrote:
> Christian Kirsch schrieb:
> >>
> >>1. Gibt es durch den Einsatz von Unicode irgendwelche
> >> "Performance-Verluste"? Die ganze Encoderrei in Perl
> >> sieht irgendwie nach "aufgefropft" aus?!
> >
> > Definiere "Einsatz". Ich verstehe nicht, was Du erreichen willst. Wenn
> > Du nur Unicode-Daten zwischen einer Datenbank und Perl hin- und
> > herschiebst (etwa für eine CGI-Anwendung), dann sollte das völlig egal
> > sein. Wenn Du REs benutzen willst, um in Unicode-Strings nach etwas zu
> > suchen, dann könnte es anders aussehen.
> >
>
> Hab eine auf mod_perl basierende Webanwendung. Über CGI-Schnittstellen
> kommen Daten rein und die (so wie es scheint) in unterschiedlichen
> Codierungen und mit denen komme ich irgendwie nicht klar.

Browser senden den Inhalt von Forms immer im gleichen Encoding wie das
HTML-Formular, das die Form enthalten hat (das ist m.W. nirgends so
definiert, aber alle Browser, die ich je getestet habe, verhalten sich
so).

Wenn Du also Deine Seiten mit "Content-Type: text/html; charset=utf-8"
generierst, bekommst Du vom Browser UTF-8 zurück. Wenn Du sie mit
"Content-Type: text/html; charset=iso-8859-1" generierst, bekommst Du
ISO-8859-1 zurück, etc. Wenn Du hingegen kein Charset angibst, muss der
Browser raten, was das sein könnte, und Du bekommst irgendwas zurück,
daher solltest Du das vermeiden.

Ich würde empfehlen, prinzipiell UTF-8 zu verwenden, da Du bei jedem
kleineren Charset das Problem hast, dass zumindest ein Teil Deiner User
Zeichen auf der Tastatur hat, die nicht in diesem Charset enthalten sind
(ISO-8859-1 enthält z.B. kein Euro-Zeichen, was soll der arme Browser
machen, wenn ein User in einem Text-Feld auf einer Seite in ISO-8859-1
ein Euro-Zeichen eintippt?)

Problematisch sind auch Nicht-ASCII-Zeichen in URLs. Es ist am besten,
die gleich entsprechend zu kodieren.


Zum CGI-Modul ist noch anzumerken, dass es (wenn sich nicht in letzter
Zeit etwas geändert hat) keine Möglichkeit zur automatischen Konversion
von Parametern kennt.

Angenommen, Du hast eine Seite in UTF-8 mit dem Formular



und der User gibt "€" ein,
dann schickt der Browser einen Request mit dem Parameter currency=%E2%82%AC
was Dir das CGI-Modul zu einem String mit 3 Zeichen
("\x{E2}\x{82}\x{AC}") dekodiert. Das Wissen, dass dieser String
UTF-8-kodiert sein muss, weil das Formular ebenfalls UTF-8-kodiert war,
musst Du als Applikationsprogrammierer beisteuern und explizit ein
decode("utf-8", $q->param("currency")) aufrufen, wenn Du einen
Perl-Character-String haben möchtest.

(Nebenbemerkung: Ich halte es für sehr sinnvoll, alle Strings, die eine
Applikation liest, so früh wie möglich in Perl-Character-Strings zu
konvertieren, und alle, die sie schreibt, so spät wie möglich in das
gewünschte Encoding zu konvertieren, und beide Konversionen in eigenen
Modulen zu kapseln - sonst muss man sich für jede Variable merken ob das
jetzt ein Character-String oder ein Bytestring ist, und wenn letzteres,
in welcher Kodierung - da kommt man sehr leicht durcheinander und
konvertiert zu oft oder zu selten)


> Ich vermute zumindest, dass es an Unicode (UTF8) liegt ... den
> folgender Effekt ist zu beobachten.
>
> Sagen wir mal ein User (aus Norwegen) hat in seinem Namen ein
> paar "andere" Zeichen (ich kann die jetzt hier irgendwie gerade
> nicht eingeben :D) ... okay ... er registriert sich bei mir ...
> der Datensatz landet in der DB. Jetzt kuck ich als Admin (ebenfalls
> Webfrontend) in meine Applikation und sehen nur "kommische"
> Zeichen statt dieser "anderen" Zeichen.

"komische Zeichen" ist keine besonders exakte Beschreibung. Ohne eine
genaue Angabe, welche Zeichen das sind, kann man da bestenfalls
unqualifiziert ins Blaue hineinraten.

> > Andererseits: Warum fragst Du nach Performance? Ist sie schlecht?
>
> Ich hatte da nur was gelesen ... dass Perl pro Unicode-Variable noch
> ein zusätzliches Flag (intern) setzt. Und da frag ich mir halt ob das
> irgendwie mehr Rechenleistung braucht, wenn es intern 2 unterschiedliche
> Variablen-Typen verarbeiten muss.

Perl hat intern noch viel mehr Variablentypen. Das steigert eher die
Performance, weil der jeweils passende Typ gewählt werden kann (Zahlen
als String abzuspeichern wäre z.B. ziemlich unperformant).
Allerdings stimmt es, dass UTF-8-kodierte Strings aufwendiger in der
Verarbeitung sind als byte-kodierte. In dem meisten Applikationen sollte
das aber vernachlässigbar sein.

> >>2. Gibt es eine Möglich mit Hilfe von ein paar Befehlen, an zentraler
> >> Stelle, eine bisher nicht-Unicode-fähige Perl-Applikation Unicode-
> >> fähig zu machen. Ich möchte vermeinden, dass ich für jede Variable
> >> einen "eigenen" En/Decoding-Aufruf starten muss (so ließt sich dass
> >> jedenfalls für mich - bitte berichtigt mich wenn ich falsch liege)
> >
> > Waf ift "Unicode-fähig"?
> >
>
> Gute Frage :) Halt eine Web-Applikation die Eingaben aus aller Herren
> Länder schön einheitlich in der DB ablegt und sie dann jedem User so
> wieder darstellt, wie er es gewohnt ist.

Datenbanken sind in der Hinsicht wieder ein eigenes Kapitel. Die
Methoden, mit denen Du einem Datenbanksystem mitteilst, welches
Character-Set Du wo zu verwenden gedenkst, sind bei jedem anders.


> > Browser haben eigentlich kein Encoding eingestellt. Wozu auch? Das
> > Encoding ist eine Eigenschaft der HTML-Dokumente, die sie darstellen.
> >
>
> Ich meine "Ansicht->Zeichencodierung" usw.

Ein Punkt, der aus den Menüs sämtlicher Browser verschwinden sollte. Da
kann der User eigentlich nur Sachen kaputtmachen :-(.


> >>okay dann Encodieren wir mal alle "Ausgabedaten" in
> >> dieses Format.
> >>
> >
> >
> > Tolle Idee. Und wie gehst Du damit in Deiner Datenbank um? Wenn
> > Lieschen ihre Daten als Latin-1, Karlchen seine als UTF-8 und Marek
> > seine als Latin-2 ablegt - wie möchtest Du dann ein
> > SELECT id, name FROM kunden ORDER BY name
> > in der Datenbank ausführen lassen?
>
> Genau! Du hast es erfaßt :) Irgendwie muss es doch einen bewährte
> Möglichkeit geben wie man sowas macht. Dass mach ich doch nicht als
> erster (hoff ich doch!). Man müßte die Daten in der DB in einem
> einheitlichen Format speichern. Dabei sollte natürlich auch nix
> an Information verloren gehen (damit meine ich diese 1 Byte / 2 Byte
> ASCII/Unicode Geschichte).

So ist es. Man sucht sich ein Charset aus, das alle benötigten Zeichen
enthält (mit Unicode/UTF-8 ist man auf der sicheren Seite, solange man
nicht Sumerisch oder so braucht) und speichert alles einheitlich in
diesem Charset.


> > In erster Linie solltest Du Dich vielleicht fragen, ob Du überhaupt
> > Unicode *brauchst*. Wenn Deine Anwendung nämlich nur Daten aus dem
> > mitteleuropäischen Sprachraum verarbeitet (das geht von Portugal über
> > Island, Finnland bis Lettland, schließt aber Griechenland, Polen,
> > Ex-Jugoslawien aus), dann ist Unicode doch völlig überflüssig.
>
> Genau mit den Norwegern habe ich eben ein Problemchen ... da hat jeder
> zweite in seinem Namen ein "durchgestrichendes O" ;)

Das ist aber in ISO-8859-1 enthalten, dafür brauchst Du kein Unicode.
Erst wenn Du sowohl Norweger als auch Tschechen als User hast, brauchst
Du Unicode. (ok, vielleicht ginge das sogar, ich bin jetzt zu faul,
nachzusehen, ob es ein Charset aus der ISO-8859-Familie gibt, das sowohl
die für Norwegisch als auch für Tschechisch benötigten Zeichen enthält)

> Wie kann ich sowas einheitlich abspeichern und dann auch wieder so
> anzeigen wie ER es eingegeben hat??

Indem man durchgehend Unicode/UTF-8 verwendet, und nicht versucht, für
jeden User was anderes zu verwenden.

> Da kam mir der Sinn nach Unicode - wollte halt mal wissen ob einer von
> Euch Spezialisten hier, mit sowas Erfahrung hat.

Ja.

> > Deine HTML-Ausgabe per charset passend ein als auch Deine Datenbank
> > (sodass das Sortieren vernünftig funktioniert). Ob dann in Deinen
> > Perl-Scripts am Anfang noch "use utf8;" stehen muss oder nicht,
> > entnimmst Du am besten der Dokumentation (AFAIK hängt das auch von der
> > Perl-Version ab).
>
> Also so in die Richtung dachte ich halt auch ... demnach müßte ich halt
> immer vorm Versenden der HTML-Seite an den Kunden rausbekommen, was für
> ein Encoding der gerade eingestellt hat und dementsprechend die Seite
> "umcodieren" ODER liege ich da falsch und DER USER muss MEINE
> Encodierung (die sich NIEMALS ändert) bei SICH einstellen - dass ist des
> Puddels Kern denke ich :)

Nein, musst Du nicht. Du schickst immer in einem Encoding, das Dir
genehm ist (der Einfachheit halber z.B. UTF-8), und teilst das dem
Browser im Content-Type-Header mit. Der Browser hat dann die Aufgabe,
das richtig anzuzeigen (die Browser können das auch).

hp

--
This is not a signature

Re: (mod_)perl und Unicode

am 18.09.2005 12:51:40 von hjp-usenet2

On 2005-09-14 19:09:17 +0200, B.Eckstein wrote:
> Andreas Höhmann schrub im Jahre 14.09.2005 19:07:
> >Wie mein Skript programmiert ist, hat (so denke ich jedenfalls) doch
> >nix mit den Daten die ich verarbeiten muss zu tun oder?
>
> ich habe ein ca. 2000 Zeilen grosses CGI-Script, das früher nur
> ISO-8859-1 konnte. Das habe ich mit obigen einfachen Änderungen
> komplett auf die Bearbeitung und Auslieferung von utf-8 umgestellt.

Dann konnte es das wohl schon vorher, und Du wusstest es nur nicht. "use
encoding 'utf8'" hat jedenfalls meines Wissens keine Auswirkungen auf
Ein- und Ausgabe.

hp

--
This is not a signature

Re: (mod_)perl und Unicode

am 19.09.2005 01:44:06 von Martin Mohr

Andreas Höhmann wrote:
> Unicode-Unterstützung für mod_perl Applikation mit Sybase-DB-Anbindung
>
> Was muss ich beachten, Wie kann ich sowas in eine existierende
> ISO-8859-* Applikation einbasteln (Daten umkonvertieren oder sind die
> Unicode-Informationen unwiederbringlich futsch) usw.

Intern werden die Daten ohnehin als eine Art Unicode gespeichert. Man
muss lediglich darauf achten, dass dort wo Daten hereinkommen oder
hinausgehen, das richtige Encoding verwendet wird. Andernfalls werden
die Daten verstümmelt und im Allgemeinen geht unwiederbringlich
Information verloren. Bei normalem IO kann man das beispielsweise mit
binmode(STDOUT,":utf8") erreichen. In deinem Falle handelt es sich um
die Übergabe der Daten an die Datenbank und den Empfang der Daten vom
CGI-Modul. Zweiteres stelle ich mir etwas haarig vor angesichts der
Vielzahl der möglichen Eingangskodierungen, die noch dazu häufig sicher
nicht oder sogar falsch deklariert sind. Gibt aber sicher gute Module dafür.

Martin

Re: (mod_)perl und Unicode

am 19.09.2005 19:54:52 von hjp-usenet2

On 2005-09-19 01:44:06 +0200, Martin Mohr wrote:
> In deinem Falle handelt es sich um die Übergabe der Daten an die
> Datenbank und den Empfang der Daten vom CGI-Modul. Zweiteres stelle
> ich mir etwas haarig vor angesichts der Vielzahl der möglichen
> Eingangskodierungen, die noch dazu häufig sicher nicht oder sogar
> falsch deklariert sind.

Sie sind im Normalfall gar nicht deklariert. Man kann nur hoffen, dass
der Browser das zurückschickt, was er bekommen hat. (Was allerdings den
Vorteil hat, dass man eben nicht zig Kodierungen unterstützen muss,
sondern nur eine).

hp

--
This is not a signature

Re: (mod_)perl und Unicode

am 20.09.2005 12:02:33 von Christian Kirsch

Peter J. Holzer wrote:

> Erst wenn Du sowohl Norweger als auch Tschechen als User hast, brauchst
> Du Unicode. (ok, vielleicht ginge das sogar, ich bin jetzt zu faul,
> nachzusehen, ob es ein Charset aus der ISO-8859-Familie gibt, das sowohl
> die für Norwegisch als auch für Tschechisch benötigten Zeichen enthält)
>
Mit Polnisch geht es wg. des durchgestrichenen l definitiv nicht: Das
gibt es nur in Latin-2, nicht ber in Latin-1. Wer also sowohl Polen
als auch Deutsche ansprechen will, braucht UTF-8

Re: (mod_)perl und Unicode

am 20.09.2005 18:16:14 von hjp-usenet2

On 2005-09-20 12:02:33 +0200, Christian Kirsch wrote:
> Peter J. Holzer wrote:
> > Erst wenn Du sowohl Norweger als auch Tschechen als User hast, brauchst
> > Du Unicode. (ok, vielleicht ginge das sogar, ich bin jetzt zu faul,
> > nachzusehen, ob es ein Charset aus der ISO-8859-Familie gibt, das sowohl
> > die für Norwegisch als auch für Tschechisch benötigten Zeichen enthält)
> >
> Mit Polnisch geht es wg. des durchgestrichenen l definitiv nicht: Das
> gibt es nur in Latin-2, nicht ber in Latin-1. Wer also sowohl Polen
> als auch Deutsche ansprechen will, braucht UTF-8

Die deutschen Umlaute und das scharfe s sind aber auch in Latin-2
enthalten. Somit wäre für deutsch und polnisch auch Latin-2 ausreichend.
Allerdings enthält Latin-2 ebenso wie Latin-1 kein Euro-Zeichen, das ist
m.W. nur in Latin-9 enthalten.

hp

--
This is not a signature

Re: (mod_)perl und Unicode

am 21.09.2005 11:10:53 von andreas.hoehmann

Peter J. Holzer schrieb:
> On 2005-09-20 12:02:33 +0200, Christian Kirsch wrote:
>
>>Peter J. Holzer wrote:
>>
>>>Erst wenn Du sowohl Norweger als auch Tschechen als User hast, brauchst
>>>Du Unicode. (ok, vielleicht ginge das sogar, ich bin jetzt zu faul,
>>>nachzusehen, ob es ein Charset aus der ISO-8859-Familie gibt, das sowohl
>>>die für Norwegisch als auch für Tschechisch benötigten Zeichen enthält)
>>>
>>
>>Mit Polnisch geht es wg. des durchgestrichenen l definitiv nicht: Das
>>gibt es nur in Latin-2, nicht ber in Latin-1. Wer also sowohl Polen
>>als auch Deutsche ansprechen will, braucht UTF-8
>
>
> Die deutschen Umlaute und das scharfe s sind aber auch in Latin-2
> enthalten. Somit wäre für deutsch und polnisch auch Latin-2 ausreichend.
> Allerdings enthält Latin-2 ebenso wie Latin-1 kein Euro-Zeichen, das ist
> m.W. nur in Latin-9 enthalten.
>
> hp
>

Lange Rede dumdidum ... also am besten gleich
Unicode ;) So soll es ja auch irgendwann mal sein
nehme ich an :D

Also was ich aus den ganzen Hinweisen rauslese:

1. Alle HTML-Seiten müssen ein enthalten
2. alle eintreffenden Daten müssen *nach* utf8 konvertiert
werden, da nicht sicher ist ob der Browser utf8 codierte
daten losschickt
3. in der DB gibt es dann nur noch utf8 (wobei ich noch
klären muss, ob Sybase dann auch "select ... name like '%ddd'"
kann usw.
4. für die Ausgabe der Dbrauch ich mir nix besonderes
einfallen lassen, da ja bereits alles in utf8 vorliegt (sobald
es einmal in meinem System [+DB] ist)

Doof ist hierbei nur, dass ich bereits ein laufendes System (+DB)
habe und dort bisher die Daten iso_1 (Sybase-Charset) abgelegt sind.
Ich müßte also für eine gewisse Übergangszeit alles was in der DB
steht vorm "Rausgeben" doch noch nach utf8 wandeln. Dass dabei bereits
Information verlorengegangen ist, ist sehr wahrscheinlich würde ich
meinen :(

Viele Grüße
Andreas

Re: (mod_)perl und Unicode

am 24.09.2005 11:40:46 von hjp-usenet2

On 2005-09-21 11:10:53 +0200, Andreas Höhmann wrote:
> Peter J. Holzer schrieb:
> Lange Rede dumdidum ... also am besten gleich
> Unicode ;)

ACK

> So soll es ja auch irgendwann mal sein nehme ich an :D
>
> Also was ich aus den ganzen Hinweisen rauslese:
>
> 1. Alle HTML-Seiten müssen ein enthalten
> 2. alle eintreffenden Daten müssen *nach* utf8 konvertiert
> werden, da nicht sicher ist ob der Browser utf8 codierte
> daten losschickt

Der Browser schickt das zurück, was Du ihm schickst. Wenn Du also 1.
machst, bekommst Du sicher UTF-8 zurück. (Außer der Browser ist kaputt
oder verkonfiguriert, in dem Fall kannst Du Dich aber ohnehin auf
nichts verlassen - insbesondere kannst Du nicht konvertieren, wenn Du
nicht weißt, was Du bekommst)

Konvertieren musst Du aber trotzdem. Denn Du bekommst einen Byte-Strom,
und Du willst daraus Character-Strings machen. Wenn Dein Norweger ein ø
eingibt, bekommst Du zwei Bytes ("\x{C3}\x{B8}"). Du willst aber
wahrscheinlich ein Zeichen ("\x{F8}") haben. Du musst also (mit
Encode::decode) den Bytestring zu einem Characterstring konvertieren
(dass Perl intern wieder UTF-8 verwendet, um Zeichen > 0xFF
darzustellen, ist in diesem Zusammenhang irrelevant - ein normales
Perlscript merkt das nämlich nicht)

> 3. in der DB gibt es dann nur noch utf8 (wobei ich noch
> klären muss, ob Sybase dann auch "select ... name like '%ddd'"
> kann usw.
> 4. für die Ausgabe der Dbrauch ich mir nix besonderes
> einfallen lassen, da ja bereits alles in utf8 vorliegt (sobald
> es einmal in meinem System [+DB] ist)

Jein. Möglicherweise (hängt vom Sybase-Treiber ab) musst Du auch die
Daten, die Du aus der Datenbank liest, von UTF-8 nach "Perl-Unicode"
umwandeln. Wenn Du nur Daten unverändert herumschaufeln willst, ist "es
ist eh alles UTF-8, ich brauche nichts zu tun" ein brauchbarer Ansatz.
Wenn Du aber z.B. Strings ändern, mit Regexps suchen, oder
sortieren willst, dann willst Du wahrscheinlich Perl-Character-Strings
verwenden, nicht UTF-8-kodierte Byte-Strings.

> Doof ist hierbei nur, dass ich bereits ein laufendes System (+DB)
> habe und dort bisher die Daten iso_1 (Sybase-Charset) abgelegt sind.
> Ich müßte also für eine gewisse Übergangszeit alles was in der DB
> steht vorm "Rausgeben" doch noch nach utf8 wandeln. Dass dabei bereits
> Information verlorengegangen ist, ist sehr wahrscheinlich würde ich
> meinen :(

Naja, was jetzt drin ist, ist drin. Daran kannst Du wohl nichts mehr
ändern, außer jemand liest das ganze Korrektur. Wenn Du aber ein
UTF-8-fähiges Webinterface mit einer Latin-1-Datenbank dahinter hast,
musst Du Dir überlegen, was passiert, wenn jemand ein Zeichen eingibt,
das nicht in Latin-1 enthalten ist. Der Norweger hat damit kein Problem,
aber der Pole aus Łodz ist vielleicht nicht glücklich, wenn seine
Heimatstadt als "?odz" abgespeichert wird (Oracle ersetzt alle
nicht-konvertierbaren Zeichen durch ein Fragezeichen - was Sybase macht,
weiß ich nicht).

hp

--
This is not a signature

Re: (mod_)perl und Unicode

am 30.09.2005 10:58:10 von andreas.hoehmann

Peter J. Holzer schrieb:
> On 2005-09-21 11:10:53 +0200, Andreas Höhmann wrote:
>
>>Peter J. Holzer schrieb:
>>Lange Rede dumdidum ... also am besten gleich
>>Unicode ;)
>
>
> ACK

Danke für deine Kommentare Peter, jetzt seh ich einigermassen durch :)

Viele Grüße @All
Andreas

Re: (mod_)perl und Unicode

am 30.09.2005 11:14:57 von andreas.hoehmann

Peter J. Holzer schrieb:
> On 2005-09-21 11:10:53 +0200, Andreas Höhmann wrote:
>
>>3. in der DB gibt es dann nur noch utf8 (wobei ich noch
>> klären muss, ob Sybase dann auch "select ... name like '%ddd'"
>> kann usw.
>>4. für die Ausgabe der Dbrauch ich mir nix besonderes
>> einfallen lassen, da ja bereits alles in utf8 vorliegt (sobald
>> es einmal in meinem System [+DB] ist)
>
> Jein. Möglicherweise (hängt vom Sybase-Treiber ab) musst Du auch die
> Daten, die Du aus der Datenbank liest, von UTF-8 nach "Perl-Unicode"
> umwandeln. Wenn Du nur Daten unverändert herumschaufeln willst, ist "es
> ist eh alles UTF-8, ich brauche nichts zu tun" ein brauchbarer Ansatz.
> Wenn Du aber z.B. Strings ändern, mit Regexps suchen, oder
> sortieren willst, dann willst Du wahrscheinlich Perl-Character-Strings
> verwenden, nicht UTF-8-kodierte Byte-Strings.
>

Ich hab eben nochmal bissl gegoogled ... und das Modul Class::DBI::utf8
gefunden. Da ich eh Class::DBI verwende, scheint mir dass die richtige
Stelle zu sein.

Mann mach dann wohl nur noch sowas hier:

__PACKAGE__->utf8_columns(qw( text ));