IsNumeric en JavaScript : 5 erreurs fatales lors de la validation des nombres

Validation des nombres décimaux en JavaScript : pourquoi IsNumeric() casse le code et comment y remédier

Chaque développeur qui a écrit en JavaScript pendant au moins une semaine a tôt ou tard été confronté à la tâche : « Vérifier si une chaîne est un nombre ». Cela semble simple, non ? La fonction intégrée isNaN() ou parseFloat() — et le tour est joué. Mais ce n'est pas si simple. La question « Validate decimal numbers in JavaScript — IsNumeric() » sur Stack Overflow a recueilli des centaines de milliers de vues et des dizaines de réponses contradictoires. Pourquoi ? Parce que JavaScript est un langage où typeof NaN === 'number' et une chaîne vide est considérée comme zéro.

Dans cet article, nous ne nous contenterons pas de donner une fonction isNumeric() toute prête. Nous analyserons les 5 erreurs les plus fréquentes et dangereuses que même les programmeurs expérimentés commettent, et nous montrerons comment les éviter. Vous découvrirez pourquoi isNaN est un piège, comment fonctionne la conversion de type et quelle méthode de validation des nombres en JS est réellement utilisable en production.

Pourquoi isNaN() est un mal (et quand ça marche)

Commençons par l'évidence. Beaucoup de débutants écrivent ceci :

function isNumeric(n) {\n  return !isNaN(n);\n}\n

À première vue, c'est logique : si ce n'est pas NaN, c'est un nombre. Mais testons :

console.log(isNumeric('123'));    // true — ok\nconsole.log(isNumeric('12.3'));   // true — ok\nconsole.log(isNumeric(''));       // true — OUPS ! Une chaîne vide est un nombre ?\nconsole.log(isNumeric(' '));      // true — un espace est aussi un nombre ?\nconsole.log(isNumeric(null));     // true — null est un nombre ?\nconsole.log(isNumeric(true));     // true — true vaut 1\n

Erreur n°1 : isNaN() convertit d'abord l'argument en nombre, puis vérifie. La chaîne vide '' est convertie en 0, null en 0, true en 1. En conséquence, la fonction considère comme des nombres ce qui n'en est pas.

Il existe une variante stricte — Number.isNaN() (ES6), mais elle vérifie uniquement si la valeur est exactement NaN, sans conversion. Elle ne convient pas non plus pour la validation des nombres.

parseFloat : héros ou méchant ?

La deuxième approche populaire consiste à utiliser parseFloat() :

function isNumeric(n) {\n  return !isNaN(parseFloat(n)) && isFinite(n);\n}\n

Cette variante est déjà meilleure, mais elle a un autre problème :

console.log(isNumeric('123abc')); // true — parseFloat extrait '123', ignore 'abc'\nconsole.log(isNumeric('12.3.4')); // true — parseFloat ne voit pas le deuxième point\nconsole.log(isNumeric('Infinity')); // true — l'infini est un nombre ?\n

Erreur n°2 : parseFloat() analyse la chaîne jusqu'au premier caractère invalide. La chaîne '123abc' est interprétée comme 123. Mais l'utilisateur a pu appuyer accidentellement sur une touche supplémentaire, et nous devons détecter cela.

Erreur n°3 : isFinite() exclut Infinity et -Infinity, mais laisse passer NaN et undefined. Le problème est que isFinite(null) renvoie true, car null est converti en 0.

Erreur n°4 : Les expressions régulières — panacée ou nouvel enfer ?

Lorsque les développeurs réalisent que les fonctions intégrées ne sont pas fiables, ils tombent souvent dans l'autre extrême — les expressions régulières. Et là, le chaos commence.

Voici une regex typique mais dangereuse :

function isNumeric(n) {\n  return /^\\d+$/.test(n);\n}\n

Problèmes :

\n
• N'accepte pas les points décimaux ('12.3' — false)
\n
• N'accepte pas les nombres négatifs ('-5' — false)
\n
• N'accepte pas la notation scientifique ('1e5' — false)
\n

Voici une version « u