ForHosting KIT · Strumenti per sviluppatori

Checksum Internet (RFC 1071)

La parola hello dà il checksum Internet bc2d: i suoi 5 byte vengono raggruppati in parole da 16 bit, sommati ripiegando i riporti e la somma viene invertita. Incolli un'intestazione in esadecimale per verificare il checksum di IPv4, TCP o UDP. Gratis nel suo browser.

  • Gratis
  • Funziona nel suo browser
  • Senza registrazione
  • I suoi dati restano sul dispositivo
Usalo da WebAPIEmailTelegramApp presto
Se inserisce
Testo
hello
Modalità di calcolo
Text
Ottiene
Checksum
bc2d
Checksum Internet (intero)
48.173
Byte
5
Algoritmo
Internet checksum (RFC 1071)

L'input vuoto è valido e produce ffff, il complemento naturale di una somma zero.

Cos'è il checksum Internet RFC 1071 e come si formano le parole

La RFC 1071 specifica un residuo di integrità semplice: tratti il messaggio come una sequenza di parole a sedici bit in ordine di byte di rete, le sommi con aritmetica in complemento a uno così che i riporti si ripieghino nei sedici bit bassi, poi prenda il complemento a uno di quella somma. Il risultato è un valore a sedici bit di solito mostrato come quattro cifre esadecimali. Questa calcolatrice di checksum Internet implementa esattamente quella piega.

In modalità text la stringa di input è prima codificata come UTF-8 affinché i caratteri multi-byte contribuiscano con i loro byte reali sul filo; in modalità hex la stringa è analizzata come ottetti grezzi dopo aver rimosso spazi, due punti, trattini, underscore e prefissi opzionali zero-x. Le parole si formano big-endian: il primo byte di ogni coppia è la metà alta e il secondo la metà bassa, come le intestazioni IP, TCP e UDP sul filo.

Se la lunghezza in byte è dispari, l'ultimo byte è trattato come metà alta di una parola con byte basso zero, come descritto nella sezione 4.1 della RFC, così ogni byte partecipa senza inventare dati extra oltre a un unico pad zero. L'algoritmo non è criptografico di proposito: è economico, rileva molte inversioni accidentali di bit e incolli troncati, ed è il residuo che router e stack già si aspettano. Non è CRC-32, né Fletcher-32, né un membro di una famiglia di hash.

Se uno strumento di terze parti discorda sugli stessi byte, quasi sempre usa packing little-endian, una regola di pad diversa, un polinomio CRC o una codifica diversa degli stessi caratteri.

Verifica delle intestazioni IP, TCP e UDP

Ricalcoli il residuo RFC 1071 su un dump hex di intestazione o pseudo-header incollato per confermare i campi di checksum IPv4, TCP o UDP senza uno stack di rete completo.

Come si calcola un checksum Internet (RFC 1071)?

La modalità predefinita è text (byte UTF-8). Imposti mode su hex per ottetti grezzi.

Qual è la differenza tra la modalità text e la modalità hex?

La modalità text codifica la stringa in UTF-8 e calcola il checksum su quei byte. La modalità hex analizza ottetti esadecimali (spazi, due punti, trattini e 0x ammessi).

Il checksum Internet è un hash crittografico?

No. La RFC 1071 rileva rapidamente la corruzione accidentale e coincide con gli stack IP/TCP/UDP; non è progettata per resistere a collisioni o falsificazioni deliberate. Usi strumenti della famiglia SHA quando serve un digest crittografico.

Perché il mio risultato è diverso da quello di un altro strumento?

Di solito l'altro strumento accoppia i byte in ordine inverso, completa in altro modo un ultimo byte isolato, usa un CRC o codifica i caratteri diversamente. Qui il primo byte di ogni coppia è la metà alta, come nelle intestazioni IP, TCP e UDP.

Perché un testo vuoto dà ffff?

Senza byte la somma è zero, e il complemento a uno di zero è ffff. Restituire questo valore stabile invece di un errore aiuta quando si calcola il checksum di dati facoltativi che possono essere vuoti.

Tutto quello che vedi in questa pagina è disponibile anche via API. Questa sezione è per i team che vogliono integrarlo nei propri sistemi; chi non ne ha bisogno può semplicemente usare lo strumento qui sopra.

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

Autenticazione con Bearer token: un POST mette in coda l'attività e il risultato arriva via webhook o link firmato.

curl -X POST https://api.kit.forhosting.com/enc/internet-checksum \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text":"hello"}'
{
  "text": "hello"
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "enc.internet_checksum",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

L'API è asincrona: ricevi subito un task_id e puoi fare polling fino a 1 richiesta al secondo.

per richiesta$0.002

Prezzo pubblicato, senza token né crediti. Se l'attività fallisce, non paghi.

HTTPCodiceSignificato
401unauthorizedChiave API mancante o non valida: controlla l'header Authorization.
402insufficient_balanceCredito esaurito: ricarica per continuare a eseguire attività.
404unknown_typeTipo di attività sconosciuto: controlla il campo type della richiesta.
429rate_limitedTroppe richieste in poco tempo: rallenta e riprova tra qualche secondo.

Il checksum Internet è il residuo a sedici bit in complemento a uno definito nella RFC 1071 e usato da IPv4, TCP e UDP affinché i ricevitori rilevino la corruzione accidentale di intestazioni e payload. Questo strumento accetta testo semplice (serializzato come UTF-8) oppure un dump di byte esadecimali, piega i byte come parole a sedici bit big-endian con ripiegamento del riporto e restituisce il complemento a uno come stringa hex a quattro cifre minuscole più l'intero senza segno corrispondente. L'hex malformato—conteggio dispari di nibble o caratteri non hex dopo aver rimosso spazi, due punti, trattini e prefissi opzionali zero-x—genera invalid_input senza addebito. Nessuna chiamata di rete, sale casuale o orologio di parete entra nel calcolo al prezzo base pubblicato $0.002.

Cos'è il checksum Internet RFC 1071 e come si formano le parole

Un payload vuoto produce una somma zero il cui complemento a uno è ffff, l'identità spesso usata quando un campo non è usato.

Contratto di input, modalità text rispetto a hex e campi di risposta

Il mode opzionale sceglie l'interpretazione: text (predefinito) codifica la stringa come UTF-8; hex analizza ottetti esadecimali. La stringa vuota è consentita di proposito: le pipeline che checksummano campi opzionali necessitano di un residuo ffff stabile invece di un fallimento duro. Mode riecheggia la modalità risolta, algorithm è sempre l'etichetta Internet checksum con RFC 1071 tra parentesi, e rfc è sempre la stringa 1071 così che esempi OpenAPI e risposte di supporto citino il profilo senza ambiguità. Non c'è un selettore di modalità per CRC, Fletcher o digest crittografici: usi una capacità dedicata quando quella è l'intenzione di ricerca affinché ogni landing page resti focalizzata. Invii un corpo JSON con il campo obbligatorio text impostato sulla stringa di cui vuole il checksum. Gli alias input, value, s, string, content e data sono accettati così che form antichi e client brevi si colleghino ancora. Numeri finiti e big integer sono convertiti in stringa prima dell'elaborazione; oggetti, array, booleani, null, Infinity e NaN generano invalid_input e non sono addebitati. Quando la lunghezza risultante in byte è zero, la risposta imposta empty a true, checksum a ffff, checksum_int a sessantacinquemilacinquecentotrentacinque e bytes a zero. Con input non vuoto empty è false, bytes uguaglia la lunghezza del payload, checksum è il residuo hex a quattro cifre minuscole senza prefisso zero-x, e checksum_int è lo stesso valore come intero a sedici bit senza segno, utile nei linguaggi che preferiscono i numeri alle stringhe. In modalità hex, dopo aver rimosso i separatori, i caratteri rimanenti devono essere un conteggio pari di cifre esadecimali; qualsiasi altro carattere o un conteggio dispari di nibble è hex malformato e fallisce con invalid_input.

Dove un'API di checksum Internet rende valore

Gli ingegneri di rete incollano brevi dump di intestazione in una calcolatrice di checksum Internet quando devono ricalcolare il checksum dell'intestazione IPv4 o un residuo TCP e UDP su un pseudo-header più segmento senza avviare uno stack completo. I team di supporto ricalcolano i checksum dall'hex del ticket per confermare che un frame incollato non sia stato troncato o rispaziato in transito. I job di integrazione continua fissano vettori noti come la stringa UTF-8 hello e un dump hex multi-byte classico così che qualsiasi deriva accidentale di endianness o regola di pad faccia fallire subito la build. I laboratori didattici usano lo stesso endpoint per mostrare che invertire un bit cambia le quattro cifre hex, illustrando il rilevamento degli errori senza introdurre macchinari crittografici o strumenti di pacchetto containerizzati. Poiché l'implementazione è parse pura di livello A, ogni chiamata riuscita costa il prezzo base pubblicato $0.002 senza token di modello e senza rete in uscita; la validazione fallita non consuma saldo. Mantenga i payload sotto il tetto di caratteri documentato, tratti il campo checksum come destinazione canonica di incolla, e otterrà valori RFC 1071 riproducibili per documentazione, SDK, worker edge e demo di aula senza erigere un servizio di checksum separato.

Vettori golden di CI per codice di protocollo

Fissi fixture di testo e hex (incluso vuoto → ffff) così che l'integrazione continua individui derive di endianness, regola di pad o codifica UTF-8 negli helper di checksum.

Demo di aula e ticket

Mostri a studenti e operatori come modificare un byte cambia il checksum Internet a quattro cifre con il widget gratuito del browser o una singola chiamata API.

Cosa succede con input vuoto?

Un payload vuoto è valido. La risposta imposta empty a true, checksum a ffff, checksum_int a 65535 e bytes a 0. Text mancante o non stringa genera invalid_input.

Quanto costa lo strumento di checksum Internet?

Il widget del browser è gratuito. Le richieste API usano il saldo KIT prepagato a $0.002 per chiamata riuscita; l'input non valido non viene addebitato.

Leggi la documentazione completa del KIT →