Then I'm misunderstanding the suggestion then. My reading of:<div><br></div><div>"<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Therefore, we should be able to always use utf-8 for workers. Always using utf-8 is simpler to implement and test and encourages people to switch to utf-8 elsewhere."</span></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">...was "we should ignore charset headers coming from the server and always treat script data imported via importScripts() as if it were encoded as utf-8" (i.e. skip step 3 of section 4.3 of the web workers spec), which seems like it's effectively changing the default decoding.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Which means that someone naively serving up an existing Big5-encoded script (containing, say, string resources) with the appropriate charset header will find it fails when loaded into workers.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Again, apologies if I'm misunderstanding the suggestion.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">-atw<br>
</span></font><br><div class="gmail_quote">On Fri, Sep 25, 2009 at 10:21 AM, Anne van Kesteren <span dir="ltr"><<a href="mailto:annevk@opera.com">annevk@opera.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, 25 Sep 2009 19:16:47 +0200, Drew Wilson <<a href="mailto:atwilson@google.com" target="_blank">atwilson@google.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Certainly. If I explicitly override the charset, then that seems like<br>
reasonable behavior.<br>
</blockquote>
<br></div>
It does not need to be overridden per se. If the document character encoding is different from UTF-8 then a script loaded through <script> will be decoded differently from a script loaded through importScripts() as well.<div class="im">
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Having the default decoding vary between importScripts() and <script> seems bad, especially since you can't override charsets with importScripts().<br>
</blockquote>
<br></div>
This is already the case. The suggestion was not about changing the default.<div><div></div><div class="h5"><br>
<br>
<br>
-- <br>
Anne van Kesteren<br>
<a href="http://annevankesteren.nl/" target="_blank">http://annevankesteren.nl/</a><br>
</div></div></blockquote></div><br></div>