Tickets :: Comment on [#9567] charset pb replying to message

* Your Email Address
* Spam protection	Enter the letters below: . ..___.___.__ .__ \| \|[__ [__ [__)[__) \|/\\|\| \| \| \\|
Comment	>>> --- Xss.php.org 2011-03-15 10:41:22.000000000 +0100 >>> +++ Xss.php 2011-03-15 10:41:24.000000000 +0100 >>> - return Horde_String::convertCharset($text, $dom->encoding, >>> $this->_params['charset']); >>> + return $text; >> This isn't correct. Xss filter needs to return text in whatever >> charset it was provided in, which is why the convertCharset() call is >> necessary. The question is why $dom->encoding is 'ISO-8859-1' for >> you and 'UTF-8' for everybody else. > > If we assume that information from this link > http://devzone.zend.com/article/8855 are right, specifically section > 5 : "DOMDocument::saveXML($node) method is always performed in UTF-8" > > Then, no matter what $doc->encoding is set to, the following code > will always return a UTF-8 encoded string : > if ($body && $body->hasChildNodes()) { > foreach ($body->childNodes as $child) { > $text .= $dom->dom->saveXML($child); > } > } > > So, I think that Horde_Text_Filter_Xss::postProcess should be patch > like this : > > - return Horde_String::convertCharset($text, $dom->encoding, > $this->_params['charset']); > + return Horde_String::convertCharset($text, 'UTF-8', > $this->_params['charset']); > > > Now, why $dom->encoding is different on my machine than yours, I > don't have the answer (and I tried a lot of things). but according to > http://devzone.zend.com/article/8855, Section 4, > DOMDocument::loadHTML() should detect meta tag 'charset', and on my > system, it does (I guess) and this should explain as why > $dom->encoding=iso-8859-1 (or whatever charset the meta tag is set > to, see other comments). > > > As I think that the above small patch is right, I don't mind if some > of the other dev can try to reply to the message 'email_charset.eml' > to see if I'm really alone on this one. > > Thanks. > >
Attachment
Watch this ticket

Saved Queries