Por que o EAN-13 usa pesos 3 e 1, em vez de duplicar dígitos como o Luhn?

São algoritmos diferentes, definidos por organizações diferentes: o GS1 define EAN-13 com pesos fixos 3/1 alternados por posição; a ISO/IEC 7812-1 define Luhn (usado em cartões) com duplicação de dígitos alternados. Ambos são variações de Módulo 10, mas com regras de ponderação distintas — não são intercambiáveis nem produzem o mesmo dígito para a mesma sequência de números.

Um sistema pode calcular o dígito verificador do Code128 da mesma forma que o do EAN-13?

Não. Code128 usa módulo 103 sobre valores mapeados de uma tabela de caracteres específica da simbologia (incluindo os subconjuntos A, B e C), enquanto EAN-13 usa módulo 10 sobre os próprios dígitos decimais. São dois algoritmos de checksum incompatíveis entre si, cada um específico da sua simbologia.

Informar só 12 dígitos para gerar um EAN-13 é diferente de informar os 13?

Na prática, não deveria ser: se os 13 dígitos informados já tiverem um dígito verificador correto, o resultado é o mesmo que informar 12 e deixar a ferramenta calcular o 13º. A diferença só aparece se o 13º dígito informado estiver errado — nesse caso, alguns geradores rejeitam o valor, enquanto outros ignoram o dígito informado e recalculam.

Gerador de Código de Barras

Documentação técnica

Gerador de Código de Barras: EAN-13 e Code128, duas simbologias diferentes

"Código de barras" não é um formato único — é uma categoria de simbologias, cada uma com sua própria forma de codificar dados em barras e seu próprio algoritmo de checksum. Este gerador cobre as duas mais comuns em contextos de e-commerce e logística: EAN-13 (o padrão internacional GS1 usado em praticamente todo produto de varejo, reconhecível pelas barras verticais e o número de 13 dígitos embaixo) e Code128 (uma simbologia alfanumérica de comprimento variável, usada em logística e rastreamento, capaz de codificar letras, números e vários símbolos no mesmo código, não só dígitos).

EAN-13: o dígito verificador do padrão GS1

Um EAN-13 tem 13 dígitos, dos quais os 12 primeiros carregam a informação (prefixo do país/GS1, código do fabricante, código do produto) e o 13º é o dígito verificador. O cálculo, definido pelo GS1, é: a partir da direita, os dígitos em posição ímpar (a 2ª, 4ª, 6ª... a contar do dígito verificador) são multiplicados por peso 3, os de posição par por peso 1; soma-se tudo, e o dígito verificador é o valor que, somado a esse total, fecha no próximo múltiplo de 10 — formalmente, dv = (10 - (soma mod 10)) mod 10. É uma variação relativamente simples de Módulo 10, na mesma família conceitual do algoritmo de Luhn (usado no cartão de crédito deste site), mas com pesos fixos 3/1 em vez da duplicação alternada de Luhn.

Este gerador aceita tanto um EAN-13 completo (13 dígitos) quanto um código parcial de 12 dígitos — nesse segundo caso, o 13º dígito verificador é calculado e adicionado automaticamente, útil para quem já tem o código-base (prefixo + produto) e só precisa do dígito final correto.

Code128: por que não tem "um" dígito verificador simples

Code128 usa um esquema de checksum mais elaborado que EAN-13: cada caractere do conteúdo é mapeado para um valor numérico específico da tabela Code128 (que inclui os três subconjuntos A, B e C, cada um otimizado para um tipo de conteúdo — texto com controle, texto alfanumérico comum, ou pares de dígitos compactados), multiplicado por um peso posicional, somado a um valor de início dependente do subconjunto, e o resultado é reduzido por módulo 103 (não módulo 10 ou 11). Por isso o Code128 aceita texto livre — letras, números e símbolos — sem uma "fórmula de dígito verificador" simples de explicar em uma frase, diferente do EAN-13.

Uso em testes de sistemas de e-commerce e logística

Sistemas de estoque, PDV (ponto de venda) e etiquetagem logística leem código de barras como entrada principal de identificação de produto. Testar a leitura e o parsing desses códigos — seja simulando um leitor de código de barras via input de teclado (a forma como a maioria dos leitores físicos se comunica com o sistema, emulando digitação), seja testando a geração de etiquetas — se beneficia de códigos com checksum real: um EAN-13 com dígito verificador incorreto deveria ser rejeitado pelo sistema antes mesmo de tentar buscar o produto correspondente, e testar esse caminho de rejeição exige gerar deliberadamente tanto códigos válidos quanto inválidos.