Regex EAN-13
Un EAN-13 est treize chiffres dont le dernier est une clé de contrôle calculée par pondération alternée (poids 1/3) — exactement le même algorithme que le GTIN-14 et le GLN (voir les fiches liées). Une regex peut vérifier que la forme est correcte ; elle ne peut pas recalculer cette clé. Le motif trouvé presque partout en ligne — treize chiffres, rien de plus — accepte donc « 0000000000000 » et un code dont la clé est fausse, tout en rejetant les exports contenant des espaces ou un tiret. C'est le motif le plus simple honnêtement disponible ; le vrai risque est de croire qu'il suffit.
/^[0-9]{13}$/passe 21/21 cas
Comparatif des patterns existants
Implémentation
const re = new RegExp("^[0-9]{13}$", "");
re.test(input);Limites
- Ne vérifie pas la clé de contrôle (pondération alternée 1/3, modulo 10) : un code syntaxiquement valide selon ce motif peut avoir une clé fausse, ou être treize zéros — aucun des deux ne correspond à un produit réel. Calculer et vérifier la clé demande du code, pas une regex (voir par exemple `calc_check_digit()` dans python-stdnum, lien ci-dessus).
- N'accepte que des chiffres consécutifs sans séparateur : les exports contenant des espaces ou un tiret (fréquents en logistique et en export tableur) doivent être normalisés avant validation — retirer espaces et tirets, comme le fait explicitement `compact()` dans python-stdnum.
- Un UPC-A (12 chiffres, marché nord-américain) n'est PAS un EAN-13 : il le devient en lui ajoutant un zéro non significatif en tête. Les deux formats se ressemblent assez pour que du code écrit pour l'un soit copié par erreur pour l'autre (voir le candidat 3 ci-dessus).
- Écrit avec `[0-9]` et non `\d` : en Python et .NET, `\d` matche par défaut tous les chiffres décimaux Unicode (pas seulement 0-9), et son comportement dépend d'une option de compilation en Java — un motif copié tel quel d'un langage à l'autre peut accepter des chiffres non arabes.