技術情報棚卸し(平日限定)

todoa2cの技術情報棚卸しです。平日限定ってことはアレだ。言わせんな恥ずかしい。

JavaScriptのparseIntを数値入力の妥当性検証に使うと失敗する話

Webアプリケーションにおけるクライアント側のバリデーション処理で、 手抜きで下記のような書き方をしたら、(自分にとって)意外な答えが返ってきました。

1
2
3
var notNan = parseInt('10x', 10);
console.log(notNan);
// NaNが表示されるかと思ったけど、10が表示された

parseInt – JavaScript | MDNを見ると、確かにその通りに動いている事がわかります。下記は第1引数に関する記載の引用です。

parseInt が、指定された基数においては、数ではない文字に出会った場合、その文字とそれに続く文字の全てを無視し、その地点までパースされた値の整数を返します。 parseInt は、整数の値まで数を切り捨てます。 文字列の前後に空白があっても問題ありません。

JavaのInteger.parseInt()やPythonのint()のように、例外を返してくれるだろう、 または変換不可ということでNaNを返すだろう、と勝手な予想をしながら実装したのですが、 それがよくありませんでした。

他の言語で使い慣れているAPIのルールが、そのまま他の言語でも通じるだろう、 という思い込みは捨てて、ちゃんとAPIの挙動を調べて使うべきだ、と改めて痛感しました。

そもそもバリデーションですが、 バリデーションライブラリを使うか、 HTML5前提でIE 9を無視してよいのであれば、HTML5のForm Validationを使うのが便利かと思います。 今回のケースのように独自実装で頑張ると不具合混入しやすいですしね。 残念ながら私はまだこれらを使ったことがないので、ポインタだけ示しておきます。

jQuery Validation Plugin

HTML5 Form Validation のカスタマイズ

Comments