http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10114 Bug ID: 10114 Summary: Double encoding problems caused by uri_escape_utf8 Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: m.de.rooy@rijksmuseum.nl Reporter: m.de.rooy@rijksmuseum.nl This is a followup on bug 6554. While looking at report 10107 that makes opac-search do a resubmit on itself while adding a biblio to a list, a search expression with diacritics suffers an encoding problem. Reproduce this by: search on musée, click on Save next to Add to list. Why does this occur only on the resubmit? This is interesting: At first glance I was inclined to find the cause in the different CGI request method: the first search submit is a POST, the second is a GET. But since opac-search already uses the -utf8 flag on CGI, this is not the cause. The cause is found little bit deeper: The template variable QUERY_INPUTS is reconstructed via $query_cgi, which comes from Search.pm. In that module buildQuery uses uri_escape_utf8 for $query_cgi. This function from URI::Escape encodes before escaping. Since we should only encode when finally sending to STDOUT, this creates double encoding on the diacritical search expression. This only shows up on the resubmit. Why? The search term normally goes via ms_value to the template into the search box. No problem. The mangled url is only used when resubmitting in the above described way. Solution: We should carefully examine all occurrences of uri_escape_utf8 (not that much) and replace them by uri_escape as long as they are in the scope of the template handling process. My first patch will handle the Search.pm occurrences. -- You are receiving this mail because: You are watching all bug changes.