Português (Brasil)

Ferramentas de desenvolvedor · Codificador e decodificador URL

Como codificar um mailto: link com assunto, quebras de linha do corpo e e comercial

· Por que é importante

mailto codificação de URL HTML

Estrutura de link Mailto com assunto e corpo codificados
Ilustração vetorial original ToolAcre

Um link mailto: com assunto e corpo é URL, portanto, espaços, quebras de linha e & devem ser codificados em porcentagem. Esta postagem mostra o que quebra quando não existe e como construir um link que abre corretamente em clientes de e-mail.

O link de contato cujo assunto parou no primeiro espaço — um mailto concreto quebrado: e o que o cliente de email recebeu

Links de contato como <a href="mailto:test@example.com?subject=Support Inquiry">Send</a> são interrompidos porque espaços em "Consulta de suporte" encerram links em clientes de e-mail. Muitos clientes recebem apenas “Suporte” como assunto. Isso ocorre porque os links mailto: seguem RFC 6068, especificando que espaços e caracteres especiais requerem codificação percentual nos parâmetros de consulta. E comerciais precisam de codificação %26 para evitar serem separadores de parâmetros.

Mailto: links quebrados demonstram claramente o problema. Links construídos como <a href="mailto:test@example.com?subject=Support Inquiry&body=Reply">Contact</a> resultam apenas em mensagens com assunto "Suporte". Testes em diferentes clientes de e-mail revelam tolerâncias variadas: o Apple Mail lida parcialmente com links, o Gmail mostra apenas "Suporte", o Outlook falha completamente.

mailto: é um esquema URL - RFC 6068 resumidamente e quais partes são a string de consulta

RFC 6068 define mailto: URL esquemas com regras de codificação específicas do componente. Ao contrário dos URLs normais, mailto: possui regras específicas por componente. As partes do endereço (test@example.com) permanecem não codificadas; @ e domínios são estruturais. Os parâmetros de consulta (assunto, corpo, cc, cco) precisam de codificação. RFC 6068 faz referência a RFC 3986 para regras, exigindo codificação percentual para espaços e caracteres especiais. Os e comerciais dentro dos valores tornam-se %26 quando aparecem como dados, não como delimitadores.

Compreender mailto: a estrutura do esquema evita erros de codificação. O formato é: mailto:endereço?parâmetro1=valor1&parâmetro2=valor2. Os pontos de interrogação introduzem seções de consulta. Os parâmetros que separam o e comercial permanecem não codificados; apenas o "e" comercial dentro dos valores é codificado como %26. Se os assuntos contiverem "Tom & Jerry", codifique como Tom%20%26%20Jerry. Os e comerciais entre sujeito e corpo permanecem não codificados. Essa codificação aninhada é propensa a erros.

Codificando o assunto e o corpo — espaços como %20, quebras de linha como %0D%0A e & como %26 valores internos

A codificação de assuntos e corpos requer um tratamento cuidadoso de espaços e caracteres especiais. Os espaços tornam-se %20 nos links mailto:, e não sinais de mais, ao contrário dos formulários HTML. Essa diferença crítica confunde os desenvolvedores familiarizados com formulários da web. As quebras de linha são codificadas como %0D%0A (CRLF finais de linha no e-mail). E comercial se torna %26. Os sinais de porcentagem tornam-se %25. Os assuntos normalmente contêm espaços, acentos e parênteses. Os corpos contêm espaços, acentos e quebras de linha.

Codificações comuns em links mailto: incluem: espaços como %20, novas linhas como %0D%0A, e comercial como %26, porcentagem como %25, hash como %23, pergunta como %3F. Acentos não semelhantes a ASCII primeiro são convertidos em UTF-8 bytes e depois codificados por porcentagem. "Über relatório" torna-se %C3%9ber%20report. "Olá! Adeus" se torna Olá%21%0D%0AAdeus. Codificar apenas valores, não estruturais? e & caracteres.

Exemplo resolvido: construção de um link com assunto, corpo de duas linhas e cc — o resultado codificado e como ele aparece em um cliente de e-mail

Exemplo resolvido: construção de vínculos com o assunto “Agenda da reunião (setembro)”, corpo “Vamos discutir: Metas trimestrais" e cc "manager@example.com" demonstram a codificação completa. Os assuntos precisam de: espaços como %20, parênteses como %28 e %29. Os órgãos precisam de: "Vamos discutir:" praticamente inalterado (o espaço é %20), quebras de linha como %0D%0A, "Metas trimestrais" praticamente inalteradas. O campo cc não requer codificação.

O mailto resultante: é: mailto:contact@example.com?subject=Reunião%20agenda%20%28Set%29&body=Let%20us%20discuss%3A%0D%0AQuarterly%20goals&cc=manager@example.com. Os testes em navegadores revelam diferentes interpretações do cliente de e-mail. O Gmail abre janelas de composição com assunto correto, corpo de duas linhas e cc. O Outlook mostra resultados semelhantes. Apple Mail requer permissões. Clientes mais velhos falham na falta de apoio corporal.

Por que + está errado aqui - mailto: segue RFC 3986, não codificação de formulário, então + permanece um ponto positivo

Por que os sinais de mais estão errados - mailto: segue RFC 3986, não a codificação do formulário, então o sinal de mais permanece literal - esclarece distinções críticas. A codificação de formulário HTML usa mais para espaços em strings de consulta. RFC 3986 e RFC 6068 especificam %20 para espaços. Um mailto: com subject="Meeting+Agenda" cria assuntos com sinais de adição literais, não espaços. Este erro acontece ao copiar a lógica de codificação de formulário para mailto: geração. Mais significa mais, não espaço.

Por que isso é importante: desenvolvedores copiando a lógica de envio do formulário GET para mailto: geração de links de quebra. O assunto “Agenda da Reunião” passa a ser “Reunião+Agenda” nos formulários. Nos links mailto:, ele cria "Reunião + Agenda" com vantagens literais. Os usuários corrigem manualmente as linhas de assunto. Testar links mailto: requer clicar neles ou examinar links gerados, não analisar regras de formulário.

Erros comuns - esquecer de HTML-escapar dos separadores & no href e codificar percentualmente o @ no endereço

Mailto comum: erros de construção incluem esquecer HTML e comercial escapando em atributos href. Em HTML, o e comercial nos atributos deve ser &amp; para XHTML válido. href="mailto:address?subject=Test&body=Test" é inválido HTML; deveria ser href="mailto:address?subject=Test&amp;body=Test". Isso representa uma codificação diferente da codificação URL. Os analisadores HTML interpretam &amp; como e antes dos navegadores processarem URLs.

Testar esses erros requer examinar a fonte HTML e os consoles do navegador. Clique com o botão direito e selecione "Inspecionar elemento" para visualizar os valores href reais. Copie e cole os valores href nas barras de endereço (com prefixo mailto:) e verifique os clientes de e-mail. Alguns links de e-mail funcionam em determinados navegadores, mas não em outros. O teste automatizado é difícil porque mailto: envolve clientes externos, tornando comum a verificação manual.

O que isso não cobre – diferenças de suporte ao cliente de e-mail e vários destinatários em profundidade

O que isso não cobre inclui diferenças de suporte ao cliente de e-mail e vários destinatários. Nem todos os clientes suportam igualmente os parâmetros RFC 6068. O parâmetro body tem amplo suporte, mas alguns clientes mais antigos o ignoram. Os parâmetros cc e bcc possuem suporte variável. Vários destinatários exigem endereços de e-mail separados por vírgulas, codificando vírgulas como %2C para endereços complexos. Diferentes localidades requerem codificação UTF-8 adequada para exibição.

A evolução do cliente de email afeta o comportamento mailto: entre plataformas. Os clientes de webmail modernos (Gmail, Outlook.com) têm melhor conformidade com RFC 6068 do que os clientes de desktop mais antigos. Os clientes móveis às vezes têm uma análise mais rigorosa. Alguns oferecem suporte a rich text, enquanto outros oferecem suporte apenas a texto simples. Os desenvolvedores devem testar com clientes de e-mail que seus públicos realmente usam. As implementações reais variam apesar das especificações RFC 6068.

Conclusão: codifique cada valor, mantenha a estrutura - como o modo de valor único do codificador e decodificador URL fornece o assunto codificado e o corpo para colar

Conclusão: codifique cada valor, mantenha a estrutura - o modo de valor único do codificador e decodificador URL produz assuntos e corpos codificados prontos para serem colados em links. A ferramenta aceita valores não codificados como "Agenda da reunião (setembro)" e produz "Reunião%20agenda%20%28Sept%29". Copie a saída diretamente nos atributos mailto: href. Para corpos multilinhas, cole versões em texto simples com quebras de linha, obtendo versões codificadas em %0D%0A.

A melhor prática monta mailto: links a partir de partes codificadas em vez de construção manual. Ao construir HTML dinamicamente em JavaScript ou modelos, codifique cada parâmetro separadamente antes de concatenar com & separadores. Para codificador e decodificador estático HTML, URL testa de forma confiável a codificação antes de escrever à mão. Processos de codificação de documentos em comentários de código. Teste os links mailto: resultantes clicando neles com clientes de email reais antes da implantação.