Checksum Internet (RFC 1071)
A palavra hello dá o checksum da Internet bc2d: seus 5 bytes são agrupados em palavras de 16 bits, somados com o vai-um devolvido ao início, e a soma é invertida. Cole um cabeçalho em hexadecimal para conferir o checksum de IPv4, TCP ou UDP. Grátis no seu navegador.
- Grátis
- Funciona no seu navegador
- Sem cadastro
- Seus dados não saem do seu aparelho
Executar grátis
Exemplo resolvido
- Texto
- hello
- Modo de cálculo
- Text
- Soma de verificação
- bc2d
- Soma de verificação da Internet (inteiro)
- 48.173
- Bytes
- 5
- Algoritmo
- Internet checksum (RFC 1071)
O checksum da Internet é o residual de dezesseis bits em complemento de um definido no RFC 1071 e usado em IPv4, TCP e UDP para que os receptores detectem corrupção acidental de cabeçalhos e cargas úteis. Esta ferramenta aceita texto simples (serializado como UTF-8) ou um dump de bytes em hexadecimal, dobra os bytes como palavras de dezesseis bits big-endian com reenvio de carry e devolve o complemento de um como string hex de quatro dígitos em minúsculas mais o inteiro sem sinal equivalente. Entrada vazia é válida e produz ffff, o complemento natural de uma soma zero.
O que é o checksum da Internet RFC 1071 e como as palavras são formadas
O RFC 1071 especifica um residual de integridade simples: trate a mensagem como uma sequência de palavras de dezesseis bits em ordem de bytes de rede, some-as com aritmética de complemento de um para que os carries dobrem de volta nos dezesseis bits baixos e tome o complemento de um dessa soma. O resultado é um valor de dezesseis bits geralmente mostrado como quatro dígitos hexadecimais. Esta calculadora de checksum da Internet implementa exatamente essa dobra.
No modo text a string de entrada é primeiro codificada como UTF-8 para que caracteres multibyte contribuam com seus bytes reais no fio; no modo hex a string é analisada como octetos brutos após remover espaços em branco, dois-pontos, hífens, underscores e prefixos opcionais zero-x. As palavras são formadas big-endian: o primeiro byte de cada par é a metade alta e o segundo a metade baixa, como nos cabeçalhos IP, TCP e UDP no fio.
Se o comprimento em bytes for ímpar, o byte final é tratado como a metade alta de uma palavra com byte baixo zero, conforme a seção 4.1 do RFC, de modo que cada byte participe sem inventar dados extras além de um único pad zero. Carga vazia produz soma zero cujo complemento de um é ffff, a identidade frequentemente usada quando um campo não é usado.
O algoritmo não é criptográfico de propósito: é barato, detecta muitas inversões acidentais de bits e colagens truncadas, e é o residual que roteadores e pilhas já esperam. Não é CRC-32, nem Fletcher-32, nem membro de família de hashes. Se uma ferramenta de terceiros discordar nos mesmos bytes, quase sempre usa empacotamento little-endian, outra regra de pad, um polinômio CRC ou outra codificação dos mesmos caracteres.
Onde o checksum da Internet é útil
Engenheiros de rede colam dumps curtos de cabeçalho em uma calculadora de checksum da Internet quando precisam recalcular o checksum do cabeçalho IPv4 ou um residual TCP e UDP sobre um pseudo-cabeçalho mais segmento sem subir uma pilha completa. Equipes de suporte recalculam checksums a partir do hex do ticket para confirmar que um quadro colado não foi truncado ou reespaçado em trânsito.
Jobs de integração contínua fixam vetores conhecidos como a string UTF-8 hello e um dump hex multibyte clássico para que qualquer deriva acidental de endianness ou regra de pad falhe o build imediatamente. Mantenha as cargas sob o teto de caracteres documentado, trate o campo checksum como destino canônico de colagem, e você obtém valores RFC 1071 reproduzíveis para docs, SDKs, workers na borda e demos de sala de aula sem levantar um serviço de checksum separado.
Casos de uso
Verificação de cabeçalhos IP, TCP e UDP
Recalcule o residual RFC 1071 sobre um dump hex de cabeçalho ou pseudo-cabeçalho colado para confirmar campos de checksum IPv4, TCP ou UDP sem uma pilha de rede completa.
Perguntas frequentes
Como calcular um checksum da Internet (RFC 1071)?
O modo padrão é text (bytes UTF-8). Defina mode como hex para octetos brutos.
Qual é a diferença entre o modo text e o modo hex?
O modo text codifica a string em UTF-8 e calcula o checksum sobre esses bytes. O modo hex analisa octetos hexadecimais (espaços, dois-pontos, hífens e 0x permitidos).
O checksum da Internet é um hash criptográfico?
Não. O RFC 1071 detecta corrupção acidental com rapidez e coincide com pilhas IP/TCP/UDP; não foi projetado para resistir a colisão ou falsificação deliberada. Use ferramentas da família SHA quando precisar de um digest criptográfico.
Por que meu resultado é diferente do de outra ferramenta?
Quase sempre a outra ferramenta agrupa os bytes na ordem inversa, completa de outro jeito um último byte sozinho, usa um CRC ou codifica os caracteres de outra forma. Aqui o primeiro byte de cada par é a metade alta, como nos cabeçalhos IP, TCP e UDP.
Por que uma entrada vazia dá ffff?
Sem bytes a soma é zero, e o complemento de um de zero é ffff. Devolver esse valor estável em vez de um erro ajuda quando você calcula o checksum de dados opcionais que podem vir vazios.
Ferramentas relacionadas
Para desenvolvedores — acesso via API
Tudo nesta página está disponível via API. Esta seção é para equipes que querem integrar a ferramenta aos próprios sistemas; quem não precisa disso pode simplesmente usar a ferramenta acima.
Endpoint
Autenticação por token Bearer. Um único POST coloca a tarefa na fila; o resultado chega por webhook ou link assinado.
Chame do seu código
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)Exemplo de requisição
{
"text": "hello"
}Exemplo de resposta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.internet_checksum",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}A API é assíncrona: cada chamada devolve um task_id na hora. Se preferir polling, consulte o status a até 1 requisição por segundo.
Preço
Preço publicado, sem tokens nem créditos escondidos. Tarefa que falha não é cobrada.
Erros
| HTTP | Código | O que significa |
|---|---|---|
401 | unauthorized | Token ausente ou inválido. Confira o header Authorization. |
402 | insufficient_balance | Saldo insuficiente para esta tarefa. Faça uma recarga e tente de novo. |
404 | unknown_type | Esse tipo de tarefa não existe. Confira o campo type no catálogo. |
429 | rate_limited | Muitas requisições em pouco tempo. Espere um instante e tente de novo. |
Notas técnicas
Hex malformado—contagem ímpar de nibbles ou caracteres não hex após remover espaços, dois-pontos, hífens e prefixos opcionais zero-x—gera invalid_input sem cobrança. Nenhuma chamada de rede, sal aleatório ou relógio de parede entra no cálculo ao preço base publicado US$ 0,002.
Contrato de entrada, modo text versus hex e campos de resposta
O mode opcional escolhe a interpretação: text (padrão) codifica a string como UTF-8; hex analisa octetos hexadecimais. String vazia é permitida de propósito: pipelines que somam campos opcionais precisam de um residual ffff estável em vez de falha dura. Mode ecoa o modo resolvido, algorithm é sempre o rótulo Internet checksum com RFC 1071 entre parênteses, e rfc é sempre a string 1071 para que exemplos OpenAPI e respostas de suporte citem o perfil sem ambiguidade. Não há chave de modo para CRC, Fletcher ou digests criptográficos: use uma capacidade dedicada quando essa for a intenção de busca para que cada página de destino permaneça focada. Envie um corpo JSON com o campo obrigatório text igual à string cuja soma de verificação deseja calcular. Os aliases input, value, s, string, content e data são aceitos para que formulários antigos e clientes curtos ainda liguem. Números finitos e big integers são convertidos em string antes do processamento; objetos, arrays, booleanos, null, Infinity e NaN geram invalid_input e não são cobrados. Quando o comprimento resultante em bytes é zero, a resposta define empty como true, checksum como ffff, checksum_int como sessenta e cinco mil quinhentos e trinta e cinco, e bytes como zero. Com entrada não vazia empty é false, bytes iguala o comprimento da carga, checksum é o residual hex de quatro dígitos em minúsculas sem prefixo zero-x, e checksum_int é o mesmo valor como inteiro de dezesseis bits sem sinal, útil em linguagens que preferem números a strings. No modo hex, após remover separadores, os caracteres restantes devem ser uma contagem par de dígitos hexadecimais; qualquer outro caractere ou contagem ímpar de nibbles é hex malformado e falha com invalid_input.
Onde uma API de checksum da Internet rende valor
Laboratórios educacionais usam o mesmo endpoint para mostrar que inverter um bit muda os quatro dígitos hex, ilustrando detecção de erros sem introduzir maquinaria criptográfica ou ferramentas de pacotes em contêiner. Como a implementação é parse pura de nível A, cada chamada bem-sucedida custa o preço base publicado US$ 0,002 sem tokens de modelo e sem rede de saída; validação falha não consome saldo.
Casos de integração
Vetores golden de CI para código de protocolo
Fixe fixtures de texto e hex (incluindo vazio → ffff) para que a integração contínua detecte deriva de endianness, regra de pad ou codificação UTF-8 nos helpers de checksum.
Demos de sala de aula e tickets
Mostre a estudantes e operadores como editar um byte altera o checksum da Internet de quatro dígitos com o widget gratuito do navegador ou uma única chamada API.
Perguntas técnicas
O que acontece com entrada vazia?
Carga vazia é válida. A resposta define empty como true, checksum como ffff, checksum_int como 65535 e bytes como 0. Text ausente ou não string gera invalid_input.
Quanto custa a ferramenta de checksum da Internet?
O widget do navegador é gratuito. Solicitações API usam saldo KIT pré-pago a US$ 0,002 por chamada bem-sucedida; entrada inválida não é cobrada.