El servicio web ASP.NET devuelve caracteres galimatías al generar excepciones

Question

Tengo un servicio web (ASMX) y en él, un método web que funciona y arroja una excepción si la entrada no era válida.

[ScriptMethod]
[WebMethod]
public string MyWebMethod(string input)
{
    string l_returnVal;

    if (!ValidInput(input))
    {
        string l_errMsg = System.Web.HttpUtility.HtmlEncode(GetErrorMessage());
        throw new Exception(l_errMsg);
    }

    // some work gets done...

    return System.Web.HttpUtility.HtmlEncode(l_returnVal);
} 

De vuelta en JavaScript del lado del cliente en la página web, en la función de devolución de llamada de error, muestro mi error:

function GetInputErrorCallback(error)
{
    $get('input_error_msg_div').innerHTML = error.get_message();
}

Esto funciona muy bien y cuando mi método web devuelve (una cadena), siempre se ve perfecto.Sin embargo, si uno de mis mensajes de error de una excepción lanzada contiene un carácter especial, se muestra incorrectamente en el navegador.Por ejemplo, si el mensaje de error contuviera lo siguiente:

¡Esa entrada no es válida! (Ese es un ASCII #146 allí)

Muestra esto:

¡Esa entrada no es válida!

O:

¿Te gusta Hüsker Dü? (ASCII#252)

Se convierte en:

¿Te gusta Hüsker Dü?

El contenido de los mensajes de error proviene de archivos XML con codificación UTF-8:

<?xml version="1.0" encoding="UTF-8"?>
<ErrorMessages>
   <Message id="invalid_input">Your input isn’t valid!</Message>
   .
   .
   .
</ErrorMessages>

Y en lo que respecta a la codificación de páginas, en mi Web.config tengo:

<globalization enableClientBasedCulture="true" fileEncoding="utf-8" />

También tengo un módulo HTTP para configurar los parámetros L10n:

Thread.CurrentThread.CurrentUICulture = m_selectedCulture;
Encoding l_Enc = Encoding.GetEncoding(m_selectedCulture.TextInfo.ANSICodePage);
HttpContext.Current.Response.ContentEncoding = l_Enc;
HttpContext.Current.Request.ContentEncoding = l_Enc;

Intenté deshabilitar este módulo HTTP pero el resultado es el mismo.

Los valores devueltos por el servicio web (en la variable l_errMsg) se ven bien en el depurador VS.Es solo que una vez que el script del cliente se controla, se muestra incorrectamente.He usado Firebug para ver la respuesta y los caracteres especiales también están destrozados allí.Por eso me parece bastante extraño que las cadenas devueltas por mi método web se vean bien, incluso si contienen caracteres especiales.Sin embargo, cuando lanzo una excepción del método web, los caracteres especiales en su mensaje son incorrectos.¿Cómo puedo arreglar esto?

Answer 1

¿Está seguro de que lo que desea es configurar "fileEncoding" y no "responseEncoding"?Configurar fileEncoding determina cómo el servidor web intentará leer archivos físicos .asmx/.aspx desde el disco cuando no pueda determinar la codificación automáticamente.Entonces, configurar esto en "utf-8" significa que debe guardar todos sus archivos .asmx/.aspx en utf-8.Aunque no creo que sea relevante.

La alteración que estás viendo se produce cuando el texto codificado como utf-8 se analiza utilizando una codificación de 8 bits (es decir,un flujo de bytes utf-8 se decodifica utilizando un decodificador de 8 bits, como, en su caso, iso-8859-1/Windows-1252).Por lo tanto, es posible que el HtmlEncode() que está haciendo antes de lanzar() la excepción sea incorrecto en cuanto a la codificación de salida prevista.Entonces, ¿qué sucede si no haces HtmlEncode() el mensaje de error?

(Técnicamente, "ASCII # 252" no es del todo correcto;ASCII tiene 128 caracteres;el apóstrofo que utiliza proviene de una codificación de 8 bits como, en su caso, iso-8859-1/Windows-1252).

¿Está seguro de haber desactivado ese módulo HTTP correctamente?Parece que esta línea podría estar causando el problema:

HttpContext.Current.Response.ContentEncoding = l_Enc;

... ya que lo más probable es que esté configurando la codificación de salida en una codificación de 8 bits (el equivalente de la página de códigos ANSI).

Para admitir tantas culturas como sea posible, debe configurar la codificación de respuesta en utf-8. Este es el formato Unicode más compatible con los navegadores (me atrevería a decir que todos los navegadores modernos lo admiten), y Unicode es la única alternativa a las codificaciones locales.Dicho esto, no entiendo completamente qué módulo HTTP estás utilizando y por qué lo necesitas, por lo que la situación puede ser más compleja de lo que creo.