nicht angemeldet
Lösung für das leidige Umlautproblem bei Formularübergabe an PERL
Ich hatte eines der hier anscheinend am häugsten auftretenden Problemchen.
Ich wollte für meinen Onlineshop die Eingabewerte aus einem HTML-Bestellformular an ein PERL-Script übergeben, das die Bestellung verarbeiten soll, und gleichzeitig ein email wegschickt.
Bei Netscape gabs keine Probleme: Alle Umlaute wurden richtig aus dem Formular an PERL übergeben, aber der IE 5.0 verwendet anscheinend eine url-encoding, die alle Umlaute in verrückte Zeichen (wie z.B.: Ķ, oder Ö¤) umwandelt!
Nachdem ich mich in diesem Forum ein wenig umgesehen habe, hab ich zwar viel hilfreiches enzdeckt, aber ich war mir sicher, dass es für dieses Problem eine einfachere Lösung geben muss. Was ich hier gelesen habe war mir alles irgendwie zu kompliziert, um es schnell in meinen Shop einzubauen.
Da bin ich aber dann doch über eine Message gestolpert, die auf einen Thread verwies, in dem von Stefan Münz höchstpersönlich ein Suche/Ersetze-Script für Zeichenersetzungen zu finden ist. http://www.teamone.de/selfhtml/sfarchiv/1999_1/t02280.htm#a10577.
Ich hab mich an seine Lösung gehlten, und sie ein wenig auf mein Umlaut-Dilemma zugeschnitten, und das ist dabei herausgekommen. Ich habe folgenden Code in meine JavaScript Datei eingebaut:
// function parseString(text)
// {
// var new_text = "";
// for (var i = 0; i < text.length; i++)
// {
// if(text.charAt(i) == 'ü') { new_text += "ue"; }
// else if(text.charAt(i) == 'Ü') { new_text += "Ue"; }
//
// else if(text.charAt(i) == 'ö') { new_text += "oe"; }
// else if(text.charAt(i) == 'Ö') { new_text += "Oe"; }
//
// else if(text.charAt(i) == 'ä') { new_text += "ae"; }
// else if(text.charAt(i) == 'Ä') { new_text += "Ae"; }
//
// else if(text.charAt(i) == 'ß') { new_text += "ss"; }
// else new_text += text.charAt(i);
// }
// return new_text;
// }
Aufgerufen wird das ganze mit =>
// field.value = parseString(field.value);
und einer for-schleife, die über alle Formularfelder iteriert (ACHTUNG: Dazu gehören auch Felder der Typen "hidden", "button","reset", ....)
So schickt der Browser (HTML) statt ä's und ö's ,... ae's und oe's ,.... an den Server (PERL). In meinem Perl-Script habe ich dann eine Funktion eingebaut, die das ganze wieder rückgängig macht, und aus allen übergebenen Parametern sämtliche ae's und oe's , ... wieder in Umlaute zurückverwandelt!
// sub parseString()
// {
// $text =~ s/ae/ä/g; $text =~ s/Ae/Ä/g;
// $text =~ s/ue/ü/g; $text =~ s/Ue/Ü/g;
// $text =~ s/oe/ö/g; $text =~ s/Oe/Ö/g;
// }
Bem: $text hat den Text der in die Mail geschrieben werden soll zum Inhalt. Rückgabewert brauch ich keinen, da ja alle Variablen in PERL globale sind!! - toll, nicht?
Tja solche Lösungen gefallen mir: Einfach Schnell und Gut, aber einfallen muss sie einem erst - Danke Stefan !!
Ich hoffe ich konnte damit allen Umlaut-Opfern helfen, denn diese zwei Scripts sollten dieses (im Nachhinein) lächerliche Problem endgültig aus der Welt schaffen, oder wenigstens aus diesem Forum. Es gibt doch wirklich grössere Probleme als Umlaute zu übergeben, oder ;-)
-
hi bernhard,
verwendest du das CGI:: Modul?
Wenn ich mich recht entsinne, dann dürften damit keinerlei probleme auftreten
ciao k.-
Da ist ja doch noch wer, so spät am Abend,
Hallo K@rl !Selbstredend, natürlich verwende ich das CGI-Modul, zwar bloss für die Parameterübergabe, aber was solls, geht einfacher!
Es treten bei mir im Übrigen auch keine Probleme auf :->
Ich wollte mich quasi nur beim Forum bedanken, indem ich meine Variante beisteuere, und da ich gerade keinen Thread zu diesem Thema gefunden habe, um mein Glück mit euch zu teilen, hab ich einfach einen eigenen begonnen.
Das Problem lag auch nicht bei PERL: PERL hat alles gefressen, was man ihm (oder ihr?? - weiss man's) hingeworfen hat. Das Problem war: Der Internet Explorer ist böse: ER ist es, der die Umlaute in den Formularfeldern malträtiert. Netscape ist brav, dem is alles wurscht, gibt die Eingabe 1:1 an dern Server also das PERL-Programm weiter.
Es werden die Parameter also schon falsch vom Browser (IE5) aus dem HTML-file weggeschickt. Da hilft auch das CGI Modul nix. Außer es gibt eine Funktion in diesem Modul, die man explizit aufrufen muß.
Wenn es sowas wirklich gibt, wäre ich für eine Belehrung dankbar!!Oder ich irre mich, und es liegt doch nicht am url-encoding von IE, unwahrscheinlich jedoch möglich. Aber was solls - Es funktioniert.
Gibt es eigentlich eine Beschränkung für die Länge der Beiträge?
Bitte alle User dieses Forums hiermit um Entschuldigung, wenn ich euch mit meinen elendslangen Beiträgen bombadiere, ich schreib eben gern.
Sorry,
Bernhard-
hi,
Gibt es eigentlich eine Beschränkung für die Länge der Beiträge?
*g* ja, 12 KB
ein paar gedanken zu deinem script:
- was machst du, wenn tatsaechlich Doppelvokale wie ae, oe, oder ue auftauchen (wie zum Beispiel beim Wort "Residuen" oder bei Eigennamen beispielsweise...) ?
- deine (java-)script laeuft mit sicherheit nicht auf betriebssystemen, die eine andere (erweiterte) ascii-tabelle verwenden, da liegen naemlich die Umlaute an anderen Stellen - wenn ueberhaupt (ich hab keine ahnung von englischen systemen, aber beim mac z.b. liegen sie mit sicherheit woanders....)
nix fuer ungut....
cua
n.d.p.
-
Hi n.d.
Scheisse, und ich dachte schon ich bin toll :-(
Tja, an das hab ich natürlich nicht gedacht, Dass jemand z.B.: Huemer heissen könnte.Denke, da werd ich nochmal drüber grübeln müssen. Das mit den Ascii-Tabellen hab ich nicht wirklich kapiert, kenn mich da zuwenig aus, scheint mir aber unwahrscheinlich, da ich nichts mit Ascii-Codes mache, ändere einfach nur den Wert im Formularfeld (suche nach dem Character 'ü',...) - da müsste die Belegung der Ascii-Tabelle doch egal sein, oder ?
Vielleicht sollte ich einfach die ue's, und Ae's und Konsorten einfach sich selbst sein lassen, und im PERL-Script nicht wieder zurückkonvertieren - zwar nicht schön, aber ...
Ich werde zwar nicht gerne vor den Kopf gestossen, aber trotzdem danke für deinen Fingerzeig, hätte Ärger geben können, wenn ich das wirklich ins Netz gestellt hätte.
Kann man das Thema eines Threads eigentlich nachträglich ändern ?:-(
PS: Vielleicht hat ja jemand ne Idee, wie man das trotzdem hinkriegt!
Zieh mich jetzt zurück und verbleibe,
in tiefster Depression,
Bernhard-
re hi
Denke, da werd ich nochmal drüber grübeln müssen. Das mit den Ascii-Tabellen hab ich nicht wirklich kapiert, kenn mich da zuwenig aus, scheint mir aber unwahrscheinlich, da ich nichts mit Ascii-Codes mache, ändere einfach nur den Wert im Formularfeld (suche nach dem Character 'ü',...) - da müsste die Belegung der Ascii-Tabelle doch egal sein, oder ?
falsch, du suchst nicht nach dem charakter 'ü', sondern nach dem byte, was dem charakter 'ü' auf dem system entspricht, wo du den javascript-code reingehackt hast...verstaendlich ausgedrueckt?
Vielleicht sollte ich einfach die ue's, und Ae's und Konsorten einfach sich selbst sein lassen, und im PERL-Script nicht wieder zurückkonvertieren - zwar nicht schön, aber ...
PS: Vielleicht hat ja jemand ne Idee, wie man das trotzdem hinkriegt!du kannst natuerlich in unicode transfomieren - und danach wider zurueck - musst die entsprechenden markierungszeichen (& usw.) auch maskieren
Kann man das Thema eines Threads eigentlich nachträglich ändern ?:-(
ja: < http://www.teamone.de/selfaktuell/forum/forumsfaq.htm> :-)
cua
n.d.p.
-
Hi n.d.
Scheisse, und ich dachte schon ich bin toll :-(
Tja, an das hab ich natürlich nicht gedacht, Dass jemand z.B.: Huemer heissen könnte.Viel wahrscheinlicher als bei Eigennamen ist die Kombination "ue" in Woertern wie "neue" ...
Andreas Waechter (nein, nicht Waechter!!!)
-
Hi n.d.
Scheisse, und ich dachte schon ich bin toll :-(
Tja, an das hab ich natürlich nicht gedacht, Dass jemand z.B.: Huemer heissen könnte.Viel wahrscheinlicher als bei Eigennamen ist die Kombination "ue" in Woertern wie "neue" ...
Andreas Waechter (nein, nicht Waechter!!!)
He, was ist das, ich hatte in der Klammer den Waechter mit Umlaut geschrieben, nicht mit ae - werden die hier automatisch umgewandelt? Auch Woerter habe ich mit Umlaut geschrieben
-
Tja, frei nach Falco:
Der Komissar ist immer und überall !!
;-)
-
-
-
-
-
-
Hallo,
ich habe zwar nicht verstanden, wo es unter IE 5.0 ein Problem mit Umlauten in Formularen geben soll, aber wenn Du Sonderzeichen so kodieren willst, daß Du sie später wieder eindeutig dekodieren kannst, dann solltest Du die in JS eingebaute Funktion escape() verwenden. Hier ein Beispiel:
<javascript:alert(escape(prompt('Kodierungstest','Bitte was verrücktes eingeben')))>
Gruß,
Oliver
-
Hi Oliver,
Das Formular geht an ein PERL-Script. Kann man von dort aus die Daten mit unescape() wieder dekodieren ? Ist doch ein JavaScript-Befehl, oder gibts sowas auch in PERL?
Grüsse
Bernhard-
Hallo Bernhard,
Das Formular geht an ein PERL-Script. Kann man von dort aus die Daten mit unescape() wieder dekodieren ? Ist doch ein JavaScript-Befehl, oder gibts sowas auch in PERL?
"unescape" unter Perl gibt es nicht als solches, aber so:
$text =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack('C',hex($1))/eg;
Weiterhin werde ich aber nicht ganz schlau aus Deiner Problemstellung. Wenn im Browser ein Formular abgeschickt wird, dann wird vorher auf den Inhalt von Hause aus escape() angewandt (mit kleineren Abwandlungen, wie etwa, daß " " als "+" kodiert wird).
Deshalb solltest Du escape() nicht vorher nochmal auf die Formularinhalte anwenden, denn das wäre eine doppelte Kodierung.
Handelt es sich bei Deinem Problem darum, daß die _Elementnamen_ im Formular unter IE 5.0 nicht automatisch kodiert werden? Oder: Wo kann man sich im Netz mal ein Beispiel Deines Problems ansehen?Gruß,
Oliver
-
Hallo Oliver,
Erst mal Danke für deine Mühe mit mir!
Weiterhin werde ich aber nicht ganz schlau aus Deiner Problemstellung.
Handelt es sich bei Deinem Problem darum, daß die _Elementnamen_ im Formular unter IE 5.0 nicht automatisch kodiert werden?Nein, es geht nicht um die Elementnamen, es geht um das, was der User in das Formularfeld schreibt.
Wenn man z.B.: als Name "Hülöbäßer" im IE eingibt übergibt er "Hölübäßer" als Parameter an PERL. In NN übergibt er "üöäß".Auch mit deinem Tip ...
$text =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack('C',hex($1))/eg;
... hab ich es probiert, funktioniert aber auch nicht.Oder: Wo kann man sich im Netz mal ein Beispiel Deines Problems ansehen?
Wenn du Zeit und Lust hast wäre ich dir sehr dankbar!
< http://www.wt-akademie.at/skripten/_skmain.html>
Das Perl-Script(welches die Parameter auswertet) und die JavaScript-Datei(welche die Formular-Eingabe überprüft) hab ich als Textfiles unter
< http://www.wt-akademie.at/param_pl.txt> und
< http://www.wt-akademie.at/skripten/check_js.txt>Das PERL-Script lest bloss die einzelnen Parameter ein und gibt sie aus. Die Mail-Funktion hab ich auskommentiert, kannst ruhig herumprobieren!
Danke,
Bernhard-
Hallo Bernhard,
Weiterhin werde ich aber nicht ganz schlau aus Deiner Problemstellung.
Handelt es sich bei Deinem Problem darum, daß die _Elementnamen_ im Formular unter IE 5.0 nicht automatisch kodiert werden?Nein, es geht nicht um die Elementnamen, es geht um das, was der User in das Formularfeld schreibt.
Wenn man z.B.: als Name "Hülöbäßer" im IE eingibt übergibt er "Hölübäßer" als Parameter an PERL. In NN übergibt er "üöäß".Erstmal: ich habe das Verhalten von IE 5.0 jetzt einmal getestet und komme zu dem Ergebnis, daß er grundsätzlich - sowohl bei der GET- als auch bei der POST-Methode die Sonderzeichen erst einmal (richtig) kodiert und sie dann abschickt.
Daß das auf Deinen Seiten anders ist (wie ich auch festgestellt habe), kommt vermutlich daher, daß die Seite mit dem Formular selbst über JS generiert wurde (document.write). Vielleicht hilft es ja, wenn Du zusätzlich angibts: enctype="application/x-www-form-urlencoded"Auch mit deinem Tip ...
$text =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack('C',hex($1))/eg;
... hab ich es probiert, funktioniert aber auch nicht.Ich meinte nicht, daß damit die komischen Sonderzeichen zurückverwandelt werden können. Es handelt sich lediglich um die "unescape()"-Funktion bei Perl als Gegenstück für die escape()-Funktion unter JS, die ich für einen besseren Ansatz halte als die Lösung, die Du vorgeschlagen hattest (Umwandlung in oe, ae, etc.).
Eine einfacherer Lösung wäre es aber letztlich wohl, auf der Perl-Seite, alle "ö" in "ü", alle "ü" in ö" etc. umzuwandeln.
Gruß,
Oliver
-
Hallo Oliver,
Vielleicht hilft es ja, wenn Du zusätzlich angibts:
enctype="application/x-www-form-urlencoded".... hat leider nichts geholfen :-(
$text =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack('C',hex($1))/eg;
Ich meinte nicht, daß damit die komischen Sonderzeichen
zurückverwandelt werden können. Es handelt sich lediglich um
die "unescape()"-Funktion bei Perl als Gegenstück für die
escape()-Funktion unter JS..... hab mich ein wenig mit escape() herumgespielt und weiss jetzt endlich was escape() und infolgedessen dieser kryptische reguläre Ausdruck machen :-)
Eine einfacherer Lösung wäre es aber letztlich wohl, auf der
Perl-Seite, alle "ö" in "ü", alle "ü" in ö" etc. umzuwandeln.Das war der Vorschlag zum Tage: Ich könnt mich in den A... beissen, dass ich da nicht selber draufgekommen bin. Jetzt funktionierts einwandfrei. Es war für mich von Vornherein klar, dass mir PERL solche Zeichen (ö,ü,...) nicht durchgehen lässt, dass ich es erst gar nicht probiert habe. Tja, hätt ich besser doch machen sollen, hätte dir und mir viel Zeit erspart!
Aber aus Fehlern, und gerade aus so dummen, wird man schlauer. Und was mich ganz besonders positiv überrascht:
Die Hilfsbereitschaft, mit der sich in diesem Forum Profis um die Probleme der Anfänger kümmern. Ist echt nett von Euch!Ich stell die Seite morgen ins Netz
http://www.wt-akademie.at/skriptenDanke,
Bernhard
-
-
-
-
Das Formular geht an ein PERL-Script. Kann man von dort aus die Daten mit unescape() wieder dekodieren ? Ist doch ein JavaScript-Befehl, oder gibts sowas auch in PERL?
Ich weiss zwar nicht, wo Dein Problem mit den Umlauten liegt. Aber
use CGI;
dann brauchst Du soetwas ineffizientes wie Dein Javaskript sicherlich nicht.
Peter
-
-
-
Moin,
Bei Netscape gabs keine Probleme: Alle Umlaute wurden richtig aus dem Formular an PERL
übergeben, aber der IE 5.0 verwendet anscheinend eine url-encoding, die alle Umlaute in verrückte
Zeichen (wie z.B.: Ķ, oder Ö¤) umwandelt!das wäre mir neu. Ich verwende im Prinzip die Methode, die im Selfhtml-cgi Kapitel
als Perl-Beispielskript zu finden ist, was bisher immer sowohl mit IE5 als auch
Netscape funktioniert hat. Hast Du Windows 2000? Wenn ja, dann sind Deine
'verrückten Zeichen' wahrscheinlich Unicode-Darstellungen der Umlaute. Dafür
spricht auch, daß es immer zwei Zeichen statt einem sind. Guck Dir daher
mal die in Perl eingebauten Unicode-Module an.So schickt der Browser (HTML) statt ä's und ö's ,... ae's und oe's ,.... an den Server
(PERL). In meinem Perl-Script habe ich dann eine Funktion eingebaut,
die das ganze wieder rückgängig macht, und aus allen übergebenen Parametern sämtliche
ae's und oe's , ... wieder in Umlaute zurückverwandelt!// sub parseString()
// {
// $text =~ s/ae/ä/g; $text =~ s/Ae/Ä/g;
// $text =~ s/ue/ü/g; $text =~ s/Ue/Ü/g;
// $text =~ s/oe/ö/g; $text =~ s/Oe/Ö/g;
// }söben habe ich einen Fehler in Deinem Skript gefunden... ;-)
Viele Grüße
Andreas
-
Hallo!
das wäre mir neu. Ich verwende im Prinzip die Methode, die im Selfhtml-cgi Kapitel
als Perl-Beispielskript zu finden ist, was bisher immer sowohl mit IE5 als auch
Netscape funktioniert hat. Hast Du Windows 2000? Wenn ja, dann sind Deine
'verrückten Zeichen' wahrscheinlich Unicode-Darstellungen der Umlaute. Dafür
spricht auch, daß es immer zwei Zeichen statt einem sind.Der Meinung bin ich auch. Bernhard sollte mal die Zeichensatz-Einstellungen seines IE5 checken. Wenn er sie zurueck auf ISO-8859-1 stellt, gibt's da vermutlich keine Probleme mehr. Jedenfalls haengt das ganz sicher nicht mit URL-Encoding oder sowas zusammen.
Theoretisch muesste in einem CGI-Skript man irgendwie feststellen koennen, in welchem Zeichensatz die Daten vom Browser kommen. Leider ist mir dahingehend nichts bekannt. Aber vielleicht ist ja da doch irgendwas in den Umgebungsvariablen. Deshalb wuerde ich Bernhard mal bitten, dieses kleine Script hochzuladen, mit dem IE5 zu besuchen, und uns dann den Output hier zu posten.
#!/usr/bin/perl
print "Content-type: text/plain\n\n";
print "$_:\t\t$ENV{$_}\n" for (sort keys %ENV);söben habe ich einen Fehler in Deinem Skript gefunden... ;-)
Ausserdem muss auf dem Browser JavaScript laufen, was alles andere als selbstverstaendlich ist.
So long
-
Hallo!
Hast Du Windows 2000?
Nein
Der Meinung bin ich auch. Bernhard sollte mal die Zeichensatz-
Einstellungen seines IE5 checken. Wenn er sie zurueck auf ISO-8859-1
stellt, gibt's da vermutlich keine Probleme mehr. Jedenfalls haengt
das ganz sicher nicht mit URL-Encoding oder sowas zusammen.Ja gern, aber nur wo ??
Deshalb wuerde ich Bernhard mal bitten, dieses kleine Script
hochzuladen, mit dem IE5 zu besuchen, und uns dann den Output
hier zu posten.#!/usr/bin/perl
print "Content-type: text/plain\n\n";
print "$_:\t\t$ENV{$_}\n" for (sort keys %ENV);söben habe ich einen Fehler in Deinem Skript gefunden... ;-)
»»Ausserdem muss auf dem Browser JavaScript laufen, was alles andere als selbstverstaendlich ist.
Versteht sich doch!
Output:
AUTH_TYPE:
BLASTER: A220 I10 D1 H1 P300 T6
CMDLINE: WIN
COMSPEC: C:\WINDOWS\COMMAND.COM
CONTENT_LENGTH: 0
CONTENT_TYPE:
GATEWAY_INTERFACE: CGI/1.1
HTTP_ACCEPT: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, */*
HTTP_COOKIE:
HTTP_REFERER: http://127.0.0.1/cgi-bin/shop.pl?f=sk2
HTTP_USER_AGENT: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)
MIDI: SYNTH:1 MAP:E
PATH: C:\MyPrograms\httpd;C:\WINDOWS;C:\WINDOWS\COMMAND;C:\PERL\BIN;C:\WINDOWS\TWAIN_32\SCANWIZ;C:\MYPROG~1\HTTPD\PHP
PATH_INFO: /cgi-bin/test.pl
PATH_TRANSLATED: C:\MYPROGRAMS\HTTPD\CGI-BIN/test.pl
PROMPT: $p$g
QUERY_STRING: artnr=55&item=Personengesellschaftsrecht&amount=1&ats=170&eur=12.35&ats_sum=170&eur_sum=12.35&artnr=69&item=Pr%C3%BCf.+d.+Sachanlageverm%C3%B6gens&amount=1&ats=70&eur=5.09&ats_sum=70&eur_sum=5.09&vorname=%C3%BC%C3%BC%C3%BC%C3%BC%C3%9C%C3%9C%C3%9C%C3%9C&nachname=%C3%A4%C3%A4%C3%A4%C3%A4%C3%A4%C3%A4%C3%84%C3%84%C3%84&rechnungsadresse=%C3%B6%C3%B6%C3%B6%C3%B6%C3%B6%C3%96%C3%96%C3%96%C3%96&kanzlei=&Rechnung_an_Privat=on&plz=3567&ort=%C3%9F%C3%9F%C3%9F%C3%9F%C3%9F&staat=%C3%96sterreich&email=
REMOTE_ADDR: 127.0.0.1
REMOTE_HOST:
REMOTE_IDENT:
REMOTE_USER:
REQUEST_METHOD: GET
SCRIPT_NAME: /cgi-bin/test.pl
SERVER_NAME: localhost
SERVER_PORT: 80
SERVER_PROTOCOL: HTTP/1.1
SERVER_SOFTWARE: OmniHTTPd/2.06
SOUND: c:\MYPROG~1\SB16
TEMP: C:\WINDOWS\TEMP
TMP: C:\WINDOWS\TEMP
WINBOOTDIR: C:\WINDOWS
WINDIR: C:\WINDOWSKomisch, jetzt schreibt er den Windows-Unicode hin. Ich kenn mich jetzt gar nicht mehr aus. Hab mir den Tip von Oliver zu Herzen (und zur Tastatur) genommen, und es funktioniert, aber es würd mich schon interessieren, woran die ganze Palgerei liegt. Wenn mir das jemand sagen jönnte - wär toll!!
Seltsam ist auch, dass es (gestern) mit $text =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack('C',hex($1))/eg; ebenfalls nicht funktioniert hat, was, wenn ich mir den Query String so anschaue doch hätte funktionieren müssen. Aber ich habe gestern einfach soviel herumprobiert, bis es dann endlich funktioniert hat, und da war ich dann zufrieden!
So habe ich es jetzt gelöst: Bevor ich den Mail-Text ausgebe rufe ich folgende Funktion auf:
sub encode() {
$mail_rows =~ s/ä/ä/g; $mail_rows =~ s/Ä/Ä/g;
$mail_rows =~ s/ü/ü/g; $mail_rows =~ s/Ãœ/Ü/g;
$mail_rows =~ s/ö/ö/g; $mail_rows =~ s/Ã-/Ö/g;
$mail_rows =~ s/ß/ß/g;
}Meine Frage nun: wenn ich diese Funktion nicht aufrufe, schreibt er mir ä,ü,ö, usw. hin. Wenn man nochmal einen Blick auf den Query wirft, müsste er dann aber doch %BC%C3%9C% ausgeben oder?
Oder ist es vielleicht so, dass javascript seine Parameter mit unicode encoded, und PERL mit einer anderen Methode seine Parameter decoded, welche wiederum die Javascript-encoded Daten nicht decoden kann, und daher diese komischen Zeichen als ganz normale Characters decoded, wobei noch schlimmere Zeichen rauskommen? - Das war jetzt ziemlich unverständlich oder??
Wie übernimmt das CGI::Modul eigentlich die Parameter, wäre es vielleicht ohnehin gscheiter, den Query-String nur mit PERL (ohne CGI-Modul) zu übernehmen.
PS: Könnte mir vielleicht noch jemand erklären, was ich da gerade gemacht habe, und was da alles drinsteht ?? Iss ja arg viel Information !!
Verbleibe
in rasender Verzweiflung,
Bernhard-
Der Meinung bin ich auch. Bernhard sollte mal die Zeichensatz-
Einstellungen seines IE5 checken. Wenn er sie zurueck auf ISO-8859-1
stellt, gibt's da vermutlich keine Probleme mehr. Jedenfalls haengt
das ganz sicher nicht mit URL-Encoding oder sowas zusammen.Ja gern, aber nur wo ??
Keine Ahnung, hab keinen IE, und weiss nicht, wie man den konfiguriert.
Output:
AUTH_TYPE:
BLASTER: A220 I10 D1 H1 P300 T6
[ usw. ]
WINBOOTDIR: C:\WINDOWS
WINDIR: C:\WINDOWSTja, hab leider nichts verdaechtiges gefunden. Ich hatte gehofft, dass eine Variable wie CONTENT_TYPE gesetzt ist, aber das war wohl nichts.
Meine Frage nun: wenn ich diese Funktion nicht aufrufe, schreibt er mir ä,ü,ö, usw. hin. Wenn man nochmal einen Blick auf den Query wirft, müsste er dann aber doch %BC%C3%9C% ausgeben oder?
Das ist eben das, was der Ausdruck s/%([a-fA-F0-9][a-fA-F0-9])/pack('C',hex($1))/eg erledigt (siehe folgenden Text).
Oder ist es vielleicht so, dass javascript seine Parameter mit unicode encoded, und PERL mit einer anderen Methode seine Parameter decoded, welche wiederum die Javascript-encoded Daten nicht decoden kann, und daher diese komischen Zeichen als ganz normale Characters decoded, wobei noch schlimmere Zeichen rauskommen? - Das war jetzt ziemlich unverständlich oder??
Ich glaube, da liegt ein ziemliches Verstaendnisproblem bei Dir vor. Es ist einfach so, dass in einer URL nicht alle Zeichen erlaubt sind. Z.B. duerfen Leerzeichen oder Umlaute in einer URL nicht vorkommen. Will man solche Zeichen doch uebergeben, muss man sie auf der Clientseite codieren und auf der Serverseite wieder entsprechend decodieren. Das hat erstmal noch nichts mit dem Thema Unicode/Zeichensaetze zu tun, sondern ist einfach HTTP. Diese Codierung geschieht, indem man von dem Zeichen den hexadezimalen ASCII-Code nimmt, ein Prozentzeichen davorsetzt und das dann in die URL schreibt. Ein Leerzeichen hat den ASCII-Code 32 dezimal, das ist 20 hexadezimal, also wird es mit %20 in der URL notiert. (Ausgerechnet beim Leerzeichen ist es weitverbreitet, dieses nun doch nicht mit %20, sondern mit einem einfachen + zu codieren. Das ist aber nirgendwo standardisiert und sollte deshalb bei einem Encoding nicht verwendet werden, wohl aber beim Decoding unterstuetzt, um Kompatibilitaet zu gewaehrleisten.) Das %-Zeichen selbst wird dann mit %25 codiert, da 25 hex == 37 dez der Zeichencode dieses Zeichens ist. Wenn jetzt so eine URL bzw. so ein QueryString beim Server ankommt, muss der/die natuerlich decodiert werden, und das macht man in Perl gewoehnlich mit dem regulaeren Ausdruck s/%([a-fA-F0-9][a-fA-F0-9])/pack('C',hex($1))/eg. Das CGI-Modul macht uebrigens auch nichts anderes (nur darfst Du's natuerlich nicht nochmal machen, wenn dies vom modul bereits durchgefuehrt wurde).
Soweit funzt das normalerweise ganz gut, nur kommt jetzt das Zeichensatzproblem. Woher weiss man denn, welchen (ASCII-)Code ein Zeichen hat? Dafuer gibt es sog. Zeichensaetze, die den Zeichen Nummern zuordnen. ASCII ist nur einer von vielen Zeichensaetzen, allerdings sind die ersten 128 Zeichen (mit den Codes 0 bis 127) in fast allen Zeichensaetzen dieselben (dies gilt z.B. nicht fuer EBCDIC, aber wen interessiert das schon). Ab dem Code 128 allerdings unterscheiden sich die verschiedenen Charsets (= Character sets = Zeichensaetze). Einige davon findest Du auf <../../thb.htm>. Da hierzulande meist der iso-8859-1 set verwendet wird, wird z.B. ein ü gewoehnlich mit %FC (252) encodet.
Der von Dir verwendet Unicode-Zeichensatz ist nun aber ganz anders. Er verwendet fuer manche Zeichen nicht nur ein Byte pro Zeichen, sondern zwei. Deshalb kann er auch nicht nur 256 Zeichen darstellen, sondern... na jedenfalls mehr. Das heisst aber auch, dass Dein Browser gleich zwei Bytes codieren muss, um z.B. einen Umlaut im QueryString zu uebergeben. So hat er z.B. bei Dir aus einem Ö die Sequenz %C3%96 gemacht. Nun geht Dein Perlscript beim decodieren aber von einem Zeichensatz mit nur einem Byte aus. Deshalb wird diese Sequenz zu zwei Zeichen dekodiert, naemlich à und -.
Alles klar? ;-)
Ein bessere Moeglichkeit als Deine sub encode() (die vielleicht besser decode heissen sollte) weiss ich nun auch nicht. Leider fehlt ja die information, welcher Zeichensatz verwendet wird.
So long
-
Der Meinung bin ich auch. Bernhard sollte mal die Zeichensatz-
Einstellungen seines IE5 checken. Wenn er sie zurueck auf ISO-8859-1Hallo Calocybe,
Ich glaube, da liegt ein ziemliches Verstaendnisproblem bei Dir vor. Es ist einfach so, dass in einer URL nicht alle Zeichen erlaubt sind. Z.B. duerfen Leerzeichen oder Umlaute in einer URL nicht vorkommen. Will man solche Zeichen doch uebergeben, muss man sie auf der Clientseite codieren und auf der Serverseite wieder entsprechend decodieren.
Das hab ich gemeint, bloss verallgemeinere ich gern. Ich weiss auch dass der Reguläre Ausdruck genau diese %20 wieder in Leerzeichen zurückverwandelt, aber als ich mit deinem regulären Trick-Ausdruck gesehen habe, wie der Query-String ankommt, konnte ich mir einfach nicht erklären, wieso er diese komischen Zeichen ausspuckt, wo doch bei NN der string genauso aussieht, und auch das richtige ausgibt.
Wie das allerdings genau funktioniert mit den Ascii-Tabellen und dem ver_hexe_en hab ich vorher nicht gewusst, also danke an dieser Stelle!
Der von Dir verwendet Unicode-Zeichensatz ist nun aber ganz anders. Er verwendet fuer manche Zeichen nicht nur ein Byte pro Zeichen, sondern zwei. Deshalb kann er auch nicht nur 256 Zeichen darstellen, sondern... na jedenfalls mehr. Das heisst aber auch, dass Dein Browser gleich zwei Bytes codieren muss, um z.B. einen Umlaut im QueryString zu uebergeben. So hat er z.B. bei Dir aus einem Ö die Sequenz %C3%96 gemacht. Nun geht Dein Perlscript beim decodieren aber von einem Zeichensatz mit nur einem Byte aus. Deshalb wird diese Sequenz zu zwei Zeichen dekodiert, naemlich à und -.
Das heisst also, banal ausgedrückt, dass Perl nicht weiss, dass der Browser nicht den normalen Standard-Zeichensatz nach Iso-Norm 8... verwendet hat, sondern diesen ...... Sonder-Zeichensatz, den kein Schwein kennt ?!!
Und da er das natürlich nicht weiss, zerlegt er %c3%9C in %c3 und %9C also in 2 verschiedene Zeichen, und so entstehen also meine ä's, hab ich ungefähr recht?
Das heisst aber auch, dass ich da gar nix machen kann, denn wenn ein User mit nem vietnamesischen Zeichensatz auf meiner Seite was bestellen will .... Ich müsste für alle Sonderzeichen der gängigsten Zeichensätze (zum Beispiel für Französische) eine Ersetzungsroutine schreiben! Is ja irre.Bei einigen Seiten hab ich gesehen, dass es irgend ein meta-tag gibt, wo man den Zeichensatz für eine Seite vorgeben kann.
<meta name="charset" content="ISO-88..."> oder so ähnlich. Das werd ich noch ausprobieren, und wenn das auch nicht klappt, können mich die blöden Umlaute mal!Alles klar? ;-)
Scherzkeks :-(
Dankend,
Bernhard-
Hi again!
Das heisst also, banal ausgedrückt, dass Perl nicht weiss, dass der Browser nicht den normalen Standard-Zeichensatz nach Iso-Norm 8... verwendet hat, sondern diesen ...... Sonder-Zeichensatz, den kein Schwein kennt ?!!
Aeh.. ja, allerdings sind das beides ganz normale "gleichberechtigte" Zeichensaetze. Ist also nicht so, dass der iso-8859-1 was besonderes waere, er wird halt nur bei uns am haeufigsten eingesetzt, weil er alle unsere Umlaute enthaelt. Der Unicode ist dafuer gedacht, alle Zeichen auf der Welt in einem Zeichensatz zu halten. Ich glaube, derzeit sind so ca. 40000 Zeichen registriert. Aber da kenne ich mich auch nicht aus.
Das heisst aber auch, dass ich da gar nix machen kann, denn wenn ein User mit nem vietnamesischen Zeichensatz auf meiner Seite was bestellen will ....
Zumindest weiss ich nicht, was man da machen koennte.
Ich müsste für alle Sonderzeichen der gängigsten Zeichensätze (zum Beispiel für Französische) eine Ersetzungsroutine schreiben! Is ja irre.
Naja, das waere die Notloesung. Eine richtige finden wir ja leider nicht. (Wenn man erstmal weiss, welcher Zeichensatz verwendet wird, kann man das ordentlich decodieren, sofern man die entsprechenden Code-Tabellen hat.)
Bei einigen Seiten hab ich gesehen, dass es irgend ein meta-tag gibt, wo man den Zeichensatz für eine Seite vorgeben kann.
<meta name="charset" content="ISO-88..."> oder so ähnlich. Das werd ich noch ausprobieren, und wenn das auch nicht klappt, können mich die blöden Umlaute mal!<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
Das teilt dem Browser mit, dass in dieser Datei eben dieser Zeichensatz verwendet wird. Dadurch musst Du nicht mehr die Umlaute als ¨ schreiben, sondern kannst einfach ¨ schreiben. Wuesste der Browser den Zeichensatz nicht, so hat er ja nur die relativ bedeutungslose Zahl 252 vor sich (Computer denken in Zahlen, nicht in Zeichen, und so werden auch alle Daten uebertragen). Erst durch die Zeichensatzangabe weiss er, dass diese 252 soviel wie ü bedeutet. (Allerdings klappt es meist auch ohne die Meta-Angabe, weil bei uns ja sowieso standardmaessig eben iso-8859-1 verwendet wird.)Ob die Meta-Angabe auch Einfluss darauf hat, mit welchem Charset Formularinhalte abgeschickt werden, weiss ich nicht. Du koenntest es ja einfach mal ausprobieren.
So long
-
Hallo Calocybe
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
Das teilt dem Browser mit, dass in dieser Datei eben dieser Zeichensatz verwendet wird. Dadurch musst Du nicht mehr die Umlaute als ¨ schreiben, sondern kannst einfach ¨ schreiben.Na, das ist ja auch schon was, wird mir in Zukunft eine Menge Tipparbeit ersparen. Gut zu wissen!
Ob die Meta-Angabe auch Einfluss darauf hat, mit welchem Charset Formularinhalte abgeschickt werden, weiss ich nicht. Du koenntest es ja einfach mal ausprobieren.
Das werd ich machen!! Einen Versuch ist's wert
Ich glaube, bald werde ich anfangen von char-sets zu träumen, von Apostrophen, Umlauten, und sonstigen Sonderzeichen. Andere träumen von Claudia Schiffer. Aber was solls - kann man sich ja nicht aussuchen oder sagt Freud da was anderes?
Lasse es dich wissen, ob's funktioniert hat!!
Bis zum nächsten Mal ;-)
Bernhard
-
-
-
-
-
-