Compression des noms de domaine

Je suis curieux de savoir comment on pourrait compresser de manière très compacte le domaine d'un nom d'hôte IDN arbitraire (tel que défini par RFC5890 ) et je pense que cela pourrait devenir un défi intéressant. Un hôte ou un nom de domaine Unicode (U-label) se compose d'une chaîne de caractères Unicode, généralement limitée à une langue en fonction du domaine de premier niveau (par exemple, les lettres grecques sous .gr), qui est codée dans une chaîne ASCII commençant par xn--(le correspondant Une marque).

On peut construire des modèles de données non seulement à partir des exigences formelles

• chaque étiquette non Unicode doit correspondre à une chaîne ^[a-z\d]([a-z\d\-]{0,61}[a-z\d])?$;

• chaque étiquette A doit correspondre à une chaîne ^xn--[a-z\d]([a-z\d\-]{0,57}[a-z\d])?$; et

• la longueur totale de l'ensemble du domaine (étiquettes A et étiquettes non IDN concaténées avec des délimiteurs «.») ne doit pas dépasser 255 caractères

mais aussi à partir de diverses heuristiques, dont:

• les U-labels d'ordre inférieur sont souvent des expressions lexiquement, syntaxiquement et sémantiquement valides dans certains langages naturels, y compris les noms et les chiffres appropriés (non ponctués sauf le trait d'union, dépourvus d'espaces et pliés par Nameprep ), avec une préférence pour les phrases plus courtes; et

• les étiquettes d'ordre supérieur sont tirées d'un dictionnaire de SLD et de TLD et fournissent un contexte pour prédire quel langage naturel est utilisé dans les étiquettes d'ordre inférieur.

Je crains qu'il soit difficile d'obtenir une bonne compression de telles chaînes courtes sans prendre en compte ces caractéristiques spécifiques des données et, en outre, que les bibliothèques existantes produiront une surcharge inutile afin de s'adapter à leurs cas d'utilisation plus généraux.

En lisant le livre en ligne de Matt Mahoney intitulé Data Compression Explained , il est clair qu'un certain nombre de techniques existantes pourraient être utilisées pour tirer parti des hypothèses de modélisation ci-dessus (et / ou d'autres) qui devraient se traduire par une compression bien supérieure par rapport à des outils moins spécifiques.

À titre de contexte, cette question est une ramification d'une précédente sur SO .

Pensées initiales

Il me semble que ce problème est un excellent candidat pour la formation hors ligne et j'envisage un format de données compressé selon les lignes suivantes:

• Un codage Huffman du « suffixe public », avec des probabilités tirées d'une source publiée d'enregistrement de domaine ou de volumes de trafic;

• Un codage Huffman dont le modèle (en langage naturel) est utilisé pour les U-labels restants, avec des probabilités tirées d'une source publiée d'enregistrement de domaine ou de volumes de trafic étant donné le contexte du suffixe de domaine;

• Appliquer des transformations basées sur un dictionnaire à partir du modèle de langage naturel spécifié; et

• Un codage arithmétique de chaque caractère dans les U-labels, avec des probabilités tirées de modèles de langage naturel contextuellement adaptatifs dérivés de la formation hors ligne (et peut-être aussi en ligne, bien que je soupçonne que les données peuvent bien être trop courtes pour fournir un aperçu significatif?).

Le codage Huffman est optimal pour les lettres et peut certainement être adapté aux séquences. Par exemple, si la séquence "ab" produit moins de bits que les bits pour "a" et "b", ajoutez-la simplement à l'arborescence ... et ainsi de suite.

... vous pouvez également probablement utiliser une bibliothèque simple qui fait tout cela pour vous avec des performances presque optimales, de sorte que vous ne gagnerez pas beaucoup en utilisant votre algorithme de compression super sophistiqué sur mesure.