[Koha-bugs] [Bug 11944] Cleanup Koha UTF-8

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11944

--- Comment #40 from Jacek Ablewicz <abl at biblos.pk.edu.pl> ---
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');
- at operands = map { uri_unescape($_) } @operands;
+## Not a proper fix, just proof-of-concept!!
+ at 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.