Tag: jslint

 

jslint4java 2.0.2

After another long period of having nothing to say, I’ve pushed out an update to jslint4java. Version 2.0.2 doesn’t include any major new features, but does update JSLint to the latest version (2012-02-03) and fix a couple of small bugs here and there.

  • issue 75: Handle BOMs when using the CLI.
  • issue 74: Document the technique for construction of JSLint objects.
  • issue 73: Better examples for maven configuration.
  • issue 72 : Add all formatters to the maven plugin automatically.
  • issue 67 : Fix maven docs.
  • Update to JSLint 2012-02-03.
    • This removes the adsafe, confusion and safe options.
    • This adds the anon option.

One minor point: Now that google code supports git repositories, I’m also pushing the source code there again. Github is still my “primary” but there’s another copy. More copies are good.

I did spend a bit of time testing the CLI interface properly. This isn’t really noteworthy, but it was entertaining for me, and hopefully results in fewer bugs like issue 75.

jslint4java 2.0.1

Only about a month later than I had hoped, I’ve published jslint4java-2.0.1. The main change should be that the maven plugin is a bit better behaved. Plus of course, it’s using the latest version of JSLint.

No escape() from JavaScript

A couple of days ago, we got caught out by a few encoding issues in a site at $WORK. The Perl related ones were fairly self explanatory and I’d seen before (e.g. not calling decode_utf8() on the query string parameters). But the JavaScript part was new to me.

The problem was that we were using JavaScript to create an URL, but this wasn’t encoding some characters correctly. After a bit of investigation, the problem comes down to the difference between escape() and encodeURIComponent().

input escape(…) encodeURIComponent(…)
a&b a%26b a%26b
1+2 1+2 1%2B2
café caf%E9 caf%C3%A9
Ādam %u0100dam %C4%80dam

The last is particularly troublesome, as no server I know of will support decoding that %u form.

The takeaway is that encodeURIComponent() always encodes as UTF-8 and doesn’t miss characters out. As far as I can see, this means you should simply never use escape(). Which is why I’ve asked Douglas Crockford to add it as a warning to JSLint.

Once we switched the site’s JavaScript from escape() to encodeURIComponent(), everything worked as expected.