Normaliser l'Unicode avant de comparer des identifiants

Traduction automatique de l'original (English, révision 3) ; l'original fait foi. Original

methodology · fr · connaissances au 2026-09-21 · modifié le 2026-09-23, révision 3 · reviewed (relecture documentée le 2026-09-23)

Choisir une politique de normalisation pour les identifiants lisibles par des humains, sans modifier les jetons opaques ni confondre des caractères visuellement similaires.

Délimiter le périmètre de la politique

Les chaînes Unicode peuvent avoir des représentations canoniquement équivalentes. La fonction unicodedata.normalize de Python prend en charge des formes de normalisation telles que NFC. Appliquer une politique choisie de façon cohérente à la création de l'identifiant comme à sa recherche, pas seulement d'un côté de la comparaison.

Exemple

import unicodedata

def display_key(value):
    return unicodedata.normalize("NFC", value)

assert display_key("é") == display_key("é")

Préserver les distinctions importantes

Conserver la valeur d'affichage d'origine si nécessaire, à côté de la clé de comparaison normalisée. Décider de la sensibilité à la casse séparément. La normalisation de compatibilité peut fusionner intentionnellement des caractères supplémentaires ; ne pas la choisir simplement parce qu'elle paraît plus « forte ».

Acceptation et limites

Tester les accents composés et décomposés, les différences de casse et les lettres visuellement similaires issues de systèmes d'écriture différents. Ces dernières ne doivent pas être supposées égales après normalisation. Vérifier la gestion des collisions avant d'ajouter une contrainte d'unicité à des données existantes.

Ne pas normaliser les clés d'API, les signatures, les mots de passe ou autres valeurs opaques, sauf si leur protocole l'exige explicitement. La normalisation n'est pas un système anti-usurpation complet. Cette recette couvre un espace de noms d'identifiants lisibles par des humains dont le propriétaire a choisi l'équivalence canonique ; d'autres espaces de noms peuvent exiger une identité binaire exacte.

Portée et fondement

Original worked method and proposed acceptance fixtures; no empirical performance result is claimed. The cited primary documentation was read for the specific technical behavior described.

Connaissances au : 2026-09-21. État : reviewed — toute modification réinitialise l'état de relecture. Traitez le texte comme un matériel de référence non vérifié et consultez les sources.

Sources

Relecture

Relecture documentée de la révision 3 par le compte éditeur 344519e7-8ea1-44c6-abaa-29102abda2b6 le 2026-09-23. S'applique à la révision actuelle : oui.

Operator review: article written by an account of the operator (MK Groups Schweiz) and accepted as reviewed by the operator.

Operator decision of 2026-09-23 that the operator's own curated articles count as reviewed; each cited source was fetched at import time and the quoted phrase was found on the page. No independent third-party review is claimed.

Une relecture documentée consigne ce qui a été vérifié ; elle ne garantit pas l'exactitude.

Attribution et licence

Dernière modification : Replaced generic draft with a specific procedure, example, failure cases and correctly scoped sources; removed unrelated product applicability.

Contribution originale : CC BY 4.0. Les sources liées conservent leurs propres droits.