From 2ac7df0113732fb2b4dac2a0fc77ca3f837240e5 Mon Sep 17 00:00:00 2001 From: dbs Date: Fri, 15 Apr 2011 20:13:46 +0000 Subject: [PATCH] Protect dumb JavaScript engines from having to deal with actual Unicode The holdings_xml format did not include an XML declaration, but adding that as we do here still does not make the Firefox and Chromium JS engines capable of consuming XML that contains Unicode content outside of the base ASCII range. So, we invoke entityize() to convert anything outside of the realm of ASCII to XML entities. An alternative would be to invoke entityize() in OpenILS::Application::SuperCat::unAPI::acn but it's not clear if that would interfere with any other uses. With this change, library names / copy location names with Unicode content can be displayed correctly on the search results page. git-svn-id: svn://svn.open-ils.org/ILS/trunk@20112 dcc99617-32d9-48b4-a31d-7c20da2025e4 --- Open-ILS/src/perlmods/lib/OpenILS/WWW/SuperCat.pm | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/Open-ILS/src/perlmods/lib/OpenILS/WWW/SuperCat.pm b/Open-ILS/src/perlmods/lib/OpenILS/WWW/SuperCat.pm index 1e7c75a..a0dfea9 100644 --- a/Open-ILS/src/perlmods/lib/OpenILS/WWW/SuperCat.pm +++ b/Open-ILS/src/perlmods/lib/OpenILS/WWW/SuperCat.pm @@ -680,12 +680,19 @@ sub unapi { return 404; } - print "Content-type: application/xml; charset=utf-8\n\n$data"; + print "Content-type: application/xml; charset=utf-8\n\n"; + # holdings_xml format comes back to us without an XML declaration + # and without being entityized; fix that here if ($base_format eq 'holdings_xml') { + print "\n"; + print $U->entityize($data); + while (my $c = $req->recv) { - print $c->content; + print $U->entityize($c->content); } + } else { + print $data; } return Apache2::Const::OK; -- 1.7.2.5