前些天信用卡站点要接入一个新功能，不过还真比较坑爹，asp站点，大家都知道信用卡的背面是有一个有效期的，在对接银行中这个信息一定是要传给银行做数据校验，用户在语音输入信用卡有效期后，系统会做一个有效期判断，为了不必要的麻烦，就是判断过期时间一定不能在一个月内，由于输入的年月日在三个文本框中，再加上我嫌转成时间麻烦，就索性直接拿年，月，日的文本内容直接强转成int类型来判断，此为背景。
说了这么多，终于说到文章主题了，我们知道有效期有这样的：2015-09-20，我就毫不犹豫的从月文本框中拿出了"09"，然后屁颠屁颠的在chrome下做了如下转换，很开心，搞定。
下午测试小妹妹反馈过来说，信用卡有效期判断有问题，比较诧异，在自己机器上怎么试都没有问题，然后没辙，只能亲自去小妹妹桌上看看，顺便搽点油，开着IE调试器调试了下，果然，灵异事件发生了，现在终于找到问题所在了。
当时测试小妹妹装的是IE8，然后在IE8下面parseint默认会把我的“09”当成八进制，但是又发现不是合法的八进制，最后就抛出了0这个false，我们也看到在chrome下，“09”会默认当做十进制来看的，所以js引擎会理所当然的转化成了9这个我满意的结果，所以嘛，IE真的是不按照人的常理出牌，现在我们该如果解决呢？
一：解决方案
<1> 刚才讨论中也发现了，parseInt在不同的浏览器下有不同的默认行为处理，没辙，又看不到parseint底层是怎么处理的，只能去找javascript的api文档这个黑盒去看一看，然后就发现一个让我很惊喜的radix参数。
知道了这个radix，问题就可以迎刃而解了，现在我只需指定下radix=10即可，如图：
不过后来发现在IE9下面，parseint在缺失radix的时候底层也是默认采用十进制的，终于微软为了符合大众口味做了正确的修改。
<2>除了parseint这个函数，其实还有一个Number函数也可以帮你解决这个问题，并且在IE7,8上面都是没有问题的，由于在js中，如果你去new 一下这个Number的话，那就可以生成Number对象了，这一点和C#有一些区别，所以下面我可以用两种方式看一下。
这个Number的好处在于只会处理十进制数值，而且还有其他特殊的玩法，不像parseint只接受string的参数，number可以接受任何类型，比如：
由于看不到Number底层的源码，所以针对这些问题，我们也只能道听途说来记住了，这也是JS与其他托管语言不一样的地方。