escape(€)

[hotti]

siehe Thema,

auf meinem lokalen Server funktioniert die Übertagung mit ajax, beim Provider hingegen bleibt der serverseitige Prozess hängen, bzw. stürzt ab.

Das XHR-Objekt kommt mit einem Status != 200
   xhro.status != 200

escape() ist zwar deprecated, jedoch will ich damit noch ein paar Tests machen.

Fehlersuche:
JS Console gibt nichts aus

Hat jemand eine Idee woran es liegen könnte?

http://rolfrost.de/cgi-bin/ajaxtest.cgi

Hotti

[Jens Holzkämper]

Tach,

Hat jemand eine Idee woran es liegen könnte?

am CGI-Script

mfg
Woodfighter

[hotti]

Tach,

Hat jemand eine Idee woran es liegen könnte?

am CGI-Script

Stimmt, Du hast Recht ;-)

Serverseitig hab ich Perl und hab mittlerweile rausbekommen, dass es an
use URI::Escape;
print uri_escape($cin);

liegt, da bleibt das Script hängen, wenn der Euro kommt.... Mal gucken was ich noch so machen kann, es geht mir eigentlich nur darum, zu zeigen, was am Server ankommt und wie die Zeichen URL-encodet wurden. Werd mir wohl ne eigene Funktion schreiben müssen, die den Kram in hex umrechnet...

Hotti

[Struppi]

Serverseitig hab ich Perl und hab mittlerweile rausbekommen, dass es an
use URI::Escape;
print uri_escape($cin);

liegt, da bleibt das Script hängen, wenn der Euro kommt....

Das kann ich nicht nachvollziehen. Funktioniert bei mir Problemlos. Vielleicht ist die Version von URI::Escpae zu alt?

Struppi.

[hotti]

hi mein Guter,

Das kann ich nicht nachvollziehen. Funktioniert bei mir Problemlos. Vielleicht ist die Version von URI::Escpae zu alt?

Ja, irgendwas tut mit diesem schei? Modul nicht richtig ;-)

Wie gesagt, ich will Zeichen in der URI-Encodierung per ajax senden wie folgt:

default
escape
encodeURI
encodeURIComponent

also die Zeichen so übertragen

  
var cin = '';  
if(document.getElementById('euc').checked == true){  
	cin = encodeURIComponent(document.getElementById('cin').value);  
}  
else if(document.getElementById('eui').checked == true){  
	cin = encodeURI(document.getElementById('cin').value);  
}  
else if(document.getElementById('esc').checked == true){  
	cin = escape(document.getElementById('cin').value);  
}  
else{  
	cin = document.getElementById('cin').value;  
}  

, am liebsten ohne die Kontrollstruktur (nebeneinander), und als Response zurückgekommen, dem Besucher so zeigen wie die übertragen wurden <- dazu dient das uri_ecape().

Perl macht dazu das da:

  
my $cin = param('cin');  
print "Content-type: text/plain\n\n";  
print uri_escape($cin);  

um eben nicht das Zeichen selbst zurückzuschicken, sondern ein anschauliches %hex. Btw., wie der Euro mit escape('€') ankommt, ist Browserabhängig, das steht schonmal zweifelsfrei fest ;-)

Hotti

[Struppi]

Wie gesagt, ich will Zeichen in der URI-Encodierung per ajax senden wie folgt:

Das senden ist ja nicht das Problem, versuch's doch mal ohne AJAX, dann kannst du dir ja auch eine evtl. vorhandene Fehlermeldung anzeigen lassen

Struppi.

[Beat]

Perl macht dazu das da:

my $cin = param('cin');
print "Content-type: text/plain\n\n";
print uri_escape($cin);

  
Gib ein / mit encodeURI() ein.  
In diesem Fall gibt uri\_escape Perlseitig das anschaulich falsche zurück.  
  
Wenn du etwas demonstrieren willst, dann drucke einfach den Querystring aus.  
  
mfg Beat

-- 

><o(((°>           ><o(((°>  

   <°)))o><                     ><o(((°>o  
Der Valigator leibt diese Fische

[hotti]

hi,

Wenn du etwas demonstrieren willst, dann drucke einfach den Querystring aus.

Genau! Genau das ist nun der Workaround ;-)

POST auf GET umgestellt und Verzicht auf URI::Escape. QUERY_STRING parsen...

http://rolfrost.de/cgi-bin/ajaxtest.cgi

Hotti

[Struppi]

POST auf GET umgestellt und Verzicht auf URI::Escape. QUERY_STRING parsen...

So, ich hab mein Beispiel auch mal auf AJAX umgebaut.
http://jstruebig.de/cgi-bin/eurozeichen.pl funktioniert nach wie vor einwandfrei, das Euroziechen wird in allen drei kodierungsformen angenommen und von der Funktion uri_escape() entsprechend umgesetzt. In dieser Version existiert dein Problem also nicht.

Aber!

Hier lokal bekomme ich eine eindeutige Fehlermeldung:

Can't escape \x{20AC}, try uri_escape_utf8() instead at ..\eurozeichen.pl line 87

Diese Zeile betrifft genau dein Problem. Hast du mal uri_escape_utf8() probiert? Und warum läßt du dir nicht die Fehler ausgeben?Und

Struppi.

[MudGuard]

Hi,

Serverseitig hab ich Perl und hab mittlerweile rausbekommen, dass es an
use URI::Escape;
print uri_escape($cin);

Doku dazu:
Replaces each unsafe character in the $string with the corresponding escape sequence and returns the result. The $string argument should be a string of bytes. The uri_escape() function will croak if given a characters with code above 255.

Das Euro-Zeichen hat in Unicode einen Code deutlich über 255 ...

cu,
Andreas

[Struppi]

Das Euro-Zeichen hat in Unicode einen Code deutlich über 255 ...

Naja, bei mir funktioniert es

Struppi.

[MudGuard]

Hi,

Das Euro-Zeichen hat in Unicode einen Code deutlich über 255 ...

Naja, bei mir funktioniert es

Vielleicht hängt es ja auch daran, in welcher Codierung das Script selbst vorliegt?
In ISO-8859-15 hat das Euro-Zeichen einen Code unter 255 ...

cu,
Andreas

[Struppi]

Das Euro-Zeichen hat in Unicode einen Code deutlich über 255 ...

Naja, bei mir funktioniert es

Vielleicht hängt es ja auch daran, in welcher Codierung das Script selbst vorliegt?
In ISO-8859-15 hat das Euro-Zeichen einen Code unter 255 ...

Wieso das Eurozeichen kommt doch von der Seite die in utf-8 kodiert ist, exakt wie bei Rolf. Aber ich habe das Problem ja bereits gelöst, er hätte die Funktion encode_uri_utf8() verwenden müssen, was die Fehlermeldung schon sagt (sofern man sie sich anzeigen läßt)

Struppi.

[hotti]

hi Andreas,

Das Euro-Zeichen hat in Unicode einen Code deutlich über 255 ...

ja, schon möglich, aber der € kommt auf jeden Fall am Server an, wahrscheinlich als %u20AC. Ist mir jedoch (noch) nicht ganz klar. Auf jeden Fall kracht es in der Hin-und Hercodierung zwischen
escape('€') -> CGI.pm (uri_unescape) -> URI::Escape (uri_escape)
was möglicherweise auch an der Request_Method POST liegen könnte. Ich hab versucht, mach dem Parsen der Parameter mit CGI::param() den Handle STDIN direkt zu parsen, aber das ist mir nicht gelungen. tell(STDIN) zeigte mir zwar dasselbe wie CONTENT_LENGTH, was heißt, da steht was drin, zu sehen jedoch war da nix :(

Wie auch immer, mit GET und dem eigenen Parsen des QUERY_STRING (nicht mit CGI.pm) hab ich nun, was ich wollte, also unter Verzicht von uri_unescape/uri_escape ;-)

Viele Grüße,
Horst Hselhuhn

[Struppi]

ja, schon möglich, aber der € kommt auf jeden Fall am Server an, wahrscheinlich als %u20AC. Ist mir jedoch (noch) nicht ganz klar. Auf jeden Fall kracht es in der Hin-und Hercodierung zwischen
escape('€') -> CGI.pm (uri_unescape) -> URI::Escape (uri_escape)

Ich kann nur wiederholen - es kracht nur bei dir, in meinem Skript "kracht" nichts und das Zeichen wird kodiert und es ist dabei unerheblich ob ich GET oder POST verwende.

Struppi.

[hotti]

moin,

Ich kann nur wiederholen - es kracht nur bei dir, in meinem Skript "kracht" nichts und das Zeichen wird kodiert und es ist dabei unerheblich ob ich GET oder POST verwende.

Tja, mein Lieber, was Du vielleicht noch nicht weißt:

CGI::param() lässt von STDIN nix mehr übrig, außer einem Zeiger, der auf derselben Position steht wie CONTENT_LENGTH ;-)

Das ist ungefähr so, als hätte ein Ostfriese eingebrochen: Da ist der Dackel vergewaltigt und die Mülltonne leergefressen.

Viele Grüße nach Mainz!
Horst Haselhuhn

[Struppi]

Tja, mein Lieber, was Du vielleicht noch nicht weißt:

Natürlich weiß ich das, aber was hat das mit deinem Problem zu tun? Ich dachte es ging um uri_escape?
Das das CGI Modul den Input leer räumt, hat ja nichts damit zu tun, es sei denn du machst irgendwas, was du uns bisher aber nicht gesagt hast.

Struppi.

[hotti]

hi,

Das das CGI Modul den Input leer räumt, hat ja nichts damit zu tun, es sei denn du machst irgendwas, was du uns bisher aber nicht gesagt hast.

Mist, ist wohl doch nicht so rübergekommen ;-)

Also, ich will die Zeichen so darstellen, wie die übertragen werden per HTTP::POST, is ja eh nur Text. Und da wir nun wissen, dass CGI::param() den STDIN abräumt und uri_unescape verwendet, wärs doch doof von mir, wenn ich den Zeichensalat dann wieder mit uri_escape zurückdrehe. Da kannn ich doch gleich selbst den STDIN auslesen und das hab ich nun

Endlich auch fertig.

Viele Grüße,
Horst Hammersack

[Struppi]

Also, ich will die Zeichen so darstellen, wie die übertragen werden per HTTP::POST, is ja eh nur Text. Und da wir nun wissen, dass CGI::param() den STDIN abräumt und uri_unescape verwendet, wärs doch doof von mir, wenn ich den Zeichensalat dann wieder mit uri_escape zurückdrehe. Da kannn ich doch gleich selbst den STDIN auslesen und das hab ich nun

Genau. Das Problem liegt also nicht bei der Funktion, sondern daran, dass CGI sich um genau solche Sachen schon kümmert. Wie du an meinem Beispiel siehst, ist es dem Modul egal, wie du die Zeichen in JS kodierst. Ob unkodiert oder mit escape oder URIComponent, es kommt immer ein EURO Zeichen an.

Dein Problem war, dass die funktion uri_escape() anscheinend nicht immer mit den von escape() kodierten Parametern umgehen kann.

Struppi.

[hotti]

hi,

Dein Problem war [..]

Genau: War ;-)

Endlich fertisch, nun kann sowohl POST als auch GET getestet werden. Unter Verzicht auf CGI.pm ist nun auch zu sehen, was wirklich rüberkommt.

Viele Grüße,
Horst Lottermann

[Struppi]

Serverseitig hab ich Perl und hab mittlerweile rausbekommen, dass es an
use URI::Escape;
print uri_escape($cin);

liegt, da bleibt das Script hängen, wenn der Euro kommt....

Du hast die Doku auch mal durchgelesen?
http://search.cpan.org/~gaas/URI-1.52/URI/Escape.pm
Da steht z.b. sowas:
Note: Javascript has a function called escape() that produces the sequence "%uXXXX" for chars in the 256 .. 65535 range. This function has really nothing to do with URI escaping but some folks got confused since it "does the right thing" in the 0 .. 255 range. Because of this you sometimes see "URIs" with these kind of escapes. The JavaScript encodeURIComponent() function is similar to uri_escape_utf8().

Struppi.

[henman]

hallo,

siehe Thema,

auf meinem lokalen Server funktioniert die Übertagung mit ajax, beim Provider hingegen bleibt der serverseitige Prozess hängen, bzw. stürzt ab.

is klar, dass du lokal nichts bezahlen musst, als Provider würde ich aber auch nicht mitspielen ;P

grüße,
henman

[hotti]

moin,

is klar, dass du lokal nichts bezahlen musst, als Provider würde ich aber auch nicht mitspielen ;P

Früher hab ich kurz nach dem Eintreten in meine Stammkneipe immer laut gerufen: "Peter, Lokalrunde!"

(bei wenig Gäste...)

Lokal Horst