CodeKitHubEn quoi consiste cet outil ?
CRC signifie Cyclic Redundancy Check (contrôle de redondance cyclique), un code de détection d'erreurs décrit pour la première fois dans l'article de 1975 de W. Wesley Peterson et D.T. Brown, puis formalisé notamment dans "A Painless Guide to CRC Error Detection Algorithms" de Ross Williams et les normes ITU-T / ISO 3309. Un CRC traite un message comme un grand nombre binaire et le divise par un polynôme générateur fixe ; le reste de cette division constitue la somme de contrôle. La division polynomiale étant peu coûteuse à calculer, aussi bien en matériel qu'en logiciel, les CRC sont devenus le contrôle d'erreurs par défaut dans les systèmes de stockage et de transmission.
Le CRC-32 — plus précisément la variante avec le polynôme 0xEDB88320, une valeur initiale de 0xFFFFFFFF et un XOR final de 0xFFFFFFFF — est normalisé dans IEEE 802.3 (Ethernet) et utilisé comme somme de contrôle dans les archives ZIP et gzip, les fichiers image PNG, ainsi que d'innombrables protocoles réseau et de stockage. C'est de loin la variante de CRC la plus demandée, ce qui explique qu'elle soit l'algorithme par défaut de cet outil. CRC-16/CCITT-FALSE (polynôme 0x1021) et CRC-16/MODBUS (polynôme 0x8005, réfléchi) sont deux variantes 16 bits largement utilisées dans des protocoles série comme Modbus RTU, XMODEM, et diverses normes de communication industrielle et embarquée.
Il est important de comprendre ce qu'un CRC n'est pas : ce n'est pas un hachage cryptographique. Les CRC sont des fonctions linéaires rapides, sans aucune résistance à une manipulation délibérée — il est facile de construire un message différent produisant la même valeur de CRC. Ils excellent à détecter le type d'erreurs de bits aléatoires causées par des lignes de transmission bruitées, des erreurs de disque ou des téléchargements tronqués, mais n'offrent aucune protection contre un adversaire cherchant à altérer les données sans être détecté.
Pourquoi l'utiliser ?
- Vous déboguez un firmware pour un appareil Modbus RTU et le maître rejette vos trames pour "CRC error" — collez les octets exacts de la trame ici, calculez le CRC-16/MODBUS attendu et comparez octet par octet avec ce que génère votre code.
- Un fichier ZIP téléchargé sur un serveur lent signale une entrée corrompue à la décompression — recalculez le CRC-32 du fichier extrait et comparez-le à la valeur figurant dans l'en-tête local du ZIP pour savoir si le problème vient du transfert ou du fichier d'origine.
- Vous écrivez votre propre implémentation de CRC-32 en C ou Python pour un projet embarqué et avez besoin d'une valeur de référence fiable — utilisez le vecteur de test standard "123456789" (qui donne toujours 0xCBF43926) pour vérifier que votre code produit le bon résultat avant de l'intégrer.
- Un collègue vous transmet un PNG que Photoshop signale comme endommagé, et vous voulez confirmer s'il s'agit d'un vrai problème de CRC dans le chunk ou d'une fausse alerte du logiciel avant de perdre du temps à retélécharger le fichier.
- Vous implémentez XMODEM pour transférer des fichiers par port série et devez vérifier que votre calcul de CRC-16/CCITT-FALSE correspond exactement à ce qu'attend le protocole, octet par octet, sans réflexion de bits.
- Vous devez calculer un CRC sans installer d'outil en ligne de commande sur une machine restreinte — tout tourne dans le navigateur, sans téléverser le fichier vers un serveur externe.
Mode d'emploi
- Choisissez l'onglet "Texte" et collez ou saisissez votre contenu, ou passez à l'onglet "Fichier" et sélectionnez un fichier depuis votre appareil.
- Sélectionnez l'algorithme CRC : CRC-32 (IEEE 802.3, celui par défaut et le plus courant), CRC-16/CCITT-FALSE, ou CRC-16/MODBUS.
- La somme de contrôle se met à jour automatiquement, affichée en hexadécimal, décimal et binaire.
- Cliquez sur "Copier" à côté de n'importe quel résultat pour le copier dans votre presse-papiers.
Exemple
Entrée
123456789Résultat
0xCBF43926 (3421780262)Il s'agit du vecteur de test standard et publié pour le CRC-32 (IEEE 802.3) : le CRC-32 de la chaîne ASCII "123456789" est toujours 0xCBF43926. Vous pouvez vérifier le résultat de cet outil face à n'importe quelle autre implémentation correcte de CRC-32 en utilisant exactement cette chaîne.
CRC contre hachages cryptographiques (MD5 / SHA)
Les CRC et les hachages cryptographiques réduisent tous deux des données à une empreinte de taille fixe, mais ils résolvent des problèmes différents et ne sont pas interchangeables.
| Propriété | CRC (par ex. CRC-32) | MD5 / SHA-256 |
|---|---|---|
| Objectif | Détecter une corruption accidentelle | Détecter une altération intentionnelle / vérifier l'intégrité |
| Vitesse | Extrêmement rapide, matériel/logiciel simple | Plus lent, plus de calcul par octet |
| Résistance aux collisions | Aucune — trivial à provoquer volontairement | Conçu pour être impossible à réaliser en pratique (SHA-256) ou cassé pour MD5 |
| Taille typique | 16 ou 32 bits | 128 bits (MD5) ou 256 bits (SHA-256) |
| Usages courants | ZIP/gzip, PNG, Ethernet, Modbus, stockage | Vérifications d'intégrité de fichiers, signatures numériques, stockage de mots de passe (avec salage) |
Outils associés
Si vous avez besoin d'une somme de contrôle cryptographique plutôt que d'un CRC de détection d'erreurs, ces outils sont plus adaptés.
→ Générateur de hachage multi-algorithme · Générateur MD5 · Générateur HMAC
Erreurs courantes lors de l'implémentation d'un CRC
La plupart des "mon CRC ne correspond pas" ne sont pas des erreurs de logique mais de mauvais choix de paramètres. Voici les plus fréquentes lors du débogage d'une implémentation maison.
- Utiliser le polynôme sous sa forme normale (0x04C11DB7) au lieu de la forme réfléchie (0xEDB88320) requise par le CRC-32 standard traité bit à bit depuis le LSB.
- Oublier le XOR final de 0xFFFFFFFF en CRC-32 — sans lui, le résultat est le CRC "brut" avant l'étape de post-traitement exigée par la norme IEEE 802.3.
- Confondre CRC-16/CCITT-FALSE (sans réflexion, valeur initiale 0xFFFF) avec d'autres variantes CCITT qui réfléchissent l'entrée et la sortie, ou utilisent une valeur initiale de 0x0000 — ce sont quatre algorithmes distincts partageant le même polynôme 0x1021.
- Calculer le CRC sur du texte dans un éditeur avec un encodage différent de celui attendu (UTF-8 avec BOM au lieu d'ASCII pur, par exemple), ce qui change les octets réels d'entrée et donc le résultat.
Foire aux questions
À quoi sert un CRC ?
Un CRC (contrôle de redondance cyclique) est un code de détection d'erreurs ajouté à un bloc de données afin que le destinataire puisse le recalculer et confirmer que les données n'ont pas été accidentellement corrompues lors du stockage ou de la transmission. Il est intégré dans des normes telles que le trame Ethernet IEEE 802.3, les formats de fichiers ZIP et gzip, les images PNG, ainsi que de nombreux protocoles série et industriels comme Modbus.
Le CRC-32 est-il identique à MD5 ou SHA-256 ?
Non. Le CRC-32 est une somme de contrôle rapide et linéaire pour la détection d'erreurs, sans propriété de sécurité — il est trivial de construire volontairement deux entrées différentes ayant la même valeur CRC-32. MD5 et SHA-256 sont des fonctions de hachage cryptographiques conçues pour rendre ce type de collision délibérée impossible à réaliser en pratique. Utilisez CRC-32 pour détecter une corruption accidentelle (un disque rayé, un paquet réseau perdu) ; utilisez un hachage cryptographique de notre [Générateur de hachage](/hash-generator) ou [Générateur MD5](/md5-generator) lorsque vous avez besoin de preuves d'altération ou de garanties d'intégrité face à un adversaire.
Quelle variante de CRC-32 cet outil utilise-t-il ?
La variante IEEE 802.3 / ZIP / PNG : polynôme 0xEDB88320 (la forme réfléchie en bits de 0x04C11DB7), valeur initiale 0xFFFFFFFF, entrée et sortie réfléchies, et un XOR final de 0xFFFFFFFF. C'est la variante utilisée par Ethernet, ZIP, gzip et PNG, celle qui produit 0xCBF43926 pour la chaîne ASCII "123456789" — le vecteur de test standard et publié pour vérifier une implémentation de CRC-32.
Quelle est la différence entre CRC-16/CCITT-FALSE et CRC-16/MODBUS ?
Ce sont tous deux des CRC 16 bits, mais avec des polynômes et des paramètres différents. CRC-16/CCITT-FALSE utilise le polynôme 0x1021 avec une valeur initiale de 0xFFFF et sans réflexion de bits ; il est courant dans des protocoles comme XMODEM et diverses normes de télécommunication. CRC-16/MODBUS utilise le polynôme 0x8005 (réfléchi en 0xA001), également avec une valeur initiale de 0xFFFF, mais avec entrée et sortie réfléchies — c'est la somme de contrôle que Modbus RTU ajoute à chaque trame série. Ils produisent des résultats différents pour une même entrée, il est donc important de choisir la variante réellement spécifiée par votre protocole cible.
Puis-je calculer le CRC d'un fichier, pas seulement d'un texte ?
Oui. Passez à l'onglet "Fichier" et choisissez un fichier depuis votre appareil — l'outil lit ses octets bruts localement dans le navigateur (via la File API) et calcule la somme de contrôle exactement sur ces octets, comme le ferait un lecteur ZIP ou PNG.
Mes données sont-elles envoyées à un serveur ?
Non. Le calcul, que ce soit pour du texte ou un fichier, s'exécute entièrement côté client en JavaScript, à l'aide d'un algorithme CRC standard basé sur des tables. Rien de ce que vous saisissez ou téléversez ne quitte jamais votre navigateur.
Pourquoi mon implémentation Python de CRC-32 donne-t-elle un résultat différent de ce calculateur ?
C'est presque toujours un problème de paramètres, pas de l'algorithme lui-même : vérifiez que vous utilisez le polynôme réfléchi 0xEDB88320 (pas la forme normale 0x04C11DB7), une valeur initiale de 0xFFFFFFFF, une entrée et une sortie réfléchies, et un XOR final de 0xFFFFFFFF. Un seul paramètre différent — comme oublier le XOR final — produit un résultat complètement différent même si le reste de l'algorithme est correct.
Puis-je vérifier l'intégrité d'une trame Modbus RTU complète, adresse et fonction incluses ?
Oui — collez les octets bruts de la trame (adresse esclave, code fonction et données, sans le CRC final) dans l'onglet texte ou fichier, et comparez le CRC-16/MODBUS calculé aux deux derniers octets de la trame originale, que Modbus envoie en ordre little-endian.
Que se passe-t-il si deux fichiers différents produisent le même CRC-32 ?
C'est possible et attendu avec un CRC 32 bits, avec une probabilité d'environ 1 sur 4 milliards pour des fichiers aléatoires distincts. Comme le CRC n'est pas conçu pour résister aux collisions, il ne doit pas servir de preuve d'intégrité contre une altération intentionnelle — pour cela, il faut un hachage cryptographique comme SHA-256.
Le calculateur gère-t-il de très gros fichiers, comme une image disque ?
La limite pratique dépend de la mémoire disponible dans votre navigateur, car le fichier entier est chargé en mémoire avant le calcul du CRC. Cela fonctionne bien pour des fichiers de plusieurs mégaoctets, mais pour des images disque de plusieurs gigaoctets, mieux vaut utiliser un outil en ligne de commande comme crc32 ou python -c avec zlib.