From aba2d83cc6c0273c30ae109b32c2ea404488116e Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Tue, 3 Feb 2009 14:52:26 -0500 Subject: [PATCH] Report XML::Feed bug and provide a workaround for IkiWiki; please review --- ...regated_Atom_feeds_are_double-encoded.mdwn | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 doc/bugs/Aggregated_Atom_feeds_are_double-encoded.mdwn diff --git a/doc/bugs/Aggregated_Atom_feeds_are_double-encoded.mdwn b/doc/bugs/Aggregated_Atom_feeds_are_double-encoded.mdwn new file mode 100644 index 000000000..c2d9e17ef --- /dev/null +++ b/doc/bugs/Aggregated_Atom_feeds_are_double-encoded.mdwn @@ -0,0 +1,22 @@ +The Atom feed from +get "double-encoded" (UTF-8 is decoded as Latin-1 and re-encoded as +UTF-8) when aggregated with IkiWiki on Debian unstable. The RSS 1.0 +and RSS 2.0 feeds from the same Planet are fine. All three files +are in fact correct UTF-8, but IkiWiki mis-parses the Atom. + +This turns out to be a bug in XML::Feed, or (depending on your point +of view) XML::Feed failing to work around a design flaw in XML::Atom. +When parsing RSS it returns Unicode strings, but when parsing Atom +it delegates to XML::Atom's behaviour, which by default is to strip +the UTF8 flag from strings that it outputs; as a result, they're +interpreted by IkiWiki as byte sequences corresponding to the UTF-8 +encoding. IkiWiki then treats these as if they were Latin-1 and +encodes them into UTF-8 for output. + +I've filed a bug against XML::Feed on CPAN requesting that it sets +the right magical variable to change this behaviour. IkiWiki can +also apply the same workaround (and doing so should be harmless even +when XML::Feed is fixed); please consider merging my 'atom' branch, +which does so. --[[smcv]] + +[[!tag patch]] -- 2.45.0