Herramientas de desarrollo · Codificador y decodificador de URL
Cómo codificar un mailto: enlace con asunto, saltos de línea del cuerpo y símbolos
· Por qué es importante
enviar por correo codificación de URL html
Un enlace mailto: con asunto y cuerpo es una URL, por lo que los espacios, los saltos de línea y & deben estar codificados en porcentaje. Esta publicación muestra qué se rompe cuando no es así y cómo crear un enlace que se abra correctamente en los clientes de correo.
El enlace de contacto cuyo asunto se detuvo en el primer espacio: un mailto roto concreto: y lo que recibió el cliente de correo
Enlaces de contacto como <a href="mailto:test@example.com?subject=Support Inquiry">Enviar</a> se rompen porque los espacios en "Support Consulta" terminan los enlaces en los clientes de correo. Muchos clientes reciben sólo como asunto "Soporte". Esto ocurre porque los enlaces mailto: siguen RFC 6068, especificando que los espacios y caracteres especiales requieren codificación porcentual en los parámetros de consulta. Los símbolos comerciales necesitan codificación %26 para evitar ser separadores de parámetros.
Correo roto: los enlaces demuestran claramente el problema. Los enlaces creados como <a href="mailto:test@example.com?subject=Support Inquiry&body=Reply">Contacto</a> dan como resultado mensajes con el asunto "Soporte" únicamente. Las pruebas en diferentes clientes de correo revelan tolerancias variables: Apple Mail maneja parcialmente los enlaces, Gmail solo muestra "Soporte", Outlook falla por completo.
mailto: es un esquema de URL: RFC 6068 en resumen, y qué partes son la cadena de consulta
RFC 6068 define mailto: esquemas de URL con reglas de codificación específicas del componente. A diferencia de las URL normales, mailto: tiene reglas específicas por componente. Las partes de la dirección (prueba@ejemplo.com) permanecen sin codificar; @ y los dominios son estructurales. Los parámetros de consulta (asunto, cuerpo, cc, bcc) deben codificarse. RFC 6068 hace referencia a RFC 3986 para reglas, lo que exige codificación porcentual para espacios y caracteres especiales. Los símbolos dentro de los valores se convierten en %26 cuando aparecen como datos, no como delimitadores.
Comprender mailto: la estructura del esquema evita errores de codificación. El formulario es: mailto:dirección?parámetro1=valor1&parámetro2=valor2. Los signos de interrogación introducen secciones de consulta. Los símbolos que separan los parámetros permanecen sin codificar; solo los símbolos dentro de los valores se codifican como %26. Si los asuntos contienen "Tom & Jerry", codifique como Tom%20%26%20Jerry. Los símbolos entre sujeto y cuerpo permanecen sin codificar. Esta codificación anidada es propensa a errores.
Codificación del asunto y el cuerpo: espacios como %20, saltos de línea como %0D%0A y & como %26 valores internos
La codificación de sujetos y cuerpos requiere un manejo cuidadoso de espacios y caracteres especiales. Los espacios se convierten en %20 en los enlaces mailto:, no en signos más a diferencia de los formularios HTML. Esta diferencia crítica hace tropezar a los desarrolladores familiarizados con los formularios web. Los saltos de línea se codifican como %0D%0A (finales de línea CRLF en el correo electrónico). Los símbolos de unión se convierten en %26. Los signos de porcentaje se convierten en %25. Los temas suelen contener espacios, acentos y paréntesis. Los cuerpos contienen espacios, acentos, saltos de línea.
Las codificaciones comunes en los enlaces mailto: incluyen: espacios como %20, nuevas líneas como %0D%0A, ampersand como %26, porcentaje como %25, hash como %23, pregunta como %3F. Los acentos que no son de tipo ASCII primero se convierten a UTF-8 bytes y luego se codifican porcentualmente. "Superinforme" se convierte en %C3%9ber%20report. "¡Hola! Adiós" se convierte en Hola%21%0D%0AGoodbye. ¿Codificar sólo valores, no estructurales? y & personajes.
Ejemplo resuelto: crear un enlace con asunto, cuerpo de dos líneas y cc: el resultado codificado y cómo aparece en un cliente de correo
Ejemplo resuelto: creación de vínculos con el tema "Agenda de la reunión (septiembre)", cuerpo "Discutamos: Metas trimestrales", y cc "manager@example.com" demuestra la codificación completa. Los sujetos necesitan: espacios como %20, paréntesis como %28 y %29. Los cuerpos necesitan: "Discutemos:" prácticamente sin cambios (el espacio es %20), saltos de línea como %0D%0A, "Metas trimestrales" prácticamente sin cambios. El campo cc no requiere codificación.
El correo resultante: es: mailto:contact@example.com?subject=Meeting%20agenda%20%28Sept%29&body=Let%20us%20discuss%3A%0D%0AQuarterly%20goals&cc=manager@example.com. Las pruebas en navegadores revelan diferentes interpretaciones del cliente de correo. Gmail abre ventanas de redacción con el asunto correcto, el cuerpo de dos líneas y cc. Outlook muestra resultados similares. Apple Mail requiere permisos. Los clientes mayores fracasan por falta de apoyo corporal.
Por qué + está mal aquí: mailto: sigue el RFC 3986, no la codificación de formulario, por lo que + sigue siendo una ventaja
Por qué los signos más son incorrectos: mailto: sigue el RFC 3986, no la codificación de formularios, por lo que el signo más permanece literal: aclara las distinciones críticas. La codificación de formularios HTML utiliza plus para espacios en cadenas de consulta. RFC 3986 y RFC 6068 especifican %20 para espacios. Un mailto: con asunto="Reunión+Agenda" crea asuntos con signos más literales, no espacios. Este error ocurre al copiar la lógica de codificación de formularios a mailto: generación. Más significa más, no espacio.
Por qué esto es importante: los desarrolladores copian la lógica de envío del formulario GET a mailto: generación de enlaces rotos. Un asunto "Agenda de la reunión" se convierte en "Agenda de la reunión" en los formularios. En los enlaces mailto:, crea una "Reunión+Agenda" con ventajas literales. Los usuarios corrigen manualmente las líneas de asunto. Para probar los enlaces mailto: es necesario hacer clic en ellos o examinar los enlaces generados, no analizar las reglas del formulario.
Errores comunes: olvidarse de aplicar formato de escape HTML a los separadores & en href y codificar porcentualmente @ en la dirección
Mailto común: los errores de creación incluyen olvidar el ampers HTML y el escape en los atributos href. En HTML, los signos y en los atributos deben ser & para XHTML válido. href="mailto:address?subject=Test&body=Test" no es HTML válido; debería ser href="mailto:address?subject=Test&body=Test". Esto representa una codificación diferente de la codificación de URL. Los analizadores HTML interpretan & como & antes de que los navegadores procesen las URL.
Para detectar estos errores es necesario examinar el código fuente HTML y las consolas del navegador. Haga clic derecho y seleccione "Inspeccionar elemento" para ver los valores href reales. Copie y pegue los valores href en las barras de direcciones (con el prefijo mailto:) y verifique los clientes de correo. Algunos enlaces de correo electrónico funcionan en ciertos navegadores pero no en otros. Las pruebas automatizadas son difíciles porque mailto: involucra clientes externos, lo que hace que la verificación manual sea común.
Lo que esto no cubre: diferencias en el soporte del cliente de correo y múltiples destinatarios en profundidad
Lo que esto no cubre incluye diferencias en el soporte del cliente de correo y múltiples destinatarios. No todos los clientes admiten por igual los parámetros RFC 6068. El parámetro corporal tiene un amplio respaldo, pero algunos clientes mayores lo ignoran. Los parámetros cc y bcc tienen soporte variable. Varios destinatarios requieren direcciones de correo electrónico separadas por comas, codificando comas como %2C para direcciones complejas. Diferentes configuraciones regionales requieren la codificación UTF-8 adecuada para su visualización.
La evolución del cliente de correo afecta el comportamiento de mailto: en todas las plataformas. Los clientes de correo web modernos (Gmail, Outlook.com) cumplen mejor con RFC 6068 que los clientes de escritorio más antiguos. Los clientes móviles a veces tienen un análisis más estricto. Algunos admiten texto enriquecido, mientras que otros solo admiten texto sin formato. Los desarrolladores deberían realizar pruebas con clientes de correo que sus audiencias realmente utilizan. Las implementaciones reales varían a pesar de las especificaciones RFC 6068.
Conclusión: codifique cada valor, mantenga la estructura: cómo el modo de valor único del codificador y descodificador de URL le proporciona el asunto y el cuerpo codificados para pegar
Conclusión: codifique cada valor, mantenga la estructura: el modo de valor único del codificador y decodificador de URL produce temas y cuerpos codificados listos para pegar en enlaces. La herramienta acepta valores no codificados como "Agenda de la reunión (septiembre)" y produce "Reunión%20agenda%20%28Sept%29". Copie la salida directamente en mailto: atributos href. Para cuerpos de varias líneas, pegue versiones de texto sin formato con saltos de línea, obteniendo versiones codificadas en %0D%0A.
La mejor práctica ensambla mailto: enlaces a partir de partes codificadas en lugar de construcción manual. Al crear HTML dinámicamente en JavaScript o plantillas, codifique cada parámetro por separado antes de concatenar con separadores &. Para HTML estático, el codificador y decodificador de URL prueba de manera confiable la codificación antes de escribir a mano. Procesos de codificación de documentos en comentarios de código. Pruebe los enlaces mailto: haciendo clic en ellos con clientes de correo reales antes de la implementación.