Résumé

  • Bootstring copiait littéralement les points ASCII de base, puis représentait chaque point non basique par un delta combinant distance numérique et position d’insertion dans la sortie croissante.
  • Des entiers autodélimités et un biais adaptatif rendaient la forme unique et réversible. Ils ne traduisaient pas le nom et ne prouvaient ni sa validité IDNA, ni son enregistrement, ni son identité.

Le résultat Punycode paraît opaque parce qu’il ne tente pas de préserver l’apparence d’un mot. Pour comprendre RFC 3492, il faut se placer du côté du décodeur. Celui-ci commence avec les caractères déjà compatibles avec ASCII, puis réinsère les autres aux emplacements exacts. Il reconstruit une séquence ; il n’interprète aucune langue.

La première opération de Bootstring sépare les points de base. Ils sont copiés au début, dans leur ordre relatif d’origine. S’il y en a au moins un, un délimiteur suit. Pour Punycode, l’ensemble de base est ASCII et le délimiteur est le trait d’union. Cette partie littérale n’est pas une traduction partielle : elle est seulement ce qui n’exige aucun encodage.

La traîne contient la structure absente. Le décodeur maintient n, valeur candidate du point de code, et i, position possible dans la chaîne déjà construite. L’état avance parmi tous les interstices ; au bout, i revient à zéro et n augmente. Un delta indique combien d’états sans insertion doivent passer avant d’insérer n à la position i.

Un entier transporte donc à la fois une distance dans l’espace des points de code et une place dans la séquence. L’encodeur traite les points non basiques par ordre numérique, ce qui réduit souvent les distances successives, puis calcule les deltas qui obligeront le décodeur à retrouver l’ordre initial. Il n’est pas nécessaire d’ajouter une table explicite de positions.

Plusieurs deltas étant concaténés, les entiers ordinaires laisseraient leurs frontières ambiguës. Bootstring emploie des entiers généralisés de longueur variable. À chaque chiffre, un seuil dit si l’entier continue ; un unique dernier chiffre tombe sous son seuil. L’ordre petit-boutiste permet de lire chaque entier depuis l’avant, et chaque valeur non négative possède une seule représentation pour les seuils choisis.

Après chaque delta, un biais modifie les seuils du suivant. Le premier grand saut est fortement amorti ; les suivants tiennent compte de la taille actuelle de la sortie. Le delta récent sert d’indice sur la prochaine magnitude probable. Il ne prédit ni langue ni caractère : il ajuste seulement le coût arithmétique.

Punycode fixe la base à 36, affecte les valeurs zéro à 25 aux lettres et 26 à 35 aux chiffres, démarre n à 128 et le biais à 72. Ces paramètres influencent l’efficacité, non la correction, dès lors qu’ils respectent les contraintes de Bootstring. L’implémentation doit aussi détecter les dépassements d’entiers ; l’argument de borne pour les labels IDNA ne dispense pas un usage général de contrôles.

L’unicité avait un enjeu de sécurité : plusieurs formes ASCII d’une même séquence Unicode pourraient relever d’autorités DNS différentes. Punycode évite cette bifurcation. Mais RFC 3492 distingue aussitôt l’autre problème : plusieurs séquences Unicode peuvent représenter un texte jugé « identique » selon une convention humaine ou une normalisation. L’algorithme n’arbitre pas cette équivalence.

RFC 3490 inséra Punycode dans IDNA ; IDNA2008 conserva les A-labels Punycode tout en remplaçant les règles environnantes. Cette stabilité illustre la spécification initiale minimale de Heng Lu : un mécanisme réversible étroit peut survivre pendant que les choix de caractères, de mapping et de registre évoluent ailleurs.

Les couches de réalité restent donc séparées : points reçus, suite préparée, préfixe littéral, deltas, suite reconstruite, A-label admise, inscription, réponse DNS et identité reconnue. Punycode relie exactement une suite à sa représentation ASCII. Lui demander davantage revient à prendre une notation pour une décision.

Sources