Convertisseur de points de code Unicode

Unicode attribue à chaque caractère une valeur scalaire unique écrite dans la notation familière U+ hexadécimale, des lettres latines de base comme U+0041 pour le A majuscule jusqu'aux emoji et écritures historiques qui exigent cinq ou six chiffres hexadécimaux. Développeurs, ingénieurs de polices, équipes de localisation et services d'assistance doivent sans cesse développer une courte chaîne en ces points de code pour le débogage, la documentation ou les formats fil, et tout aussi souvent réassembler une liste de jetons U+ en glyphes originaux.

Comment les scalaires Unicode correspondent aux jetons U+XXXX

Unicode définit un espace de valeurs scalaires allant de zéro à U+10FFFF. Tout entier de cet intervalle n'est pas un caractère que l'on tape chaque jour, mais chaque caractère abstrait que vous stockez dans un texte moderne est identifié par l'un de ces scalaires. Les chaînes JavaScript sont des séquences d'unités de code UTF-16, donc un emoji unique ou un idéogramme CJK rare peut occuper deux unités appelées paire de surrogates.

Un convertisseur correct doit donc itérer par points de code plutôt qu'indexer unité par unité ; sinon un visage souriant serait rapporté à tort comme deux surrogates haut et bas séparés au lieu d'un seul scalaire tel que U+1F600. Cette capacité parcourt la chaîne avec codePointAt, avance d'une ou deux unités selon le besoin, et formate chaque scalaire comme U+ suivi d'au moins quatre chiffres hexadécimaux majuscules, étendus à cinq ou six chiffres lorsque la valeur l'exige.

Le chemin inverse accepte plusieurs orthographes courantes pour que les sources collées restent souples : U+0048, u+48, 0x48, hexadécimal nu comme 0048, et les formes HTML comme H ou la décimale H. Chaque jeton est analysé en entier puis validé : les valeurs au-dessus de U+10FFFF sont rejetées, et l'intervalle de surrogates UTF-16 de U+D800 à U+DFFF est rejeté car ces unités de code ne sont pas des valeurs scalaires Unicode et ne doivent jamais apparaître comme caractères isolés dans une chaîne Unicode bien formée.

Les scalaires valides sont assemblés avec fromCodePoint en une chaîne JavaScript normale.

Où la conversion de points de code Unicode apparaît dans le travail réel

Les chaînes de production de polices et de glyphes documentent quels scalaires une famille couvre et ont besoin de listes U+ stables dans les feuilles de spécimen et les diffs de pull requests. Les ingénieurs d'internationalisation comparent les formes normalisées, traquent les sosies trompeurs et vérifient qu'un nom de produit ne cache pas un homoglyphe en développant chaque caractère en son point de code.

Les équipes d'accessibilité et de contenu collent de courtes chaînes issues des outils de conception et ont besoin d'un développement faisant autorité quand un glyphe s'affiche comme un carré ou un emoji inattendu. Les examinateurs de sécurité inspectent les noms d'utilisateurs, les URL et les lignes de journaux à la recherche de caractères de contrôle non ASCII ou de scalaires à usage privé qui échappent aux filtres naïfs.

Les cours de programmation enseignent l'encodage en montrant qu'un seul caractère visible peut correspondre à un scalaire tandis que UTF-8 peut utiliser plusieurs octets ; une page dédiée au convertisseur sert mieux cette intention de recherche que de l'enfouir sous des outils de réparation Base64 ou UTF-8. Les services d'assistance reçoivent des captures d'écran de symboles étranges et reconstruisent les points de code exacts à partir d'un échantillon tapé ou copié afin que l'ingénierie puisse reproduire le bogue.

Si vous avez besoin de secrets Base32, de codage pour cent pour les URL, de dumps d'octets octaux ou de réparation de mojibake vers UTF-8, traitez-les comme des intentions de recherche et des pages distinctes plutôt que de surcharger cette page de convertisseur de points de code Unicode.