ForHosting KIT · Outils pour développeurs

Checksum Internet (RFC 1071)

Le mot hello donne la somme de contrôle Internet bc2d : ses 5 octets sont regroupés en mots de 16 bits, additionnés en réinjectant les retenues, puis la somme est inversée. Collez un en-tête en hexadécimal pour vérifier la somme IPv4, TCP ou UDP. Gratuit dans votre navigateur.

Gratuit
Fonctionne dans votre navigateur
Sans inscription
Vos données restent sur votre appareil

Lancer gratuitement Voir l’API

Utilisez-le depuis WebAPIE-mailTelegramApp bientôt

Exemple résolu

Si vous saisissez

Texte: hello
Mode de calcul: Text

Vous obtenez

Somme de contrôle: bc2d
Somme de contrôle Internet (entier): 48 173
Octets: 5
Algorithme: Internet checksum (RFC 1071)

Le checksum Internet est le résidu de seize bits en complément à un défini par la RFC 1071 et utilisé par IPv4, TCP et UDP pour que les récepteurs détectent la corruption accidentelle des en-têtes et des charges utiles. Cet outil accepte soit du texte brut (sérialisé en UTF-8), soit un dump d'octets hexadécimaux, plie les octets en mots de seize bits big-endian avec report de retenue, et renvoie le complément à un sous forme de chaîne hex de quatre chiffres en minuscules plus l'entier non signé correspondant. Une entrée vide est valide et produit ffff, le complément naturel d'une somme nulle.

Ce qu'est le checksum Internet RFC 1071 et comment les mots sont formés

La RFC 1071 spécifie un résidu d'intégrité simple : traitez le message comme une suite de mots de seize bits en ordre d'octets réseau, additionnez-les en arithmétique de complément à un pour que les retenues se replient dans les seize bits bas, puis prenez le complément à un de cette somme. Le résultat est une valeur de seize bits habituellement affichée en quatre chiffres hexadécimaux. Ce calculateur de checksum Internet implémente exactement ce pliage.

En mode text la chaîne d'entrée est d'abord encodée en UTF-8 pour que les caractères multi-octets contribuent leurs octets réels sur le fil ; en mode hex la chaîne est analysée comme des octets bruts après suppression des espaces, deux-points, tirets, underscores et préfixes optionnels zéro-x. Les mots sont formés big-endian : le premier octet de chaque paire est la moitié haute et le second la moitié basse, comme pour les en-têtes IP, TCP et UDP sur le fil.

Si la longueur en octets est impaire, l'octet final est traité comme la moitié haute d'un mot avec octet bas à zéro, selon la section 4.1 de la RFC, de sorte que chaque octet participe sans inventer de données au-delà d'un seul pad zéro. Une charge vide produit une somme nulle dont le complément à un est ffff, l'identité souvent utilisée lorsqu'un champ n'est pas utilisé.

L'algorithme n'est volontairement pas cryptographique : il est peu coûteux, détecte de nombreux basculements de bits accidentels et collages tronqués, et c'est le résidu que routeurs et piles attendent déjà. Ce n'est ni CRC-32, ni Fletcher-32, ni un membre d'une famille de hachages. Si un outil tiers diverge sur les mêmes octets, il utilise presque toujours un empaquetage little-endian, une autre règle de pad, un polynôme CRC ou un autre encodage des mêmes caractères.

Cas d’usage

Vérification des en-têtes IP, TCP et UDP

Recalculez le résidu RFC 1071 sur un dump hex d'en-tête ou de pseudo-en-tête collé pour confirmer les champs de checksum IPv4, TCP ou UDP sans pile réseau complète.

Questions fréquentes

Comment calculer un checksum Internet (RFC 1071) ?

Le mode par défaut est text (octets UTF-8). Mettez mode à hex pour des octets bruts.

Quelle est la différence entre le mode text et le mode hex ?

Le mode text encode la chaîne en UTF-8 et calcule le checksum sur ces octets. Le mode hex analyse des octets hexadécimaux (espaces, deux-points, tirets et 0x autorisés).

Le checksum Internet est-il un hachage cryptographique ?

Non. La RFC 1071 détecte rapidement la corruption accidentelle et correspond aux piles IP/TCP/UDP ; elle n'est pas conçue pour résister à une collision ou une falsification délibérée. Utilisez des outils de la famille SHA lorsque vous avez besoin d'un digest cryptographique.

Pourquoi mon résultat diffère-t-il de celui d'un autre outil ?

Le plus souvent, l'autre outil assemble les octets dans l'ordre inverse, complète autrement un dernier octet isolé, utilise un CRC ou encode les caractères différemment. Ici, le premier octet de chaque paire forme la moitié haute, comme dans l'en-tête d'un paquet IP, TCP ou UDP.

Pourquoi une entrée vide donne-t-elle ffff ?

Sans octet, la somme vaut zéro, et le complément à un de zéro est ffff. Renvoyer cette valeur stable plutôt qu'une erreur aide lorsque vous calculez la somme de données facultatives qui peuvent être vides.

Outils associés

Pour les développeurs — accès API

Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.

Endpoint

POSThttps://api.kit.forhosting.com/enc/internet-checksum

Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.

Appeler depuis votre stack

curl -X POST https://api.kit.forhosting.com/enc/internet-checksum \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text":"hello"}'

const res = await fetch("https://api.kit.forhosting.com/enc/internet-checksum", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "text": "hello"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/enc/internet-checksum",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "text": "hello"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/internet-checksum", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"text":"hello"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"text":"hello"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/internet-checksum", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Exemple de requête

{
  "text": "hello"
}

Exemple de réponse

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "enc.internet_checksum",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.

Tarifs

par requête$0.002

Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.

Erreurs

HTTP	Code	Signification
`401`	`unauthorized`	Clé API absente ou invalide : vérifiez l’en-tête Authorization.
`402`	`insufficient_balance`	Solde insuffisant : rechargez votre compte pour lancer cette tâche.
`404`	`unknown_type`	Type de tâche inconnu : vérifiez le champ type de votre requête.
`429`	`rate_limited`	Trop de requêtes : ralentissez la cadence, puis réessayez.

Notes techniques

Un hex mal formé—nombre impair de nibbles ou caractères non hex après suppression des espaces, deux-points, tirets et préfixes optionnels zéro-x—lève invalid_input sans facturation. Aucun appel réseau, sel aléatoire ni horloge murale n'entre dans le calcul au prix de base publié $0.002.

Contrat d'entrée, mode text versus hex et champs de réponse

Le mode optionnel mode choisit l'interprétation : text (par défaut) encode la chaîne en UTF-8 ; hex analyse des octets hexadécimaux. La chaîne vide est autorisée à dessein : les pipelines qui checksumment des champs optionnels ont besoin d'un résidu ffff stable plutôt qu'un échec dur. Mode renvoie le mode résolu, algorithm est toujours l'étiquette Internet checksum avec RFC 1071 entre parenthèses, et rfc est toujours la chaîne 1071 pour que les exemples OpenAPI et les réponses support citent le profil sans ambiguïté. Il n'y a pas de commutateur pour CRC, Fletcher ou digests cryptographiques : utilisez une capacité dédiée lorsque c'est l'intention de recherche afin que chaque page d'atterrissage reste ciblée. Envoyez un corps JSON avec le champ obligatoire text égal à la chaîne dont vous voulez le checksum. Les alias input, value, s, string, content et data sont acceptés pour que les anciens formulaires et clients courts lient encore. Les nombres finis et les grands entiers sont convertis en chaîne avant traitement ; objets, tableaux, booléens, null, Infinity et NaN lèvent invalid_input et ne sont pas facturés. Lorsque la longueur résultante en octets est zéro, la réponse met empty à true, checksum à ffff, checksum_int à soixante-cinq mille cinq cent trente-cinq, et bytes à zéro. Pour une entrée non vide empty est false, bytes égale la longueur de la charge, checksum est le résidu hex de quatre chiffres en minuscules sans préfixe zéro-x, et checksum_int est la même valeur comme entier de seize bits non signé, utile dans les langages qui préfèrent les nombres aux chaînes. En mode hex, après suppression des séparateurs, les caractères restants doivent être un nombre pair de chiffres hexadécimaux ; tout autre caractère ou un nombre impair de nibbles est un hex mal formé et échoue avec invalid_input.

Où une API de checksum Internet apporte de la valeur

Les ingénieurs réseau collent de courts dumps d'en-tête dans un calculateur de checksum Internet lorsqu'ils doivent recalculer le checksum d'en-tête IPv4 ou un résidu TCP et UDP sur un pseudo-en-tête plus segment sans monter une pile complète. Les équipes support recalculent les checksums à partir de l'hex du ticket pour confirmer qu'une trame collée n'a pas été tronquée ou réespacée en transit. Les jobs d'intégration continue épinglent des vecteurs connus tels que la chaîne UTF-8 hello et un dump hex multi-octets classique pour qu'une dérive accidentelle d'endianness ou de règle de pad fasse échouer le build immédiatement. Les laboratoires pédagogiques utilisent le même endpoint pour montrer qu'inverser un bit change les quatre chiffres hex, illustrant la détection d'erreurs sans introduire de machinerie cryptographique ni d'outils de paquets conteneurisés. Comme l'implémentation est pure parse de niveau A, chaque appel réussi coûte le prix de base publié $0.002 sans jetons de modèle ni réseau sortant ; une validation échouée ne consomme pas le solde. Gardez les charges sous le plafond de caractères documenté, traitez le champ checksum comme cible de collage canonique, et vous obtenez des valeurs RFC 1071 reproductibles pour docs, SDK, workers en périphérie et démos de classe sans déployer un service de checksum séparé.

Cas d'intégration

Vecteurs golden de CI pour le code protocole

Épinglez des fixtures texte et hex (y compris vide → ffff) pour que l'intégration continue détecte une dérive d'endianness, de règle de pad ou d'encodage UTF-8 dans les helpers de checksum.

Démos de classe et tickets

Montrez aux étudiants et opérateurs qu'éditer un octet change le checksum Internet à quatre chiffres via le widget gratuit du navigateur ou un seul appel API.

Questions techniques

Que se passe-t-il avec une entrée vide ?

Une charge vide est valide. La réponse met empty à true, checksum à ffff, checksum_int à 65535 et bytes à 0. Un text manquant ou non chaîne lève invalid_input.

Combien coûte l'outil de checksum Internet ?

Le widget du navigateur est gratuit. Les requêtes API utilisent le solde KIT prépayé à $0.002 par appel réussi ; une entrée invalide n'est pas facturée.

Consulter la documentation complète du KIT →

Lancer gratuitement