Calculateur de checksum XOR

Saisissez des entiers de 0 à 255 pour obtenir le résultat en décimal, en hexadécimal et en binaire, accompagné d’une expression lisible. Ce contrôle est courant dans les messages série compacts, les commandes de systèmes embarqués, les formats anciens et les protocoles simples de type LRC, car il demande très peu de calcul. L’outil vous permet de vérifier des exemples, déboguer des trames, préparer des vecteurs de test et reproduire une spécification sans écrire de script ponctuel.

Méthode de calcul du checksum XOR

Le calcul part d’un accumulateur nul et applique l’opération OU exclusif bit à bit à chaque octet de la séquence. Pour chaque position, XOR produit un lorsque les deux bits comparés diffèrent et zéro lorsqu’ils sont identiques. Après répétition, il ne reste qu’un octet. Une valeur combinée deux fois s’annule, car x XOR x vaut zéro, tandis qu’une combinaison avec zéro laisse la valeur intacte. L’opération est associative et commutative : regrouper ou réordonner les octets choisis ne change donc pas le résultat, même si le protocole détermine toujours précisément les champs à inclure. Ce calculateur vérifie que chaque élément est un entier compris entre 0 et 255, parcourt la liste, puis présente la même valeur sous trois formes. Le décimal convient aux API générales, l’hexadécimal correspond aux captures de paquets et aux fiches techniques, et les huit chiffres binaires rendent chaque bit visible. L’expression renvoyée consigne tous les opérandes et le résultat hexadécimal final.

Sélectionnez les bons octets du message

L’arithmétique est simple, mais le choix de la bonne portion d’une trame provoque le plus souvent les écarts. Consultez la définition du protocole pour déterminer si le délimiteur initial, l’adresse, la commande, la longueur, la charge utile, le champ de checksum existant et le délimiteur final sont inclus. En général, l’octet de contrôle lui-même est exclu, mais les conventions diffèrent. Convertissez les octets hexadécimaux tels que 7E, 01 et A4 en valeurs entières avant l’envoi : ils deviennent 126, 1 et 164. N’envoyez pas de codes de caractères sauf si le protocole contrôle explicitement du texte encodé. Le caractère ASCII « 7 » correspond normalement à 55, tandis qu’un champ numérique de valeur sept correspond à 7. Les nombres sur plusieurs octets doivent aussi respecter l’ordre de transmission. Construisez la liste exactement comme elle circule, puis comparez le résultat hexadécimal à la trame ou à la documentation. Le nombre d’octets aide à repérer un champ oublié ou ajouté deux fois.

Ce que ce contrôle peut réellement prouver

Un checksum XOR convient lorsqu’un protocole exige un contrôle extrêmement rapide et spécifie déjà cet algorithme. Il détecte toute modification d’un seul bit et de nombreuses autres altérations accidentelles, ce qui le rend pratique pour diagnostiquer de courtes trames série et des appareils contraints. Il reste toutefois bien moins robuste qu’un CRC ou qu’un hash cryptographique. Deux erreurs identiques dans des octets différents peuvent s’annuler, une permutation ne change pas le résultat et un attaquant peut compenser volontairement une modification ailleurs. Considérez la sortie comme une valeur de compatibilité et de diagnostic, jamais comme une preuve d’authenticité ou une protection contre la falsification. Pour un nouveau protocole, préférez un CRC clairement défini contre les erreurs de transmission ou un code d’authentification de message si la sécurité compte. Pour des tests reproductibles, conservez la liste exacte et l’expression renvoyée dans votre fixture. Le navigateur utilise la même logique déterministe que l’API, et chaque appel automatisé coûte $0.002, ce qui garantit des résultats concordants.