tools / hex
hex/
Convertissez du texte en hexadécimal et inversement. Jeu de caractères au choix (UTF-8, GBK, UTF-16 et d'autres) ; la sortie peut avoir un séparateur, des majuscules et un préfixe 0x ou \x.
Texte
hex
Questions fréquentes
Combien d'octets fait un caractère chinois en hexadécimal, et pourquoi d'autres outils donnent-ils un résultat différent ?
Cela dépend du jeu de caractères. En UTF-8, un caractère chinois courant occupe 3 octets : par exemple 中 donne e4 b8 ad ; en GBK et GB2312, il occupe 2 octets et 中 donne d6 d0 ; un emoji occupe 4 octets en UTF-8. Les lettres sans accent et les chiffres font 1 octet en UTF-8 comme en GBK, le résultat est donc le même. Quand le résultat diffère de celui d'un autre outil, vérifiez quel jeu de caractères celui-ci utilise. Cette page utilise UTF-8 par défaut.
La conversion hexadécimal vers texte indique que les octets ne sont pas un texte valide, ou le résultat est illisible. Que faire ?
Cela signifie que les octets n'ont pas été encodés avec le jeu de caractères actuel : essayez-en un autre. Pour du texte chinois, les plus courants sont UTF-8 et GBK (les anciens logiciels et les exports de bases de données utilisent souvent GBK) ; un hexadécimal en UTF-16 contient en général beaucoup d'octets 00. Cet outil n'affiche jamais en caractères illisibles des octets qu'il ne peut pas décoder. Seul ISO-8859-1 fait exception : chaque octet correspond à un caractère, il ne signale donc jamais d'erreur, mais le texte chinois devient des caractères illisibles. GBK et GB2312 sont tous deux décodés par le décodeur GB18030 intégré au navigateur, plus tolérant que ceux de Python ou de Java : choisir GB2312 permet donc aussi de décoder des caractères qui n'existent qu'en GBK. Si ces octets n'ont jamais été du texte (image, données chiffrées, valeur de hachage), aucun jeu de caractères ne pourra les décoder.
Quels formats la conversion hexadécimal vers texte accepte-t-elle ?
Majuscules et minuscules sont acceptées. Les octets peuvent être séparés par des espaces, des sauts de ligne, des tabulations, des deux-points, des virgules ou des tirets, ou ne pas être séparés du tout, et chaque octet peut commencer par 0x ou \x : 0x48,0x65 et \x48\x65 sont donc décodés tels quels. Chaque groupe situé entre deux séparateurs doit contenir un nombre pair de chiffres, il faut donc écrire 0x01 et non 0x1. Tout caractère autre que 0-9 et a-f provoque aussi une erreur. Dans les deux cas, le message indique la position du caractère. Les formes comme U+4E2D et %E4%B8%AD ne sont pas reconnues ; pour l'encodage URL, utilisez l'outil URL de ce site.
Comment obtenir des formats comme 0x48,0x65 ou \x48\x65 ?
Choisissez « , » comme séparateur et « 0x » comme préfixe pour obtenir 0x48,0x65, que vous pouvez coller dans un tableau d'octets en C ou en Java. Choisissez « Aucun » comme séparateur et « \x » comme préfixe pour obtenir \x48\x65, la notation des octets dans les chaînes Python et C. Le préfixe est ajouté devant chaque octet : « Aucun » avec 0x donne donc 0x480x65, ce qui est rarement utile. « Majuscules » n'affecte que a-f ; le x de 0x reste en minuscule.
Pourquoi le résultat UTF-16 commence-t-il par feff, et pourquoi diffère-t-il de celui d'autres outils ?
L'UTF-16 suit la convention de Java : le résultat commence par FE FF (marque d'ordre des octets) et est en big-endian, donc 中 devient fe ff 4e 2d. L'UTF-16BE sans marque donne 4e 2d : copiez le résultat et supprimez les deux premiers octets. L'UTF-32 est en big-endian et sans marque, donc 中 donne 00 00 4e 2d. Au décodage, l'UTF-16 accepte un FE FF initial (big-endian) ou un FF FE initial (little-endian), et suppose du big-endian en l'absence de marque.
Pourquoi du texte chinois provoque-t-il une erreur avec ASCII ou ISO-8859-1 ?
L'ASCII ne couvre que les codes 0 à 127, et l'ISO-8859-1 s'arrête à U+00FF (lettres d'Europe occidentale avec accents, sans caractères chinois). Tout caractère hors de cette plage provoque une erreur du type « Le caractère “中” ne peut pas être encodé en ASCII », au lieu d'être remplacé en silence par « ? » comme le fait getBytes en Java. GBK et GB2312 se comportent de la même façon : les emoji et les caractères rares absents de la table de codage provoquent une erreur. Passez à UTF-8 ou GB18030 pour les convertir.
Les espaces et les sauts de ligne de ma saisie sont-ils convertis ?
Dans le sens texte vers hexadécimal, oui. Chaque caractère du champ de saisie est converti, y compris les espaces et sauts de ligne au début et à la fin : un espace donne 20 et un saut de ligne donne 0a. Le champ de texte du navigateur normalise les sauts de ligne en \n, donc dans un texte multiligne un saut de ligne donne 0a et non 0d 0a ; modifiez le résultat vous-même si vous avez besoin des fins de ligne Windows. Dans le sens hexadécimal vers texte, les espaces blancs de l'hexadécimal sont ignorés et seuls les octets comptent, et un 0d 0a dans le résultat s'affiche aussi comme un seul saut de ligne.
Ce que je saisis est-il envoyé quelque part ?
Non. La conversion se fait dans votre navigateur, n'envoie aucune requête et ne conserve rien.