In my application I have to deal with all sorts of garbage that poses as HTML. In this particular case, had an email that was encoded in Windows-847. The document had the following header:<br><div class="gmail_quote"><div>
<br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div><font face="courier new, monospace">&lt;html xmlns:v=&quot;urn:schemas-microsoft-com:vml&quot; xmlns:o=&quot;urn:schemas-microsoft-com:office:office&quot; xmlns:w=&quot;urn:schemas-microsoft-com:office:word&quot; xmlns:m=&quot;<a href="http://schemas.microsoft.com/office/2004/12/omml" target="_blank">http://schemas.microsoft.com/office/2004/12/omml</a>&quot; xmlns=&quot;<a href="http://www.w3.org/TR/REC-html40" target="_blank">http://www.w3.org/TR/REC-html40</a>&quot;&gt;&lt;head&gt;&lt;meta http-equiv=Content-Type <b><font color="#ff0000">content=&quot;text/html; charset=windows-874&quot;</font></b>&gt;&lt;meta name=Generator content=&quot;Microsoft Word 12 (filtered medium)&quot;&gt;</font></div>

</blockquote><div><br></div><div>The document then contained some text in thai. When attempting to parse this document, Closure-HTML gave me the following error:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">

<div><font face="courier new, monospace">Corrupted UTF-8 input (initial byte was #b10111110)</font></div></blockquote><div><br></div><div>It&#39;s pretty clear that this error message is expected, since the input isn&#39;t actually in UTF-8. It seems as though Closure-HTML is making an incorrect assumption here. Now, the proper way to handle this case would be to detect the<b> </b>&quot;content&quot; attribute in the &quot;html&quot; tag and reparse the text using the correct encoding.</div>

<div><br></div><div>Is this something that can be easily done? I haven&#39;t looked at the necessary code changes to do this myself (yet).</div><div><br></div><div>Regards,</div><div>Elias</div><div><br></div>
</div><br>