I have default value %get[name] on my webform.

If I access to form using a name with ASCII characters, it works nicely:
name=jack

Names with encoded non-ASCII characters don't work at all:
name=p%E4ivi
results in the name field being empty.

CommentFileSizeAuthor
#2 phpinfo.jpg54.59 KBputkonen

Comments

quicksketch’s picture

Status: Active » Postponed (maintainer needs more info)

I haven't been able to reproduce this issue. It may be an environmental difference (make sure you have the mb_string PHP extension installed on your server).

putkonen’s picture

Status: Postponed (maintainer needs more info) » Active
StatusFileSize
new54.59 KB

mbstring is installed. I'll attach a screenshot of the settings.

quicksketch’s picture

What is p%E4ivi supposed to be (unencoded)? I think there's just a problem with your string. If you run p%E4ivi through rawurldecode() you don't get a valid return character. I've tried this with all kinds of strings and languages, I don't have any problems.

putkonen’s picture

p%E4ivi = päivi.

You can verify this using:

http://www.albionresearch.com/misc/urlencode.php

quicksketch’s picture

Category: bug » support

päivi URL encoded is p%C3%A4ivi, not p%E4ivi. I don't know what algorithm that JavaScript converter is using, but it's not the same format used by PHP's urlencode() and urldecode().

putkonen’s picture

This is interesting.

According to this thread, this seems to be an issue with Firefox:
http://old.nabble.com/Firefox-URL-encoding-td5982793.html

%E4 = latin-1 encoding for ä, %C3%A4 UTF-8. Firefox converts the URL to latin-1 encoding, which does not work with PHP's urldecode.

It would be great if also latin-1 encoding could be supported, but now we can get around this issue. Thanks!

quicksketch’s picture

This is probably because the HTML on the page defines itself as UTF8, all URL encodings probably also have to be UTF8.

quicksketch’s picture

Status: Active » Fixed

It would be great if also latin-1 encoding could be supported

We're reading directly from the PHP $_GET variable and don't do any decoding at all, it's just PHP doing the decoding for us. Since there could be any number of encodings (who says it's going to be Latin-1 and not Unicode or MacRoman?), I think the correct solution is just to make sure the encodings are correct to begin with and let PHP handle it as it would normally.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.