Opened 13 years ago
Closed 13 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: |
Description
Hi,
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)
Change History (6)
Changed 13 years ago by
Attachment: | testDojo.html added |
---|
comment:1 Changed 13 years ago by
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 13 years ago by
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 13 years ago by
Hi,
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,
Vincent
comment:4 Changed 13 years ago by
Milestone: | tbd → 1.4 |
---|---|
Owner: | changed from anonymous to James Burke |
severity: | major → normal |
comment:5 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Simple example