Pourquoi votre conversion binaire vers texte affiche les mauvais caractères

Une chaîne de 1 et de 0 semble sans ambiguïté — c’est du binaire, il n’y a rien à interpréter. En pratique, convertir du binaire en texte échoue exactement de la même façon que l’hexadécimal vers texte, pour la même raison sous-jacente : une séquence de bits n’est pas du texte tant que vous n’avez pas fait plusieurs suppositions sur la façon de la regrouper et de l’interpréter, et se tromper sur l’une de ces suppositions produit un résultat faux d’une manière précise et diagnosticable.

Cause 1 : mauvais regroupement de bits (7 bits vs. 8 bits)

L’ASCII standard n’a besoin que de 7 bits par caractère ; la plupart des outils binaire-vers-texte utilisent par défaut des octets de 8 bits, car c’est ainsi que le texte est réellement stocké sur les systèmes réels. Si une chaîne binaire a été générée en supposant des regroupements de 7 bits (certains exemples de manuels et systèmes anciens le font encore) et que vous la décodez en octets de 8 bits, chaque caractère ressort décalé — la limite de regroupement est fausse dès le tout premier bit, donc la corruption est uniforme sur l’ensemble du résultat plutôt que de commencer proprement et de se dégrader en cours de route.

Le signe : si littéralement tous les caractères du résultat sont faux, pas seulement certains, vérifiez d’abord l’hypothèse de regroupement des bits avant toute autre chose.

Cause 2 : un bit en trop ou manquant décale tout ce qui suit

C’est l’équivalent binaire d’un chiffre hexadécimal impair — un 0 ou un 1 isolé en trop (un caractère supplémentaire issu d’un copier-coller, un chiffre perdu, un espace analysé comme donnée) décale la limite d’octet de chaque groupe suivant ce point. Contrairement à la cause 1, cela produit un texte qui est correct jusqu’à un certain point puis brouillé ensuite — un signal fort que le nombre de bits lui-même est faux quelque part dans la chaîne, plutôt que le schéma d’encodage étant faux partout.

Comptez d’abord le nombre total de bits : la longueur de la chaîne devrait être un multiple exact de 8 (ou de 7, si vous avez confirmé que c’est le regroupement utilisé). Si ce n’est pas le cas, le bit en trop ou manquant est le bug, pas le décodeur.

Cause 3 : encodage de caractères, exactement comme pour l’hexadécimal

Une fois les bits correctement regroupés en octets, il reste à décider ce que ces valeurs d’octets signifient en tant que caractères — UTF-8, ASCII, Latin-1. C’est identique au cas hexadécimal-vers-texte : les caractères UTF-8 multi-octets (lettres accentuées, symboles, écritures non latines) décodés un octet à la fois comme si chacun était son propre caractère produisent deux ou trois symboles brouillés à la place d’un seul caractère correct. Si le regroupement des bits est confirmé correct (causes 1 et 2 écartées) et que le résultat reste faux spécifiquement autour des caractères non ASCII, c’est presque toujours la cause restante.

Cause 4 : l’endianness, pour du binaire représentant des nombres plutôt que du texte

Si la chaîne binaire encode une valeur numérique plutôt que des données de caractères — un préfixe de longueur, une somme de contrôle, un identifiant intégré à côté du texte — l’ordre des bits/octets compte et il n’existe pas de valeur par défaut universelle. 00000001 en tant qu’octet isolé n’est pas ambigu, mais les valeurs numériques multi-octets peuvent être stockées avec l’octet de poids fort en premier ou l’octet de poids faible en premier, selon le système qui les a produites, et la lire avec la mauvaise hypothèse produit silencieusement un nombre différent, d’apparence plausible mais incorrect, plutôt qu’une erreur évidente.

Diagnostiquer dans l’ordre

1. Vérifiez que le nombre total de bits est un multiple exact de votre regroupement supposé (8, généralement) — un compte erroné signifie la cause 2, corrigez l’entrée.
2. Si tous les caractères sont faux de manière uniforme dès le début, soupçonnez la taille de regroupement elle-même (cause 1) avant de toucher à l’encodage.
3. Si le résultat est propre au début et se dégrade en cours de route, cela pointe vers un bit isolé ou manquant à cet endroit précis (cause 2), pas un problème d’encodage.
4. Si le regroupement et le nombre de bits sont tous deux corrects et que seuls les caractères non ASCII semblent faux, c’est l’encodage de caractères (cause 3).
5. Si les données représentent un nombre plutôt que du texte et que la valeur semble plausible mais fausse, vérifiez l’ordre des octets (cause 4) avant de supposer que la logique de conversion elle-même est cassée.

Comme pour l’hexadécimal, l’étape de conversion elle-même est triviale — le vrai bug se trouve presque toujours dans l’une de ces quatre suppositions, pas dans le code qui effectue la conversion.