¿Debería plus estar codificado en mailto: hipervínculos?

39

Al colocar una dirección de correo electrónico con una etiqueta de dirección (también conocida como subdireccionamiento) en un hipervínculo mailto ...

<a href="mailto:[email protected]">mail us now!</a>

... ¿debería el más en el correo electrónico estar codificado con URL?

<a href="mailto:username%[email protected]">mail us now!</a>

No puedo entender esto, y la documentación es conflictiva. Nuestras pruebas del mundo real también han producido resultados mixtos, lo que lo hace aún más confuso.

hyperlink url-encoding mailto Jeff Atwood
fuente
¿Puedes ser más específico sobre los métodos y resultados de tus pruebas del mundo real? ¿Algunos clientes / servicios de correo electrónico lo tratan correctamente y otros se ahogan? ¿Puedes ser mas específico?
Bryson
1
@bryson Sé que la extensión de Chrome "enviar usando gmail" ha tenido problemas con el plus sin codificar en el mailto: por ejemplo, pero tal vez sea un error.
Jeff Atwood
2
Solo usa el que funcione con Chrome.
Hardwareguy

Respuestas:

22

La ventaja se usa para codificar espacios en URL, no en HTML ni en SMTP (RFC2821). Sin embargo, dado que mailto:[email protected]es un URI (tiene un protocolo, el separador de protocolo y la dirección del protocolo), debe tratarse como un URI y debe codificarse en porcentaje .

Por lo tanto, corresponde al cliente resolver con precisión la representación codificada y decodificarla en la medida adecuada. Aquí está la opinión oficial de Microsoft sobre el asunto .

Debe aplicar la codificación de URL en mailto: URL incrustadas en HTML si los caracteres de la dirección de correo electrónico están reservados a URI. Esto asegura que estás haciendo lo correcto. Depende del cliente decodificar el URI de forma adecuada desde donde se recibe. Sí, [email protected]es un correo electrónico muy válido; Sí this%[email protected]también es válido. Sí, esos dos son diferentes, pero si serán tratados de manera diferente depende del cliente ...

Como notó anteriormente, no todos los clientes representan esto correctamente. Sugiero encontrar el cliente más probable (gmail? Clientes basados ​​en navegador? Outlook?) Que usarán sus usuarios y hacer lo que ese cliente hace. ¿Dijiste que probaste en GMail? ¿Cómo lo probaste? Con un "cliente de mailto: basado en navegador (como los complementos para firefox y la oferta de gmail), lo más probable es que el URI no se decodifique (como debería ser).

Wez Furlong
fuente
¿Alguien tiene datos reales sobre qué funciona dónde?
Wez Furlong
así lo hice hacer una nota específica de lo que Microsoft afirma obras ...
jcolebrand
Esto es perfecto. Gmail no los maneja correctamente, pero dado que Google ignora los informes de errores del usuario, no hay mucho que pueda hacer al respecto.
Matthew leyó el
55
Si tiene codificación +en URI, @también debe codificarse porque también es un carácter reservado. Si lee detenidamente el RFC, descubrirá que, en una parte opaca, +es legal.
Eugene Yokota
Puedo estar equivocado, pero ¿no está reservado separar el nombre de usuario del host (como en [email protected]/path )? Luego, ocuparía su lugar en la dirección, ya que separa el nombre de usuario del host.
Maciej Piechotka
8

PUEDES codificar +, pero no tienes que hacerlo.

Primero, debemos aceptar que mailtoes un ejemplo de un URI genérico, especificado por RFC 2396 . (Esto es lo que usan XHTML y HTML 4).

Ahora descubramos la lista de caracteres reservados en RFC 2396.

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

URI se divide en absoluto y relativo:

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

Y debido a que mailto:se especifica el esquema, este es un URI absoluto: 

absoluteURI   = scheme ":" ( hier_part | opaque_part )

Y dado que ambos patrones para hier_partempezar /, mailtoes una parte opaca.

opaque_part   = uric_no_slash *uric

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

uric          = reserved | unreserved | escaped

Entonces, la restricción es que tienes que escapar /si se trata del primer carácter, pero después de eso puedes poner caracteres reservados incluyendo +y @.

Aquí hay otro RFC para apoyar esto. En las últimas RFC del esquema mailto publicado en 2010 llamado RFC 6068 , dice:

El software que crea 'mailto'URI también debe tener cuidado de codificar los caracteres reservados que se utilizan. Los formularios HTML son un tipo de software que crea 'mailto'URI. Las implementaciones actuales codifican un espacio como '+', pero esto crea problemas porque tal '+'posición para un espacio no se puede distinguir de un real '+'en un 'mailto' URI. Cuando se producen 'mailto'URI, todos los espacios DEBEN codificarse como %20, y los '+'caracteres PUEDEN codificarse como %2B. Tenga en cuenta que los '+' caracteres se utilizan con frecuencia como parte de una dirección de correo electrónico para indicar una subdirección, como por ejemplo en <[email protected]>.

Eugene Yokota
fuente
No estoy completamente familiarizado con esa gramática, sin embargo, enumera los caracteres como separados del grupo no reservado, lo que indica que + es un carácter reservado. No indica que debe estar codificado. Microsoft dice que lo codifique. C'est la vie, espero ver.
jcolebrand
1
Cuando una parte no comienza /, +ya no se convierte en un personaje reservado.
Eugene Yokota
Estoy en desacuerdo. Las "direcciones de correo electrónico" están definidas de manera muy peculiar y, en primer lugar, deben tratarse con cuidado. Ese estándar es muy confuso. Afortunadamente, estamos en desacuerdo aquí.
jcolebrand
8

Una lectura estricta del RFC relevante dice que el "+" debe estar codificado.

La Sección 2, parte superior de la página 2 en http://tools.ietf.org/html/rfc2368 dice:

"Tenga en cuenta que todos los caracteres de URL reservados en" a "deben estar codificados: en particular, paréntesis, comas y el signo de porcentaje ("% "), que comúnmente ocurre en la sintaxis de" buzón ".

El RFC para URI (http://tools.ietf.org/html/rfc3986#section-2.2) enumera "+" como un carácter reservado.

Dicho esto, lo que es "correcto" no es necesariamente lo que funcionará en todos los navegadores. Algunos navegadores obviamente siempre manejarán las cosas correctas como si estuvieran equivocadas y las incorrectas como si estuvieran en lo correcto.

Editar: En cuanto a RFC6068 y su "MAYO", lo leería como dependiente del contexto. Si está escribiendo la URL para la lectura de texto, entonces "+" tendría más sentido, sin embargo , si lo está escribiendo en HTML, la interpretación más estricta de RFC3986 estaría más en línea con las ideas "HTML válidas" y, por lo tanto, cualquier cosa que use el valor debería Esperamos que esté codificado.

IBBoard
fuente
2
En RFC 3986, mailtosería tratado como path-rootless, lo que permite una secuencia pchardefinida por (unreserved / pct-encoded / sub-delims / ":" / "@"). +es parte de sub-delims. Entonces, la lectura estricta dice +que no requiere codificación porcentual.
Eugene Yokota
3

Creo que codificarlo o no, no hará una diferencia real. El problema son los clientes de correo. Por ejemplo, Yahoo Mail solo usa guiones para subdirección mientras que gMail usa el signo más.

Esos son mis 2 centavos ...

EDITAR: La respuesta a continuación tiene un punto sólido.

Bruno
fuente
Es cierto, un buen punto es que hay alguna variación en el subdireccionamiento de correo electrónico, pero los correos electrónicos en este caso están alojados en Gmail, así que sé que el plus es correcto y funcionará cuando el servidor lo reciba, suponiendo que el correo electrónico pase por el cliente.
Jeff Atwood
El problema es que la aplicación analiza la solicitud de URI. Si espera recibir datos URLEncoded, decodificará los datos, pero eso no es justo para usted (codificar falsamente) ni para el cliente (hacer suposiciones). El protocolo no dicta la codificación esperada, el cliente sí. Vea las ediciones adicionales que hago a la A por @Wez
jcolebrand
3

El RFC1738

3.5. MAILTO

El esquema de URL mailto se usa para designar la dirección de correo de Internet de un individuo o servicio. No hay información adicional que no sea una dirección de correo de Internet presente o implícita.

Una URL mailto toma la forma:

    mailto:<rfc822-addr-spec>

donde es (la codificación de un) addr-spec, como se especifica en RFC 822 . Dentro de las URL de mailto, no hay caracteres reservados.

Tenga en cuenta que el signo de porcentaje ("%") se usa comúnmente en las direcciones RFC 822 y debe codificarse.

A diferencia de muchas URL, el esquema mailto no representa un objeto de datos al que se pueda acceder directamente; no tiene sentido designar un objeto. Tiene un uso diferente que el tipo de mensaje / cuerpo externo en MIME.

Como no hay caracteres reservados, debe codificarse.

S.Skov
fuente
y aún por tools.ietf.org/html/rfc6068 "Al producir URI 'mailto', todos los espacios DEBEN estar codificados como% 20, y los caracteres '+' PUEDEN estar codificados como% 2B"
Jeff Atwood
1
Since there are no reserved characters it should be encoded.ummmm eso no tiene ningún sentido.
jcolebrand
@jcolebrand '+' es un carácter especial en el esquema de URL y, por lo tanto, debe codificarse cuando no tiene un rol especial, es decir. cuando no está reservado
S.Skov
@Jeff De hecho, es malo para vivir en un mundo de RFC más antiguo. Entonces tools.ietf.org/html/rfc2119 básicamente le dice que haga lo que le parezca mejor.
S.Skov
eso parece ... al revés en espíritu a la forma en que leí las instrucciones inicialmente.
jcolebrand
3

Según RFC 6068 como se menciona en las respuestas, PUEDE codificar el signo más como%2B .

La razón por la que hay confusión es que convertir un espacio en un plus no es realmente parte de la codificación de URL estándar, es parte de la codificación de parámetros de formulario (es decir,application/x-www-form-urlencoded )

Es como la diferencia entre PHP rawurlencode()yurlencode() .

Entonces, lo que dice RFC 6068 es que una mailto:URL debe usar una codificación URL estándar "sin procesar" (según RFC 3986 ), y un signo más que aparece en la URL siempre debe tratarse como un signo más literal, y no como un espacio que tiene sido codificado en forma

Si el cliente local convierte el plus en un espacio, se rompe.

Alnitak
fuente