ForHosting KIT · Ferramentas para dev

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
Use pelo WebAPIE-mailTelegramApp em breve
Se você digitar
Texto
hello
Modo de cálculo
Text
Você obtém
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.

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.

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.

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.

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

Autenticação por token Bearer. Um único POST coloca a tarefa na fila; o resultado chega por webhook ou link assinado.

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"
  }
}

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.

por chamadaUS$ 0,002

Preço publicado, sem tokens nem créditos escondidos. Tarefa que falha não é cobrada.

HTTPCódigoO que significa
401unauthorizedToken ausente ou inválido. Confira o header Authorization.
402insufficient_balanceSaldo insuficiente para esta tarefa. Faça uma recarga e tente de novo.
404unknown_typeEsse tipo de tarefa não existe. Confira o campo type no catálogo.
429rate_limitedMuitas requisições em pouco tempo. Espere um instante e tente de novo.

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.

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.

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.

Ver a documentação completa do KIT →