http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11944
--- Comment #40 from Jacek Ablewicz <[email protected]> --- So here and there we uri-escape some strings twice (mostly various search query parts, plus some more): - directly, by uri_escape_utf8() followed by '|url' or '|uri' TT filter, - indirectly, by using already uri-escaped string in <input value="..."> which will trigger 2nd uri-escape in browser The other way around, they are uri-unescaped twice too: first in CGI.pm and 2nd time directly by using uri_unescape in Search.pm etc. (including some places when they rather shouldn't; funny things might happen when searching for something with '%' in it..). But what's more important, delayed 2nd uri_unescape() would prevent those strings from being promoted to 'wide character' despite CGI qw(-utf8). This terribly dirty fix seems to resolve both problems mentioned in comment #13 (in OPAC search; staff search may need another one): diff --git a/opac/opac-search.pl b/opac/opac-search.pl index 7a35085..db0545e 100755 --- a/opac/opac-search.pl +++ b/opac/opac-search.pl @@ -387,7 +387,8 @@ if ($indexes[0] && !$indexes[1]) { } # an operand can be a single term, a phrase, or a complete ccl query my @operands = $cgi->param('q'); -@operands = map { uri_unescape($_) } @operands; +## Not a proper fix, just proof-of-concept!! +@operands = map { /%[a-f\d]{2}/i? Encode::decode('UTF-8', uri_unescape($_)): $_; } @operands; -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
