the ‘Experimental features’ messed with jQuery-UI datepicker l10n

[notxx]

it should look like this

and now it's like this

i think the root is base64'ed js file is not decoded using utf-8 charset.

[gorhill]

Is there a URL I can use to test for fixes?

[notxx]

http://jsfiddle.net/qo2o2s0j/

[notxx]

it looks like i've found the cure
change
data:application/x-javascript;base64,YWxlcnQoJ+a1i+ivlScp
into
data:application/x-javascript;charset=utf-8;base64,YWxlcnQoJ+a1i+ivlScp

then the javascript is decoded correctly.

check
http://jsfiddle.net/xf8ov1jj/
(sadly the jsfiddle editor is crushed by my code)

[gorhill]

data:application/x-javascript;charset=utf-8;

I want to investigate further, I can't do this blindly. Some data is binary, sometimes it may be a charset. I may have to revive code I had, to extract charset.

[notxx]

JavaScript are always text, and always have charset of ISO8859-1 or utf-8. so I think always using utf-8 charset for JavaScript is acceptable. 发自我的 iPhone

…

在 2014年11月12日，12:06，Raymond Hill <notifications@github.com> 写道： data:application/x-javascript;charset=utf-8; I want to investigate further, I can't do this blindly. Some data is binary, sometimes it may be a charset. I may have to revive code I had, to extract char encoding. — Reply to this email directly or view it on GitHub.

[gorhill]

It's not only javascript being mirrored, it's not only text being mirrored. I used to use charset before in the data: URI, until I converted to an ArrayBuffer. I will just bring back that code, which read the charset from the HTTP headers, not hard-coded.

I just wanted the real life scenario you encountered to inspect the HTTP header etc. to verify that all the information I need is in there in.

[notxx]

I could not find any public page with jqueryui l10n in Chinese or other eastern Asia locale. 发自我的 iPhone

…

在 2014年11月12日，20:25，Raymond Hill <notifications@github.com> 写道： It's not only javascript being mirrored, it's not only text being mirrored. I used to use charset before in the data: URI, until I converted to an ArrayBuffer. I will just bring back that code, which read the charset from the HTTP headers, not hard-coded. I just wanted a real life scenario to inspect the HTTP header etc. to verify that all the information is in there in the case you encountered. — Reply to this email directly or view it on GitHub.

[gorhill]

It's ok, your jsfiddle here works as a test case.

[gorhill]

Ok looking into this now.

Unfortunately, the charset is not specified in the response headers when receiving the resource through XHR. That is a problem. I suspect that normally, the browser will use the charset of the page, if one for the resource is not specified. But it looks like the browser may not be doing this for when the resource is from a data: URI. I feel like there is a browser issue here given the inconsistency.

I can't hard-code for UTF-8, because it could very well happen the resource is actually in another charset. Anyway as said above, I can't also just blindly add charset=, given that the resource may be something else than text (image/png, font/woff, etc.)

[gorhill]

I will go with some heuristic to figure whether charset=utf-8 can be slapped for when charset is not specified. Found some documentation which I will use as the rationale for now for the chosen solution:

5 . If the "getting an encoding" steps above return failure, then set encoding to null.

6 . If encoding is null, then set encoding to utf-8.

[gorhill]

This page says "with no charset (default should be US-ASCII)". If true, using UTF-8 seems entirely acceptable given UTF-8 intersects completely with ASCII over the ASCII set.

[notxx]

yeah. totally agree. 发自我的 iPhone

…

在 2014年11月21日，20:15，Raymond Hill <notifications@github.com> 写道： This page says "with no charset (default should be US-ASCII)". If true, using UTF-8 seems entirely acceptable given UTF-8 intersects completely with ASCII over the ASCII set. — Reply to this email directly or view it on GitHub.