Valider une couleur hexadécimale

Il accepte les formats standard à trois, quatre, six et huit chiffres, avec ou sans dièse initial, et contrôle chaque caractère sans deviner ni corriger la valeur. Son résultat booléen s’intègre facilement dans un formulaire, un test, un import ou un flux API. Les champs absents et les types incorrects déclenchent des erreurs claires afin de ne jamais confondre une requête défectueuse avec une couleur non valide.

Définition d’une couleur hexadécimale valide

Une couleur hexadécimale valide contient exactement trois, quatre, six ou huit chiffres hexadécimaux. Trois chiffres représentent le format RGB court, quatre le format RGBA court avec transparence, six le format RGB complet et huit le format RGBA complet. Le dièse initial reste facultatif, car CSS, les bases de données, les outils de conception et les configurations ne conservent pas toujours ce préfixe de la même manière. Après cet éventuel préfixe, chaque caractère doit être un chiffre ASCII de 0 à 9 ou une lettre de A à F, en majuscule ou en minuscule. Le contrôle refuse les espaces, signes, caractères de ponctuation, doubles dièses, noms de couleurs, fonctions CSS et toute autre longueur. Il ne supprime pas non plus les espaces. Cette rigueur révèle les caractères invisibles et empêche l’approbation silencieuse d’une valeur différente de la source. Le booléen <code>valid</code> décrit donc exactement la chaîne que vous transmettez.

L’intérêt d’une validation déterministe

La validation d’une couleur paraît élémentaire, mais des règles incohérentes créent des défauts durables. Un navigateur peut refuser un format, une bibliothèque en normaliser un autre et une expression régulière artisanale oublier le format alpha court ou accepter cinq chiffres par erreur. Cette capacité applique une règle explicite : retirer un seul dièse facultatif, vérifier que la longueur restante figure parmi les quatre longueurs autorisées, puis contrôler l’appartenance de chaque caractère à l’alphabet hexadécimal. Elle n’utilise ni réseau, ni hasard, ni date, ni règle régionale, ni conversion de casse, ni interprétation colorimétrique. Une même entrée produit donc le même booléen dans le widget et par l’API. Une couleur incorrecte renvoie normalement <code>false</code>. En revanche, un champ absent ou un nombre, une liste ou un objet à la place d’une chaîne provoque une erreur explicite. Votre application distingue ainsi une saisie invalide d’une intégration défectueuse.

Exploiter le résultat dans vos formulaires et traitements

Utilisez le validateur juste avant qu’une couleur franchisse une frontière de confiance. Dans un formulaire, lancez-le lors de la modification du champ ou avant l’envoi, puis affichez un message précis lorsque <code>valid</code> vaut faux. Lors de l’import de jetons de conception, contrôlez chaque valeur avant de générer CSS afin qu’un jeton mal formé ne rende pas une feuille de style inutilisable ou ne se propage dans un thème. Dans un traitement de données, conservez la chaîne d’origine avec le booléen si vous avez besoin d’une piste d’audit ; ne remplacez pas la source par une forme normalisée, car cette capacité valide sans transformer. Pour développer, convertir ou extraire des canaux, validez d’abord puis confiez les valeurs admises à la capacité appropriée. Le navigateur convient aux contrôles interactifs et l’API coûte $0.002 par requête. La réponse stable s’insère directement dans les conditions et les tests de limites, symboles, préfixes, vides et espaces.