ASP.NET WebService Restituisce una serie di caratteri Incomprensibili Caratteri Quando la generazione di Eccezioni

Question

Ho un web service (ASMX), e un metodo di web che fa un certo lavoro e genera un'eccezione se l'ingresso non era valido.

[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);
} 

Back in the client-side JavaScript nella pagina Web, su errore della funzione di callback, ho visualizzato il mio errore:

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

Questo funziona alla grande, e quando mio Web metodo restituisce una stringa), sembra sempre perfetto.Tuttavia, se uno dei miei messaggi di errore da un mio eccezione generata contiene un carattere speciale, è visualizzato correttamente nel browser.Per esempio, se il messaggio di errore che contiene le seguenti:

Il fatto che l'ingresso non è valido! (che è un ASCII #146 in là)

Visualizza questo:

Il fatto che l'ingresso isna€™t valido!

O:

Ti piace gli Hüsker Dü? (ASCII # 252)

Diventa:

Ti piace Hüsker Dü?

Il contenuto dei messaggi di errore deriva dal file XML con la codifica UTF-8:

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

E per quanto riguarda la codifica della pagina in questione, nel mio Web.config, ho:

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

Ho anche un Modulo HTTP impostare L10n parametri:

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;

Ho provato a disabilitare questo Modulo HTTP, ma il risultato è lo stesso.

I valori restituiti dal servizio web (in l_errMsg variabile) guardare bene nel VS debugger.E ' solo una volta che il client script ha un possesso di, visualizza in modo non corretto.Ho usato Firebug per guardare la risposta e i caratteri speciali sono alterati in là, troppo.Quindi trovo abbastanza strano che stringhe restituite da my web metodo di guardare bene, anche se in presenza di particolari caratteri.Eppure, quando mi passi un'eccezione al metodo web, caratteri speciali nel messaggio non sono corrette.Come posso risolvere questo problema?

Answer 1

Sei sicuro che l'impostazione "fileEncoding" è ciò che si vuole, e non "responseEncoding"?Impostazione del fileEncoding determina in che modo il web server prova a leggere fisico .asmx/.aspx file dal disco quando non è possibile determinare la codifica automaticamente.Così, le impostazioni di questo "utf-8" significa che si deve salvare tutti i tuoi .asmx/.aspx file in utf-8.Non penso sia rilevante, anche se.

L'alterazione si sta vedendo è quando un testo codificato in utf-8 è analizzato utilizzando una codifica a 8 bit (es.un utf-8 bytestream viene decodificato utilizzando un 8-bit decoder, ad esempio, nel tuo caso, iso-8859-1/Windows-1252).È quindi possibile che l'HtmlEncode() si sta facendo prima di buttare()ing Eccezione è sbagliato circa gli output di codifica.Quindi, cosa succede se non HtmlEncode() il messaggio di errore?

(Tecnicamente, "ASCII # 252" non è del tutto corretta;ASCII 128 caratteri;l'apostrofo si usa proviene da una codifica a 8 bit come, nel tuo caso, iso-8859-1/Windows-1252.)

Sei sicuro di non aver disabilitato il Modulo HTTP correttamente?Questa linea sembra che potrebbe essere la causa del problema:

HttpContext.Current.Response.ContentEncoding = l_Enc;

...dal momento che è più probabile che impostando l'uscita di una codifica a 8 bit di codifica (codice ANSI pagina equivalente).

Per sostenere, come molte culture, come è possibile, si dovrebbe impostare la risposta la codifica utf-8. Questo è il più supportato il formato Unicode nel browser (oserei dire tutti i browser moderni supportano), e Unicode è l'unica alternativa ai locali codifiche.Detto questo, non posso capire pienamente cosa HTTP Modulo che si sta utilizzando e perché ne hai bisogno, quindi, la situazione può essere più complesso di quanto penso.