c# .net encoding utf-8 system.net.mail

c# - System.Net.Mail y=? Utf-8? B? XXXXX... Encabezados



encoding (5)

Estoy tratando de usar el siguiente código para enviar mensajes a través de System.Net.Mail y algunas veces obtengo temas como ''=? Utf-8? B? W3AxM25dIEZpbGV ...'' (recortado). Este es el código que se llama:

MailMessage message = new MailMessage() { From = new MailAddress("[email protected]", "Service"), BodyEncoding = Encoding.UTF8, Body = body, IsBodyHtml = true, ReplyTo = new MailAddress("[email protected]"), SubjectEncoding = Encoding.UTF8 }; foreach (string emailAddress in addresses) { message.To.Add(new MailAddress(emailAddress.Trim(), "Person")); } message.Subject = subject;

Me gustaría enfatizar que esto no sucede todo el tiempo.

¿Qué estoy haciendo mal?


Aunque no estoy seguro, tal vez este artículo sobre MIME en wikipedia pueda ayudar a obtener más información de fondo.


Cuando su tema contiene caracteres fuera del rango ASCII, el software de correo debe codificarlos (el correo RFC2822 no permite caracteres que no sean ASCII en los encabezados). Hay dos maneras de hacer esto:

  • Quoted Printable (el tema comienza con "=? Utf-8? Q")
  • Base64 (el sujeto comienza con "=? Utf-8? B")

Parece que el marco ha calculado que la codificación Base64 es más eficiente (= más corta) que la codificación imprimible entre comillas. Esto tiene sentido cuando su tema contiene muchos caracteres fuera del rango ASCII.

Para responder a tu pregunta: no estás haciendo nada mal. Así es como se supone que se ve el correo de internet con caracteres que no son ASCII. Por supuesto, el software que lee dicho correo debe detectar y decodificar tales campos de asunto.


La respuesta podría estar en el resto del tema recortado: la sección que proporcionó se decodifica como "[p13n] Archivo", pero si tiene caracteres no ASCII allí, entonces esperaría que codifique como lo ha hecho


Me encontré con esta publicación cuando estaba depurando un problema idéntico y, en base a mis investigaciones posteriores, puedo proporcionar una explicación alternativa a la de Andreas:

El problema puede ser que su software de cliente de correo electrónico (Outlook 2003, en mi caso) está descodificando incorrectamente la línea de asunto. En otras palabras, es un error en Outlook, no en .NET o su programa.

Si utiliza un valor de asunto como este (la letra "c" se repite 256 veces), se muestra bien en Outlook:

subject = New String("c"c, 256)

Del mismo modo, si usa un tema como este (la letra "c" se repite 178 veces, con un espacio de espacio no disruptivo Unicode adjunto), también se muestra como se esperaba en Outlook:

subject = New String("c"c, 178) + System.Text.Encoding.UTF8.GetChars(New Byte() {194, 160})

Sin embargo, el siguiente tema se muestra como "=? Utf-8? B" -prepended basura en Outlook:

subject = New String("c"c, 179) + System.Text.Encoding.UTF8.GetChars(New Byte() {194, 160})

La diferencia es que esta tercera línea de asunto es de 256 bytes cuando está codificada en UTF-8. Supongo que Outlook debe truncar la línea de asunto a 255 caracteres antes de mostrarlo ... lo cual estaría bien, excepto que está haciendo esto al truncar la cadena codificada a 255 bytes, lo que corta el terminador de codificación ("? =") , haciéndolo indecodificable

Este es un error en Outlook y no su proveedor de correo o .NET; puede ver la línea de asunto codificada UTF-8 completa y no truncada en Outlook haciendo clic derecho en el mensaje en su lista de mensajes y seleccionando "Opciones ..." en el menú contextual, luego desplácese hacia abajo en el cuadro "Encabezados de Internet" hasta ves la línea que comienza con "Asunto:".

Contrariamente a la situación que sugiere Andreas, el problema se manifiesta no solo cuando hay muchos caracteres que no son ASCII, sino cuando hay uno o más caracteres que no son ASCII y la línea de asunto es larga. Una solución podría ser utilizar una línea de asunto más corta o quitar todos los caracteres que no sean ASCII en el tema.

(Este error me resultó particularmente difícil de rastrear porque, como se indicó anteriormente, los datos del problema no incluían caracteres no ASCII obvios, solo unos pocos espacios sin interrupción. Estos se muestran igual que los espacios ASCII normales cuando los imprime en Además, si cambia el valor de la variable de cadena en el depurador de Visual Studio, los reemplaza silenciosamente con espacios regulares.