ASP.NET WebService retorna caracteres sem sentido ao lançar exceções

Question

Eu tenho um serviço web (ASMX) e nele um método web que faz algum trabalho e lança uma exceção se a entrada não for 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 volta ao JavaScript do lado do cliente na página da Web, na função de retorno de chamada de erro, exibo meu erro:

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

Isso funciona muito bem e quando meu método Web retorna (uma string), sempre parece perfeito.No entanto, se uma das minhas mensagens de erro de uma exceção lançada contiver um caractere especial, ela será exibida incorretamente no navegador.Por exemplo, se a mensagem de erro contivesse o seguinte:

Essa entrada não é válida! (há um ASCII #146 ali)

Ele exibe isso:

Essa entrada não é válida!

Ou:

Você gosta de Hüsker Dü? (ASCII#252)

Torna-se:

Você gosta de Hüsker Dü?

O conteúdo das mensagens de erro vem de arquivos XML com codificação UTF-8:

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

E no que diz respeito à codificação de páginas, no meu Web.config, tenho:

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

Também tenho um módulo HTTP para definir 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;

Tentei desabilitar este módulo HTTP, mas o resultado é o mesmo.

Os valores retornados pelo serviço web (na variável l_errMsg) ficam bem no depurador VS.Apenas quando o script do cliente é controlado, ele é exibido incorretamente.Eu usei o Firebug para observar a resposta e caracteres especiais também estão distorcidos.Então acho muito estranho que as strings retornadas pelo meu método web pareçam boas, mesmo que contenham caracteres especiais.No entanto, quando lanço uma exceção do método web, os caracteres especiais em sua mensagem estão incorretos.Como posso consertar isso?

Answer 1

Tem certeza de que definir "fileEncoding" é o que você deseja, e não "responseEncoding"?Definir fileEncoding determina como o servidor web tentará ler arquivos físicos .asmx/.aspx do disco quando não puder determinar a codificação automaticamente.Portanto, definir isso como "utf-8" significa que você deve salvar todos os seus arquivos .asmx/.aspx em utf-8.Eu não acho que seja relevante.

A confusão que você está vendo é quando o texto codificado como utf-8 é analisado usando uma codificação de 8 bits (ou seja,um bytestream utf-8 é decodificado usando um decodificador de 8 bits, como, no seu caso, iso-8859-1/Windows-1252).Portanto, é possível que o HtmlEncode() que você está fazendo antes de lançar() a exceção esteja errado sobre a codificação de saída pretendida.Então, o que acontece se você não usar HtmlEncode() a mensagem de erro?

(Tecnicamente, "ASCII # 252" não está certo;ASCII possui 128 caracteres;o apóstrofo que você usa vem de uma codificação de 8 bits, como, no seu caso, iso-8859-1/Windows-1252.)

Tem certeza de que desativou o módulo HTTP corretamente?Esta linha parece estar causando o problema:

HttpContext.Current.Response.ContentEncoding = l_Enc;

... já que provavelmente está definindo a codificação de saída para uma codificação de 8 bits (o equivalente da página de código ANSI).

Para oferecer suporte ao maior número possível de culturas, você deve definir a codificação de resposta como utf-8. Este é o formato Unicode mais suportado em navegadores (ouso dizer que todos os navegadores modernos o suportam), e Unicode é a única alternativa às codificações locais.Dito isto, não entendo completamente qual módulo HTTP você está usando e por que precisa dele, então a situação pode ser mais complexa do que penso.