ForHosting KIT · Entwickler-Tools

Internet-Prüfsumme (RFC 1071)

Das Wort hello ergibt die Internet-Prüfsumme bc2d: Seine 5 Bytes werden zu 16-Bit-Wörtern gepaart, mit zurückgeführten Überträgen addiert, und die Summe wird invertiert. Fügen Sie einen Header in Hex ein, um eine IPv4-, TCP- oder UDP-Prüfsumme zu bestätigen. Kostenlos in Ihrem Browser.

Kostenlos
Läuft in Ihrem Browser
Ohne Anmeldung
Ihre Daten bleiben auf Ihrem Gerät

Im Browser ausführen – kostenlos API ansehen

Nutzen Sie es über WebAPIE-MailTelegramApp bald

Rechenbeispiel

Wenn Sie eingeben

Text: hello
Berechnungsmodus: Text

Erhalten Sie

Prüfsumme: bc2d
Internet-Prüfsumme (Ganzzahl): 48.173
Bytes: 5
Algorithmus: Internet checksum (RFC 1071)

Die Internet-Prüfsumme ist das sechzehn Bit breite Einserkomplement-Residual aus RFC 1071 und wird in IPv4, TCP und UDP verwendet, damit Empfänger versehentliche Beschädigung von Headern und Nutzlasten erkennen. Dieses Werkzeug akzeptiert Klartext (als UTF-8 serialisiert) oder einen hexadezimalen Byte-Dump, faltet die Bytes als big-endian-Wörter zu sechzehn Bit mit Carry-Rückführung und liefert das Einserkomplement als vierstellige hexadezimale Zeichenkette in Kleinbuchstaben plus die passende vorzeichenlose Ganzzahl. Leere Eingabe ist gültig und ergibt ffff, das natürliche Komplement einer Nullsumme.

Was die Internet-Prüfsumme nach RFC 1071 ist und wie Wörter gebildet werden

RFC 1071 spezifiziert ein einfaches Integritätsresidual: Behandeln Sie die Nachricht als Folge von sechzehn-Bit-Wörtern in Netzwerk-Byte-Reihenfolge, addieren Sie sie mit Einserkomplement-Arithmetik, sodass Überträge in die niedrigen sechzehn Bit zurückgefaltet werden, und nehmen Sie das Einserkomplement dieser Summe. Das Ergebnis ist ein sechzehn-Bit-Wert, der üblicherweise als vier Hexadezimalziffern dargestellt wird. Dieser Rechner für die Internet-Prüfsumme implementiert genau diese Faltung.

Im Modus text wird die Eingabezeichenkette zuerst als UTF-8 kodiert, damit Multibyte-Zeichen ihre echten Leitungsbytes beitragen; im Modus hex wird die Zeichenkette nach dem Entfernen von Leerzeichen, Doppelpunkten, Bindestrichen, Unterstrichen und optionalen Null-x-Präfixen als rohe Oktette geparst. Wörter werden big-endian gebildet: das erste Byte jedes Paares ist die obere Hälfte und das zweite die untere Hälfte, wie IP-, TCP- und UDP-Header auf der Leitung.

Ist die Byte-Länge ungerade, wird das letzte Byte als obere Hälfte eines Wortes mit Null im unteren Byte behandelt, wie in Abschnitt 4.1 des RFC beschrieben, sodass jedes Byte mitwirkt, ohne Daten außer einem einzigen Null-Pad zu erfinden. Leere Nutzlast erzeugt eine Nullsumme, deren Einserkomplement ffff ist—die Identität, die oft genutzt wird, wenn ein Feld unbenutzt ist. Der Algorithmus ist absichtlich nicht kryptografisch: er ist günstig, erkennt viele versehentliche Bit-Kipps und abgeschnittene Einfügungen und ist das Residual, das Router und Stacks bereits erwarten.

Es ist weder CRC-32 noch Fletcher-32 noch ein Mitglied einer Hash-Familie. Wenn ein Drittanbieter-Tool bei denselben Bytes abweicht, nutzt es fast immer little-endian-Packung, eine andere Pad-Regel, ein CRC-Polynom oder eine andere Kodierung derselben Zeichen.

Wo die Internet-Prüfsumme nützlich ist

Netzwerkingenieure fügen kurze Header-Dumps in einen Rechner für die Internet-Prüfsumme ein, wenn sie die IPv4-Header-Prüfsumme oder ein TCP- und UDP-Residual über Pseudo-Header plus Segment neu berechnen müssen, ohne einen vollständigen Stack zu starten. Support-Teams berechnen Prüfsummen aus Ticket-Hex neu, um zu bestätigen, dass ein eingefügter Frame unterwegs nicht abgeschnitten oder neu beabstandet wurde. Continuous-Integration-Jobs pinnten bekannte Vektoren wie die UTF-8-Zeichenkette hello und einen klassischen Multi-Byte-Hex-Dump, damit jede versehentliche Endianness- oder Pad-Regel-Drift den Build sofort scheitern lässt.

Halten Sie Nutzlasten unter der dokumentierten Zeichendecke, behandeln Sie das Feld checksum als kanonisches Einfügeziel, und Sie erhalten reproduzierbare RFC-1071-Werte für Dokumentation, SDKs, Edge-Worker und Klassendemonstrationen, ohne einen separaten Prüfsummen-Dienst aufzusetzen.

Anwendungsfälle

Prüfung von IP-, TCP- und UDP-Headern

Berechnen Sie das RFC-1071-Residual über einen eingefügten Header- oder Pseudo-Header-Hex-Dump neu, um IPv4-, TCP- oder UDP-Prüfsummenfelder ohne vollständigen Netzwerkstack zu bestätigen.

Häufige Fragen

Wie berechnet man eine Internet-Prüfsumme (RFC 1071)?

Standardmodus ist text (UTF-8-Bytes). Setzen Sie mode auf hex für rohe Oktette.

Was ist der Unterschied zwischen Text- und Hex-Modus?

Der Text-Modus kodiert die Zeichenkette als UTF-8 und prüft diese Bytes. Der Hex-Modus parst hexadezimale Oktette (Leerzeichen, Doppelpunkte, Bindestriche und 0x erlaubt).

Ist die Internet-Prüfsumme ein kryptografischer Hash?

Nein. RFC 1071 erkennt versehentliche Beschädigung schnell und passt zu IP/TCP/UDP-Stacks; sie ist nicht dafür ausgelegt, bewusste Kollision oder Fälschung abzuwehren. Nutzen Sie SHA-Familie-Werkzeuge, wenn Sie einen kryptografischen Digest brauchen.

Warum weicht mein Ergebnis von einem anderen Werkzeug ab?

Meist ordnet das andere Werkzeug die Bytes in umgekehrter Reihenfolge an, füllt ein einzelnes letztes Byte anders auf, rechnet eine CRC oder kodiert die Zeichen anders. Hier bildet das erste Byte jedes Paars die obere Hälfte, wie in IP-, TCP- und UDP-Headern.

Warum ergibt eine leere Eingabe ffff?

Ohne Bytes ist die Summe null, und das Einerkomplement von null ist ffff. Dieser feste Wert statt einer Fehlermeldung hilft, wenn Sie Prüfsummen über optionale Angaben bilden, die auch leer sein können.

Für Entwickler — API-Zugang

Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.

Endpunkt

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

Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.

Aufruf aus Ihrem 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)

Beispiel-Anfrage

{
  "text": "hello"
}

Beispiel-Antwort

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

Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Preis

pro Anfrage$0.002

Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.

Fehler

HTTP	Code	Bedeutung
`401`	`unauthorized`	Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer).
`402`	`insufficient_balance`	Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht.
`404`	`unknown_type`	Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog.
`429`	`rate_limited`	Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Technische Hinweise

Fehlerhaftes Hex—ungerade Nibble-Anzahl oder Nicht-Hex-Zeichen nach dem Entfernen von Leerzeichen, Doppelpunkten, Bindestrichen und optionalen Null-x-Präfixen—löst invalid_input ohne Abrechnung aus. Kein Netzaufruf, kein Zufallssalz und keine Wanduhr gehen in die Berechnung zum veröffentlichten Basispreis $0.002 ein.

Eingabevertrag, Text- versus Hex-Modus und Antwortfelder

Optionales mode wählt die Interpretation: text (Standard) kodiert die Zeichenkette als UTF-8; hex parst hexadezimale Oktette. Die leere Zeichenkette ist absichtlich erlaubt: Pipelines, die optionale Felder prüfen, brauchen ein stabiles Residual ffff statt eines harten Fehlers. Mode spiegelt den aufgelösten Modus wider, algorithm ist immer die Bezeichnung Internet checksum mit RFC 1071 in Klammern, und rfc ist immer die Zeichenkette 1071, damit OpenAPI-Beispiele und Support-Antworten das Profil ohne Mehrdeutigkeit zitieren können. Es gibt keinen Modus-Schalter für CRC, Fletcher oder kryptografische Digests: Nutzen Sie eine eigene Fähigkeit, wenn das die Suchabsicht ist, damit jede Landingpage fokussiert bleibt. Senden Sie einen JSON-Body mit dem Pflichtfeld text auf die Zeichenkette, deren Prüfsumme Sie berechnen möchten. Die Aliase input, value, s, string, content und data werden akzeptiert, damit ältere Formulare und kurze Clients weiterhin binden. Endliche Zahlen und große Ganzzahlen werden vor der Verarbeitung in Zeichenketten umgewandelt; Objekte, Arrays, Booleans, null, Infinity und NaN lösen invalid_input aus und werden nicht abgerechnet. Wenn die resultierende Byte-Länge null ist, setzt die Antwort empty auf true, checksum auf ffff, checksum_int auf fünfundsechzigtausendfünfhundertfünfunddreißig und bytes auf null. Bei nicht leerer Eingabe ist empty false, bytes entspricht der Nutzlastlänge, checksum ist das vierstellige Hex-Residual in Kleinbuchstaben ohne Null-x-Präfix, und checksum_int ist derselbe Wert als vorzeichenlose sechzehn-Bit-Ganzzahl, nützlich in Sprachen, die Zahlen gegenüber Zeichenketten bevorzugen. Im Hex-Modus müssen die verbleibenden Zeichen nach dem Entfernen der Trennzeichen eine gerade Anzahl hexadezimaler Ziffern sein; jedes andere Zeichen oder eine ungerade Nibble-Anzahl ist fehlerhaftes Hex und scheitert mit invalid_input.

Wo eine API für die Internet-Prüfsumme ihren Nutzen bringt

Bildungslabore nutzen denselben Endpoint, um zu zeigen, dass das Kippen eines Bits die vier Hex-Ziffern ändert und so Fehlererkennung ohne kryptografische Maschinen oder containerisierte Paketwerkzeuge illustriert. Weil die Implementierung reines Parse der Stufe A ist, kostet jeder erfolgreiche Aufruf den veröffentlichten Basispreis $0.002 ohne Modell-Tokens und ohne ausgehendes Netz; fehlgeschlagene Validierung wird nicht berechnet.

Integrationsbeispiele

CI-Golden-Vektoren für Protokollcode

Pinnen Sie Text- und Hex-Fixtures (einschließlich leer → ffff), damit Continuous Integration Endianness-, Pad-Regel- oder UTF-8-Drift in Prüfsummen-Helfern erkennt.

Klassen- und Ticket-Demos

Zeigen Sie Studierenden und Operatoren, wie das Ändern eines Bytes die vierstellige Internet-Prüfsumme ändert—mit dem kostenlosen Browser-Widget oder einem einzelnen API-Aufruf.

Technische Fragen

Was passiert bei leerer Eingabe?

Leere Nutzlast ist gültig. Die Antwort setzt empty auf true, checksum auf ffff, checksum_int auf 65535 und bytes auf 0. Fehlendes oder nicht-string-text löst invalid_input aus.

Was kostet das Werkzeug für die Internet-Prüfsumme?

Das Browser-Widget ist kostenlos. API-Anfragen nutzen vorabbezahltes KIT-Guthaben zu $0.002 pro erfolgreichem Aufruf; ungültige Eingabe wird nicht abgerechnet.

Vollständige KIT-Dokumentation lesen →