Alex Le’s Blog

I randomly ran into Steven Levithan’s blog while searching to get an idea of how JavaScript handles Unicode. Steven is a JavaScript - Unicode and Regular Expression expert. He has a cool section called “Code Challenge” with some good food-for-thoughts challenges. It’s really JavaScript being pushed to the max, in terms of brevity, creativity, and obscurity. Check out Stephen’s “Roman Numeral Convert” challenge for example.

Reading through the comments, I picked out a nugget explaining a JavaScript behavior which actually caused me some unexpected issues with TubeCaption’s Captionizer. Steven explained best in his original comment

… you might have already realized this, but the unary + operator and parseInt are not equivalent. + can convert strings to numbers, and returns NaN if the element cannot be converted. parseInt (which takes an optional second argument for the radix) does the same thing, but also extracts leading numbers from strings. E.g., parseInt(”12x”) returns 12, while +”12x” returns NaN. Additionally, parseInt and + make different assumptions about the radix when there’s a leading zero. +”012″ returns 12, but parseInt(”012″) returns 10. The leading zero causes parseInt to treat it as an octal number in probably all browsers, despite octals being summarily deprecated in ES3. Of course, you can use parseInt(”012″,10) to get around that.

Here is a quick demo of how parseInt() behaves.

For the SRT import feature of TubeCaption’s Captionizer, I heavily relied on parseInt() to get the different time values. I was caught by surprise when a user notified me that his SRT file could not be imported into the timeline. After some debugging, it turned out that some values had padding values and the parseInt() returned incorrect results in octal instead of decimal. I wish I had known about the “+” trick and the subtlety of JavaScript at the time.

Tags: javascript, parseInt