Re^6: Confusing UTF-8 bug in CGI-script

ok, I follow.

Note that even if it seems to work, that doesn't make what you say correct. Depending on how the client encodes the request, the OP's code will work. That doesn't make it right.

I suspect one of two reasons for the differences:

Your client encoded the request such that the initial decoding is a no-op (e.g. it %-encodes every byte with the 8th bit set). You won't be so lucky with a different client.
Maybe your version of decode silently does nothing (instead of dieing) when it guesses a double-decode is being attempted. If so, that will make the OP's code work for all but unlikely inputs. But that means you're relying on decode to catch your bug.

Update: Cleaned up. Replaced first paragraph. (It was "Gotcha.", which is ambiguous.)

Comment on Re^6: Confusing UTF-8 bug in CGI-script Select or Download Code

Replies are listed 'Best First'.
Re^7: Confusing UTF-8 bug in CGI-script by Anonyrnous Monk (Hermit) on Feb 01, 2011 at 21:59 UTC
I suspect one of two reasons for the differences: ... Neither of those is the case. I've verified (by sending the request through a proxy) that the content is sent UTF-8 encoded (i.e. no %-encoding). And my Encode::decode also behaves normally (i.e. it would die with "Cannot decode string with wide characters"). This is, however, irrelevant, because CGI.pm has code to prevent double-decoding: `sub _decode_utf8 { my ($self, $val) = @_; if (Encode::is_utf8($val)) { return $val; } else { return Encode::decode(utf8 => $val); } }` [download] This sufficiently explains the behavior I observed and reported (for the input side).	[reply] [d/l]
Re^8: Confusing UTF-8 bug in CGI-script by ikegami (Patriarch) on Feb 02, 2011 at 01:51 UTC
Well, it's pretty damn close. I said Maybe your version of `decode` I should have said Maybe your version of the decoder	[reply] [d/l]