Ferramentas de texto e do dia a dia · Kit de ferramentas de QR e código de barras
Por que o texto acentuado às vezes é lido incorretamente em códigos QR: conjuntos de caracteres e ECI
· Fundo
código QR codificação processamento do navegador
Explica por que a interpretação de bytes padrão do padrão QR não é UTF-8, o que o mecanismo de interpretação de canal estendido faz e por que alguns leitores mostram mojibake para texto acentuado ou não latino.
O nome digitalizado como 'É' - a aparência do mojibake em um código QR decodificado e por que isso acontece
Mojibake como é aparece quando UTF-8 bytes são interpretados em outro mapeamento de caracteres. ToolAcre aborda essa falha antes da geração da matriz usando TextEncoder e seus testes de ida e volta com exemplos de japonês e emoji.
A corrupção é silenciosa porque o QR pode permanecer estruturalmente válido. Um scanner decodifica bytes, aplica uma interpretação diferente de caracteres e mostra o texto errado, de modo que os padrões de localização e a correção de erros parecem funcionar. Os testes de regressão de ToolAcre comparam a saída decodificada com amostras originais, como `café`, texto em japonês e emoji. Isso detecta corrupção semântica que um instantâneo visual de módulos pretos nunca poderia detectar.
ToolAcre pré-codifica UTF-8 bytes para evitar o comportamento padrão Latin-1 da dependência
A dependência QR subjacente trata sua string de modo de byte como dados de passagem Latin-1. ToolAcre converte primeiro o texto pretendido em UTF-8 bytes e mapeia cada byte para uma unidade de código, para que a biblioteca receba os octetos corretos em vez de caracteres corrompidos.
O wrapper de conversão cria um `Uint8Array`, processa-o em partes e cria uma string binária cujas unidades de código são iguais aos valores de byte UTF-8. A passagem Latin-1 da biblioteca preserva esses valores em vez de recodificar os caracteres JavaScript originais. A fragmentação evita passar um número excessivo de argumentos para `String.fromCharCode`, enquanto evitar uma mutação da biblioteca global mantém outros chamadores isolados.
ECI é apenas em segundo plano; esta implementação não pretende emitir um cabeçalho ECI
A Interpretação Estendida de Canal pode rotular a codificação de caracteres em sistemas QR, mas nenhuma emissão ECI aparece nesta implementação. Este artigo, portanto, não promete um cabeçalho ECI nem descreve um como o mecanismo por trás do suporte UTF-8 de ToolAcre.
ECI seria um sinal separado para um decodificador, mas ToolAcre não solicita nem expõe um. Sua estratégia de compatibilidade consiste em UTF-8 bytes corretos mais teste de dispositivo, não em um cabeçalho de codificação anunciado. Esta distinção é importante no suporte: uma viagem de ida e volta bem-sucedida ao repositório comprova a preparação de bytes e a recuperação de matriz; não pode provar que todo leitor externo escolhe a mesma interpretação de caracteres em todos os contextos de carga útil.
Os testes de repositório comprovam viagens de ida e volta da matriz, e não o comportamento em aplicativos de câmera de terceiros nomeados
O repositório decodifica matrizes geradas em testes e prova seu próprio ida e volta de bytes. Ele não testa todos os aplicativos de câmera, portanto, alegações sobre leitores que adivinham UTF-8 ou falham em plataformas específicas exigem evidências de dispositivos separados.
O decodificador de unidade usado nos testes é controlado e valioso para regressão, mas não é um catálogo de aplicativos de câmera. Registre os resultados dos dispositivos que o público realmente usa, incluindo a string decodificada em vez de “digitalização bem-sucedida”. Dois aplicativos podem reconhecer um código enquanto um exibe o mojibake. Relate essa diferença como evidência de compatibilidade do leitor em vez de alterar os bytes de ToolAcre sem entender o decodificador.
Reduzindo o risco — mantendo as cargas úteis em ASCII sempre que possível, caminhos não ASCII com codificação URL e testando em mais de um telefone
Mantenha as cargas concisas, prefira URLs HTTPS comuns quando eles puderem representar conteúdo multilíngue em uma página da web e teste texto direto não ASCII em dispositivos compatíveis. A codificação URL pode alterar os bytes de URL e deve preservar a semântica de destino.
Um URL estável geralmente reduz esse risco porque uma apresentação não ASCII pode permanecer na página de destino enquanto a carga QR permanece um endereço ASCII conciso. Se um caminho URL contiver caracteres internacionais, preserve seu destino codificado correto e teste-o; a codificação ou transliteração cegamente percentual pode alterar o roteamento. Para contato direto ou texto simples, mantenha a matriz de teste pequena e digitalize com mais de um leitor compatível.
Exemplo resolvido: verifique UTF-8 viagens de ida e volta na implementação e teste leitores externos separadamente
Codifique café, 日本 e um emoji em códigos de teste separados, confirme se o decodificador do repositório retorna o texto original e, em seguida, digitalize as imagens exportadas com os aplicativos reais que seu público usa. Registre as diferenças em vez de generalizar a partir de um telefone.
Use três cargas separadas – `café`, uma frase curta em japonês e um emoji – e decodifique cada uma com o caminho de teste do repositório e os aplicativos de telefone selecionados. Compare caracteres Unicode exatos, não capturas de tela ou semelhança visual. Se um aplicativo falhar, guarde o código exportado e os bytes decodificados para diagnóstico. A regeneração repetida a partir de entradas idênticas deve produzir a mesma matriz e não corrigirá a diferença de interpretação do leitor.
O que isso não cobre - especificações do Shift JIS do modo kanji e renderização de fonte no dispositivo de digitalização
Os detalhes do Shift JIS no modo Kanji e a renderização da fonte após a decodificação estão fora da implementação. QR armazena bytes; o scanner e a interface de destino decidem como os caracteres decodificados são apresentados à pessoa que segura o telefone.
O modo Kanji, Shift JIS e seleção de fonte pós-decodificação estão fora da implementação. Mesmo o Unicode correto pode ser renderizado com um glifo ausente em um dispositivo que não possui uma fonte adequada, o que é diferente de receber caracteres errados. Corrupção de bytes separada, interpretação do decodificador e exibição de fontes ao documentar uma falha; eles ocorrem em estágios diferentes e exigem soluções diferentes.
Conclusão: teste qualquer carga útil não ASCII antes de imprimir; o QR & Barcode Toolkit gera localmente para que você possa iterar rapidamente
A afirmação verificada de ToolAcre é forte, mas limitada: ela prepara UTF-8 bytes corretamente e percorre cadeias de teste multilíngues de ida e volta. Uma versão impressa com cargas não ASCII ainda merece testes representativos do leitor.
O critério de liberação para impressão multilíngue é a recuperação exata em leitores representativos. ToolAcre fornece preparação UTF-8 verificada e geração local, e seu contador de bytes reflete o custo multibyte. O editor ainda deve preservar o artefato testado, evitar edições de carga útil não revisadas e divulgar os requisitos do leitor onde a compatibilidade for limitada. A codificação correta é necessária, mas o usuário experimenta toda a cadeia de decodificação, interpretação e exibição.