Opened 12 years ago

Closed 12 years ago

#9584 closed defect (fixed)

ISO-8859-1 charset and xd build problem

Reported by: vincentastek Owned by: James Burke
Priority: high Milestone: 1.4
Component: General Version: 1.3.1
Keywords: charset xdomain build Cc: [email protected]
Blocked By: Blocking:



I'm in the final phase of integration of Dojo in my existing Struts framework.

I got big issue with xdomains build. Some of my users use ISO-8859-1 charsets on their web pages. With dojo src, or when accessing my build locally, I got no problem. But if I access my build with xdomain flag, like it will be in the production environment, I got charset issues, for example on dojo.number.format();

This is a problem for me, because I must keep a compatibility with my older versions that permit ISO charsets. The other problem is that DOJO doesn't react the same way in local access and in xdomain access concerning this issue, because in the future, I will have to debug potential problems locally, and I can't change every settings to fit xdomain or local environment. Ideally I will only change dojo path and djConfig xdomain flag.

Is there a way to specify to dojo that it must work exclusively in UTF-8, even if my page is in ISO-8859-1. I tried to specify an UTF-8 charset attribute on every dojo involved <script> tags, but that seems to have no effect. I suppose it should work, as every other UTF-8 javascript I use works in a ISO page if this attribute is correctly set.

Why xdomain file get and xhr file get don't behave the same way ?

I attach a simple example to illustrate this point. You just have to modify dojo path and comment/uncomment the first script lines to switch between xdomain and local dojo.

Charset of downloaded js files is the same on the two servers (local and distant), I precise.

Attachments (1)

testDojo.html (800 bytes) - added by vincentastek 12 years ago.
Simple example

Download all attachments as: .zip

Change History (6)

Changed 12 years ago by vincentastek

Attachment: testDojo.html added

Simple example

comment:1 Changed 12 years ago by Adam Peller

xdomain uses script tags to load code, which I believe may handle default charsets and document charsets differently than xhr, which according to the spec assumes UTF-8 when no HTTP headers are specified. You should be able to solve your problem by serving up your Dojo content on the server explicitly with the UTF-8 charset. Other content on your server can use a different charset as long as it's served up with the appropriate headers.

comment:2 Changed 12 years ago by vincentastek

My server serves the dojo js files in UTF-8 charset already (if I load the files independantly with FFX I can see they're recognized as UTF-8, and physical files are also UTF-8 encoded). How can I "explicitely" precise to dojo that the files it loaded are UTF-8 encoded ?

comment:3 Changed 12 years ago by vincentastek


I found the problem in dojo.xd.js

In uncompressed version of 1.3.1, it's at line 1409, in _loadUri() function. When creating the new <script> tag to import elements, I think it would be better to specify the charset on the <script> element.

If I replace :

element.type = "text/javascript";

by :

element.type = "text/javascript"; element.charset= "UTF-8";

that works correctly again.

Due to my experience with <script> tags and charsets, I think it's impossible to mix charsets without that. Even if the files are correct UTF-8, FFX (and IE I think) will always consider <script> tags without a charset attribute to be the same charset as the web page, and interpret them this way.

So I think, as dojo is using UTF-8, it should force this for every inclusion in xd mode, in order to be useable with web pages encoded in something else than UTF-8.

I will try to tweak that properly on my version, but I really hope this will be done in the future.

Thanks a lot for all the work on DOJO,


comment:4 Changed 12 years ago by James Burke

Milestone: tbd1.4
Owner: changed from anonymous to James Burke
severity: majornormal

comment:5 Changed 12 years ago by James Burke

Resolution: fixed
Status: newclosed

SVN not working. Fixed in [19077]: "Fixes #9584: use charset for xd script tags, allow for changing it, but not sure if that private option is strictly needed. Seems like the developer would have to go through some hoops to allow loading a non-utf8 module/building those modules."

Note: See TracTickets for help on using tickets.