Além disso, deve ser codificado em mailto: hiperlinks?

Ao colocar um endereço de email com uma etiqueta de endereço (também conhecido como sub-endereçamento) em um hiperlink mailto …

<a href="mailto:username+foo@example.com">mail us now!</a>

… O sinal de mais no email deve ser codificado em URL?

<a href="mailto:username%2Bfoo@example.com">mail us now!</a>

Não consigo descobrir isso, e a documentação é conflitante. Nossos testes no mundo real também produziram resultados mistos, tornando-os ainda mais confusos.

O sinal de mais é usado para codificar espaços em URLs, não em HTML e nem em SMTP (RFC2821). No entanto, como mailto:address@server.comé um URI (possui um protocolo, o separador e o endereço do protocolo), deve ser tratado como um URI e deve ser codificado em porcentagem .

Portanto, cabe ao cliente resolver com precisão a representação codificada e decodificá-la na medida do necessário. Aqui está a opinião oficial da Microsoft sobre o assunto .

Você deve aplicar a codificação de URL em mailto: URLs incorporados em HTML se os caracteres no endereço de email forem reservados por URI. Isso garante que você esteja fazendo a coisa correta. Cabe ao cliente decodificar o URI adequadamente de onde é recebido. Sim, this+address@gmail.comé um email muito válido; sim this%2Baddress@gmail.comtambém é válido. Sim, esses dois são diferentes, mas se eles serão tratados de maneira diferente depende do cliente ...

Como você observou anteriormente, nem todos os clientes processam isso corretamente. Sugiro encontrar o cliente mais provável (gmail? Clientes baseados em navegador? Outlook?) Que seus usuários usarão e farão o que esse cliente faz. Você disse que testou no GMail? Como você testou? Com um "mailto: client baseado no navegador (como complementos à oferta do firefox e do gmail), o URI provavelmente não está sendo decodificado (como deveria ser).

Você pode codificar +, mas você não precisa.

Primeiro, precisamos concordar que este mailtoé um exemplo de um URI genérico, especificado pela RFC 2396 . (É isso que XHTML e HTML 4 usam).

Agora vamos descobrir a lista de caracteres reservados no RFC 2396.

reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
              "$" | ","

O URI se divide em absoluto e relativo:

URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]

E porque o esquema mailto:é especificado, este é um URI absoluto:

absoluteURI   = scheme ":" ( hier_part | opaque_part )

E já que ambos os padrões para hier_partcomeçar /, mailtoé uma parte opaca.

opaque_part   = uric_no_slash *uric

uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" |
                "&" | "=" | "+" | "$" | ","

uric          = reserved | unreserved | escaped

Portanto, a restrição é que você precisa escapar /se for o primeiro caractere, mas depois disso você poderá colocar caracteres reservados, incluindo +e @.

Aqui está outra RFC para apoiar isso. Nas últimas RFCs do esquema mailto publicadas em 2010, denominadas RFC 6068 , ele diz:

'mailto'Da mesma forma, o software que cria URIs deve ter o cuidado de codificar qualquer caractere reservado usado. Os formulários HTML são um tipo de software que cria 'mailto'URIs. As implementações atuais codificam um espaço como '+', mas isso cria problemas porque essa '+'posição para um espaço não pode ser distinguida da real '+'em um 'mailto' URI. Ao produzir 'mailto'URIs, todos os espaços devem ser codificados como %20, e '+'caracteres podem ser codificados como %2B. Observe que os '+' caracteres são frequentemente usados ​​como parte de um endereço de email para indicar um sub-endereço, como por exemplo em <bill+ietf@example.org>.

Uma leitura estrita da RFC relevante diz que o "+" deve ser codificado.

A seção 2, parte superior da página 2 em http://tools.ietf.org/html/rfc2368, diz:

"Observe que todos os caracteres reservados da URL em" para "devem ser codificados: em particular, parênteses, vírgulas e o sinal de porcentagem ("% "), que geralmente ocorrem na sintaxe da" caixa de correio "."

O RFC para URIs (http://tools.ietf.org/html/rfc3986#section-2.2) lista "+" como um caractere reservado.

Dito isto, o que é "correto" não é necessariamente o que funcionará em todos os navegadores. Alguns navegadores obviamente sempre lidam com as coisas corretas como se estivessem erradas e as incorretas como se estivessem certas.

Edit: Quanto ao RFC6068 e seu "MAIO", eu leria isso como dependente do contexto. Se você estiver escrevendo o URL para leitura de texto, "+" faria mais sentido; no entanto , se você estiver escrevendo em HTML, a interpretação mais rigorosa do RFC3986 estará mais alinhada com as idéias "válidas em HTML" e, portanto, qualquer coisa que use o valor deve espere que seja codificado.

Por nova RFC http://tools.ietf.org/html/rfc6068#section-5

  ... '+' MAY BE encoded as %2B

Então acho que a resposta é não, mas talvez?

Eu acho que codificá-lo ou não, não fará uma diferença real. O problema são os clientes de email. Por exemplo, o Yahoo Mail usa apenas hífen para subendereço, enquanto o gMail usa o sinal de mais.

Esses são meus 2 centavos ...

EDIT: A resposta abaixo tem um ponto sólido.

O RFC1738

3.5 MAILTO

O esquema de URL mailto é usado para designar o endereço de correspondência da Internet de um indivíduo ou serviço. Nenhuma informação adicional além de um endereço de correspondência na Internet está presente ou implícita.

Um URL mailto assume o formato:

    mailto:<rfc822-addr-spec>

onde é (a codificação de uma) especificação de endereço, conforme especificado na RFC 822 . Nos URLs mailto, não há caracteres reservados.

Observe que o sinal de porcentagem ("%") é comumente usado nos endereços RFC 822 e deve ser codificado.

Ao contrário de muitos URLs, o esquema mailto não representa um objeto de dados a ser acessado diretamente; não há sentido em que designa um objeto. Ele tem um uso diferente do tipo de mensagem / corpo externo no MIME.

Como não há caracteres reservados, ele deve ser codificado.

Por RFC 6068 como mencionado nas respostas, você pode codificar o sinal de mais como %2B.

A razão pela qual há confusão é que converter um espaço em um plus não faz parte da codificação de URL padrão, faz parte da codificação de parâmetro de formulário (ou seja application/x-www-form-urlencoded)

É como a diferença entre PHP rawurlencode()e urlencode().

Portanto, o que a RFC 6068 está dizendo é que uma mailto:URL deve usar a codificação de URL padrão "bruta" (de acordo com a RFC 3986 ), e um sinal de adição que aparece na URL deve sempre ser tratado como um sinal de adição literal e não como um espaço que tenha foi codificado em forma.

Se o cliente local converter o sinal de mais em um espaço, ele será quebrado.