ForHosting KIT · Outils pour développeurs

Calculateur checksum BSD

Le texte « abc » donne une somme BSD de 16556, soit 40ac en hexadécimal, sur 1 bloc : la même paire que celle de l'ancienne commande sum d'Unix en mode BSD. Utile pour vérifier d'anciens scripts, des étiquettes de bande ou des exercices. 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: abc

Vous obtenez

Résultat: 40ac
Somme de contrôle: 16 556
Hex: 40ac
Décimal: 16 556

L'algorithme classique BSD sum est le checksum seize bits par rotation et addition utilisé par la commande Unix historique sum en mode BSD (souvent invoquée comme sum -r sur les systèmes GNU). Contrairement aux contrôles de redondance cyclique, il met à jour un unique registre de seize bits en le faisant pivoter d'un bit vers la droite et en y ajoutant chaque octet du message, puis indique un nombre de blocs en unités de mille vingt-quatre octets. Les ingénieurs qui comparent d'anciennes étiquettes de bande, les étudiants qui reproduisent la sortie sum d'un manuel et les équipes de support qui vérifient de courts textes face à d'anciens scripts ont souvent besoin de la même paire déterministe : la valeur de checksum non signée et la colonne de blocs. Cet outil de checksum BSD accepte un texte non vide, l'encode en UTF-8, exécute cette boucle de rotation-et-addition et renvoie la valeur de seize bits en décimal et quatre chiffres hexadécimaux minuscules, avec le nombre de blocs, le libellé d'algorithme, la longueur en octets et un court résumé.

Ce que calcule le BSD sum classique et pourquoi le nombre de blocs compte

Le checksum BSD traite chaque message comme une séquence d'octets et maintient un accumulateur de seize bits qui démarre à zéro. Pour chaque octet, le registre est d'abord pivoté d'un bit vers la droite dans seize bits — le bit de poids faible passe en bit de poids fort — puis la valeur de l'octet est ajoutée, la somme étant masquée à nouveau sur seize bits. Lorsque le flux se termine, cet entier non signé est la colonne de checksum de la sortie classique de sum.

En parallèle, l'outil indique combien de blocs de mille vingt-quatre octets le message occupe, par division par plafond de la longueur UTF-8 : toute charge non vide d'un à mille vingt-quatre octets donne un bloc, le kilo-octet suivant démarre un second bloc, et ainsi de suite.

Comme BSD sum n'est ni résistant aux collisions ni authentifié par clé, traitez-le comme un contrôle rapide d'intégrité ou de trame héritée, non comme une preuve d'authenticité ; préférez les digests de la famille SHA lorsque l'intention de recherche est le hachage cryptographique plutôt que le checksum classique rotation-et-addition.

Où une somme BSD reste utile

Les auteurs de systèmes hérités et les étudiants en histoire d'Unix utilisent un calculateur de checksum BSD pour vérifier des étapes de rotation-et-addition faites à la main face à sum -r sans installer un environnement coreutils complet dans chaque langage. Les plateformes d'enseignement et les plugins LMS ont besoin d'un oracle déterministe qui rejette l'entrée vide au lieu de renvoyer des zéros pour le message vide, afin que les correcteurs automatiques distinguent les réponses manquantes d'un vrai checksum.

Les sites de contenu qui se positionnent sur checksum BSD, checksum de la commande sum ou sum Unix classique bénéficient d'un outil vivant dont le chemin gratuit correspond octet pour octet à l'automatisation payante sur le même module pur. Les échecs de validation ne consomment jamais de solde après rejet.

Associez-le à des landings System V sum, CRC-16 ou hachage cryptographique seulement lorsque l'intention de recherche dépasse le rotation-et-addition BSD classique — gardez cette page centrée sur BSD sum pour que l'intention SEO reste nette et ne cannibalise pas les landings Adler-32 ou CRC-16.

Cas d’usage

Vérification héritée de sum -r

Reproduisez le checksum BSD classique et le nombre de blocs de 1024 octets pour une courte charge texte lors de la migration de scripts qui impriment encore la paire historique sum -r.

Questions fréquentes

Quel algorithme cet outil reproduit-il ?

Le BSD sum classique de l'historique Unix sum et de GNU coreutils sum -r : pour chaque octet, faire pivoter le registre de seize bits d'un bit vers la droite puis ajouter l'octet ; le nombre de blocs est ceil(length/1024).

Que se passe-t-il si le texte est vide ?

Une chaîne non vide est requise ; l'entrée vide n'est pas traitée comme un checksum réussi de zéro avec zéro blocs.

BSD sum est-il identique à System V sum ou CRC-16 ?

Non. System V sum (-s) utilise une autre accumulation et des blocs de 512 octets. CRC-16 utilise un registre polynomial. Cet outil n'implémente que le rotation-et-addition BSD classique.

Que signifie le nombre de blocs dans le résultat ?

C'est le nombre de blocs de 1024 octets qu'occupe le texte une fois encodé en UTF-8, arrondi vers le haut. De 1 à 1024 octets, on compte un bloc, et le kilo-octet suivant en ouvre un deuxième.

La somme BSD suffit-elle à prouver qu'un fichier n'a pas été modifié ?

Non. Elle ne résiste pas aux collisions et n'utilise aucune clé : c'est un contrôle rapide d'intégrité hérité des anciens systèmes. Pour une vraie preuve d'authenticité, préférez une empreinte de la famille SHA.

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/bsd-sum

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/bsd-sum \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text":"abc"}'

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

import os, requests

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

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

body := bytes.NewBufferString(`{"text":"abc"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/bsd-sum", 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": "abc"
}

Exemple de réponse

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "enc.bsd_sum",
  "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

L'entrée vide est rejetée avec invalid_input afin que les appelants ne confondent jamais un champ manquant avec le rapport zéro-zéro du fichier vide de la commande classique.

Contrat d'entrée, erreurs de chaîne vide et forme JSON de la réponse

La chaîne est encodée en UTF-8 avant la boucle BSD, de sorte que les caractères multi-octets contribuent chaque unité de code exactement comme le ferait un sum orienté fichier recevant le même flux UTF-8. L'entrée vide est délibérément rejetée plutôt que de renvoyer la paire théorique du fichier vide zéro zéro, afin que l'UX produit et les correcteurs automatiques distinguent les réponses manquantes d'un vrai checksum. Épinglez à la fois un chemin de succès et l'erreur d'entrée vide en intégration continue pour qu'un changement accidentel de sens de rotation ou de taille de bloc ne passe pas inaperçu. Les champs nuls optionnels sont omis plutôt qu'émis comme null, conformément au contrat du rendu déclaratif pour des formulaires web propres. Envoyez un corps JSON avec un unique champ chaîne obligatoire nommé text : toute séquence non vide de caractères dont vous voulez le checksum. Les alias input, value, s, data, message et payload sont acceptés pour le même champ afin que les stubs SDK et les envois de formulaire restent souples. Si text est absent, si la valeur n'est pas une chaîne ou si la chaîne est vide, la requête échoue avec invalid_input et un message clair indiquant qu'une chaîne non vide est requise ; ces échecs ne sont pas facturés sur l'API prépayée. En cas de succès le corps inclut result et hex avec le même checksum hexadécimal de quatre chiffres minuscules ; checksum et decimal avec l'entier non signé de seize bits ; blocks avec le nombre de blocs de mille vingt-quatre octets ; algorithm fixé à BSD sum ; input_bytes égal à la longueur UTF-8 ; text reprenant l'entrée ; et message résumant le nombre d'octets, la valeur décimale, l'hex et les blocs.

Où une API de checksum BSD se justifie et comment fonctionne le tarif

Utilisez l'outil gratuit dans le navigateur pour des contrôles ponctuels ; appelez l'API KIT prépayée depuis des backends, des fonctions serverless et des SDK lorsque vous avez besoin d'un contrat stable sous solde à $0.002 par élément réussi. Gardez les charges à des tailles de texte ordinaires adaptées à un appel d'item dans un Worker isolate ; cet outil est destiné aux chaînes courtes et aux fragments de protocole, non aux binaires de plusieurs mégaoctets.

Cas d'intégration

Démonstrations de rotation-et-addition en classe

Les enseignants montrent comment une rotation droite de seize bits plus une addition produit les fixtures connus abc et Hello sans installer coreutils sur chaque machine d'élève.

Fixtures CI pour aides d'intégrité héritées

Les pipelines épinglent des sorties déterministes BSD sum en décimal, hex et blocks plus l'erreur d'entrée vide afin qu'un changement accidentel de rotation ou de taille de bloc échoue vite.

Questions techniques

Comment calculer un checksum BSD d'un texte ?

Envoyez un JSON avec un champ chaîne non vide nommé text. L'API encode la chaîne en UTF-8, exécute la boucle classique BSD sum de rotation-et-addition et renvoie la valeur de seize bits en décimal et quatre chiffres hex minuscules plus le nombre de blocs de 1024 octets.

Le calculateur de checksum BSD est-il gratuit ?

L'outil navigateur s'exécute gratuitement sur votre appareil. Les appels API utilisent le solde KIT prépayé à $0.002 par élément réussi ; les échecs de validation ne sont pas facturés.

Consulter la documentation complète du KIT →

Lancer gratuitement