Merci pour le lien d'ailleurs, c'est une bonne référence.
D'ailleurs, ils disent qu'il vaut mieux ne pas faire de restriction de caractères, parce que les langues évoluent.
Ils proposent plutôt de remplacer les caractères visuellement proche:
Instead, the Consortium recommends processing strings to remove basic equivalences, promoting adequate rendering support, and putting restrictions in place according to script, and restricting by confusable characters. While the ICANN guidelines say "top-level domain registries will [...] associate each registered internationalized domain name with one language or set of languages" [ICANN], that guidance is better interpreted as limiting to script rather than language.
Ah ben oui, c'est bien ça, ils proposent d'appliquer l'algorithme NFKC (2.10.2 > B > 2):
For equivalence of identifiers, preprocess both strings by applying NFKC and case folding. Display all such identifiers to users in their processed form. (There may be two displays: one in the original and one in the processed form.) An example of this methodology is Nameprep [RFC3491]. Although Nameprep is currently limited to Unicode 3.2, the same methodology can be applied by implementations that need to support more up-to-date versions of Unicode.
[^] # Re: nomenclature et mitigation
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à l’entrée du suivi falsification d'identité par unicode. Évalué à 4 (+0/-0).
Merci pour le lien d'ailleurs, c'est une bonne référence.
D'ailleurs, ils disent qu'il vaut mieux ne pas faire de restriction de caractères, parce que les langues évoluent.
Ils proposent plutôt de remplacer les caractères visuellement proche:
Si je ne me trompe pas, ça doit correspondre à la méthode de normalisation d'UTF-8: https://en.wikipedia.org/wiki/Unicode_equivalence#Normalization
Ah ben oui, c'est bien ça, ils proposent d'appliquer l'algorithme NFKC (2.10.2 > B > 2):