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

Question

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

MailMessage message = new MailMessage() 
{ 
    From = new MailAddress("someone@somewhere.com", "Service"), 
    BodyEncoding = Encoding.UTF8, 
    Body = body, 
    IsBodyHtml = true, 
    ReplyTo = new MailAddress("do.not.reply@somewhere.com"), 
    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 ocurre todo el tiempo.

¿Qué estoy haciendo mal?

Answer 1

Cuando su sujeto contiene caracteres fuera del rango ASCII, entonces 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:

• citado imprimible (sujeto comienza con "= UTF-8 Q?")
• base 64 (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 su pregunta: No está haciendo nada incorrecto. 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.

Answer 2

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 tiene

Answer 3

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

Answer 4

me encontré con este post cuando estaba depurando un problema idéntico, y con base en mis investigaciones adicionales que puede proporcionar una explicación alternativa a Andreas:

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

Si utiliza un valor tema como éste (la letra "c" repetida 256 veces), se muestra bien en Outlook:

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

Del mismo modo, si se utiliza un tema como éste (la letra "c "repetida 178 veces, con un carácter Unicode de no separación de espacio en anexo), también muestra como se esperaba en Outlook:

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

sin embargo, aparece el siguiente tema como "= UTF-8 B" basura -prepended?? 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 mostrarla ... 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

Esto es un error en Outlook y no en 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:".

Al contrario de lo 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 no 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 antes, 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 imprimirlos para la consola por otra parte, si se cambia el valor de la variable de cadena en el depurador de Visual Studio, en silencio los reemplaza con espacios regulares)

Answer 5

he encontrado una solución rápida en los foros de Microsoft:.. http://social.msdn.microsoft.com/Forums/en-US/netfxnetcom/thread/67414337-19a6-4128-b1a0-212404cc2cb1/

mediante el uso de la clase proporcionada en este enlace: http://social.msdn.microsoft.com/Forums/en-US/dotnetframeworkde/thread/b6c764f7-4697-4394-b45f-128a24306d55