utf-8

202 views
Skip to first unread message

Brian

unread,
May 10, 2013, 1:00:50 PM5/10/13
to js-test...@googlegroups.com
jstestdriver is choking on d3.js, because of the unicode characters. I suspect it's because of this header:

Content-Type: text/javascript; charset=ISO-8859-1


but I haven't found in the code where this is generated. I'm wondering if it would work to just change this to utf-8.

Robert Dionne

unread,
May 10, 2013, 1:11:14 PM5/10/13
to js-test...@googlegroups.com
We're using Jetty 6.1.9 which is an old version, however it should default to UTF-8. It looks like your browser might be the culprit? Which browser are you using? Are you able to set it's character encoding to UTF-8?

We can look into forcing UTF-8 on requests by using ServletRequest.setCharacterEncoding(String).

Characters in the HTTP content part

Wherever possible, a POST method should be used when international characters are involved.

This is because the browser sends a HTTP Content-Type header which can help the web server determine the encoding of the content. The Content-Type header will tell the server the MIME-type encoding of the content (usually application/x-www-form-urlencoded) and also can optionally include the character encoding of the content eg:

Content-Type: application/x-www-form-urlencoded;charset=UTF-8

If both the MIME-type and the charset encoding information is sent in the POST HTTP header, the server can correctly decode the content.

Unfortunately, many browsers do not bother to send the charset information, leaving the web server to guess the correct encoding. For this reason, the Servlet API provides the SevletRequest.setCharacterEncoding(String) method to allow the webapp developer to control the decoding of the form content.

Jetty-6 uses a default of UTF-8 if no overriding character encoding is set on a request.



--
You received this message because you are subscribed to the Google Groups "JsTestDriver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to js-test-drive...@googlegroups.com.
To post to this group, send email to js-test...@googlegroups.com.
Visit this group at http://groups.google.com/group/js-test-driver?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Brian

unread,
May 10, 2013, 1:18:54 PM5/10/13
to js-test...@googlegroups.com
I'm using chrome. d3 works fine via apache. It only barfs when served by jstestdriver. I get this on the console, at the first unicode character:

Uncaught SyntaxError: Unexpected token ILLEGAL 

I'm not sure what you mean about setting the browser character encoding to utf-8.

Brian

unread,
May 10, 2013, 1:24:44 PM5/10/13
to js-test...@googlegroups.com
That API looks like it's for form handling, not file serving. It's the response character set that seems to be off.


On Friday, May 10, 2013 10:11:14 AM UTC-7, Bobby wrote:

Dave

unread,
May 10, 2013, 1:24:47 PM5/10/13
to js-test...@googlegroups.com
Make sure the file is saved as utf-8 without signature/BOM. Byte order mark.


Brian <craft...@gmail.com> wrote:

I'm using chrome. d3 works fine via apache. It only barfs when served by jstestdriver. I get this on the console, at the first unicode character:

Uncaught SyntaxError: Unexpected token ILLEGAL 

I'm not sure what you mean about setting the browser character encoding to utf-8.

Robert Dionne

unread,
May 10, 2013, 1:26:04 PM5/10/13
to js-test...@googlegroups.com
On Fri, May 10, 2013 at 1:24 PM, Brian <craft...@gmail.com> wrote:
That API looks like it's for form handling, not file serving. It's the response character set that seems to be off.

I'll take a look. You're using http://d3js.org/d3.v3.min.js ?

Brian

unread,
May 10, 2013, 2:15:54 PM5/10/13
to js-test...@googlegroups.com
I'm using the dev version, d3.js from this zip:

Brian

unread,
May 10, 2013, 2:24:04 PM5/10/13
to js-test...@googlegroups.com
I don't see a BOM on the file.

Brian

unread,
May 11, 2013, 4:55:33 AM5/11/13
to js-test...@googlegroups.com
Ugh. I modified StaticResourceHandler.java to use "application/javascript" instead of "text/javascript", and now it works.

Interestingly, "text/javascript; charset=utf-8" did not work. Chrome still barfed on it.

Brian

unread,
May 23, 2013, 10:29:02 AM5/23/13
to js-test...@googlegroups.com
I suspect this fix has broken html DOC strings in the unit tests. So far I haven't figured out the DOC string code. Is it sensitive to content type? Only applying to "text" files, perhaps?

Brian

unread,
May 23, 2013, 11:14:01 AM5/23/13
to js-test...@googlegroups.com
Turns out this fix wasn't working the way I thought. It's not that chrome doesn't like mime type text/javascript. Rather, it's that jstestdriver mangles utf8. Changing the mime type to application/javascript was working because I'd previously applied the binary file serving fix, so all the js was being served as binary, skipping the PrintWriter. This is an unbelievable mess.

Anton Ulianov

unread,
Jun 4, 2013, 7:51:11 AM6/4/13
to js-test...@googlegroups.com
The JetBrains IDE has the integration with the JSTD. And they have patched it to make it work with UTF-8.
You can try to dig in this direction. Take a look at this link http://confluence.jetbrains.com/display/WI/Patched+JsTestDriver-1.3.5

Robert Dionne

unread,
Jun 4, 2013, 4:41:13 PM6/4/13
to js-test...@googlegroups.com
I've applied the jetbrains patch in commit 170a4754 and verified that serving d3.js serves in proper UTF-8.


On Tue, Jun 4, 2013 at 7:51 AM, Anton Ulianov <anton....@gmail.com> wrote:
The JetBrains IDE has the integration with the JSTD. And they have patched it to make it work with UTF-8.
You can try to dig in this direction. Take a look at this link http://confluence.jetbrains.com/display/WI/Patched+JsTestDriver-1.3.5

--

Sergey Simonchik

unread,
Jun 6, 2013, 4:07:27 AM6/6/13
to js-test...@googlegroups.com
That's cool! Thanks a lot.


2013/6/5 Robert Dionne <robert...@gmail.com>
Reply all
Reply to author
Forward
0 new messages