ASP.NET WebService Gibt Charaktere Gibberish Wenn Ausnahmen Werfen

Question

Ich habe einen Web-Service (ASMX) und darin, eine Web-Methode, die eine Arbeit tut und wirft eine Ausnahme, wenn die Eingabe nicht gültig war.

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

Zurück in der Client-Seite JavaScript auf der Webseite, auf der Fehler-Callback-Funktion, zeige ich meine Fehler:

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

Dies funktioniert gut, und wenn mein Web-Methode zurückgibt (ein String), es sieht immer perfekt. Wenn jedoch eine meiner Fehlermeldungen von einem meiner geworfenen Ausnahme ein Sonderzeichen enthält, ist es nicht richtig im Browser angezeigt. Zum Beispiel ist, wenn die Fehlermeldung Folgendes enthalten:

Das Eingabe ist nicht gültig! (das ist ein ASCII # 146 dort)

Es zeigt dies:

Das Eingangs isnâ € ™ t gültig!

Oder:

Mögen Sie Hüsker Dü? (ASCII # 252)

Wird:

Mögen Sie Hüsker Dü?

Der Inhalt der Fehlermeldungen kommt von XML-Dateien mit UTF-8-Codierung:

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

Und was Seite Codierung betrifft, in meinem Web.config, ich habe:

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

Ich habe auch einen HTTP-Modul L10n Parameter einstellen:

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;

Ich habe versucht, das Deaktivieren dieses HTTP-Modul, aber das Ergebnis ist das gleiche.

Die Werte von dem Web-Service (in der l_errMsg Variable) zurück Blick in den VS-Debugger in Ordnung. Es ist nur, wenn der Client-Skript halten hat, zeigt es falsch. Ich habe Firebug verwendet bei der Reaktion und Sonderzeichen zu suchen sind dort verstümmelt, auch. So finde ich es ziemlich merkwürdig, dass Strings durch meine Web-Methode gut aussehen zurückgegeben, auch wenn es in ihnen Sonderzeichen ist. Doch wenn ich eine Ausnahme von der Web-Methode werfen, Sonderzeichen in seiner Botschaft sind nicht korrekt. Wie kann ich dieses Problem beheben?

Answer 1

Setzen Sie sicher, dass die „Fileencoding“ ist, was Sie wollen, und nicht „responseen“? die Fileencoding Einstellung legt fest, wie der Web-Server versuchen, physische .asmx / ASPX-Dateien von der Festplatte zu lesen, wenn es die Codierung nicht automatisch bestimmen kann. Also, Einstellungen dies auf „utf-8“ bedeutet, dass Sie alle speichern müssen Ihre .asmx / ASPX-Dateien in utf-8. Ich glaube nicht relevant ist though.

Die Mangeln Sie sehen, ist, wenn der Text codiert als utf-8 analysiert wird eine 8-Bit-Codierung (dh ein utf-8 Bytestrom decodiert wird ein 8-Bit-Decoder verwendet wird, wie in Ihrem Fall, Iso- 8859-1 / Windows 1252). So ist es möglich, dass der Htmlencode () Sie vor throw tun () ing die Ausnahme über die beabsichtigte Ausgabecodierung falsch ist. Also, was passiert, wenn Sie nicht tun Htmlencode (), um die Fehlermeldung?

(Technisch gesehen "ASCII # 252" ist nicht ganz richtig, ASCII hat 128 Zeichen, die Apostroph Sie verwenden kommt aus einer 8-Bit-Codierung, wie in Ihrem Fall, iso-8859-1 / Windows 1252 ).

Sind Sie sicher, Sie haben deaktiviert, dass HTTP-Modul korrekt? Diese Zeile sieht aus wie es das Problem verursachen könnte:

HttpContext.Current.Response.ContentEncoding = l_Enc;

... da es höchstwahrscheinlich die Ausgabecodierung in eine 8-Bit-Codierung (die ANSI-Codepage-äquivalent) zu setzen.

Um so viele Kulturen wie möglich zu unterstützen, sollten Sie die Antwort Codierung auf UTF-8 gesetzt. Dies ist das unterstützt Unicode-Format in Browsern (I daresay alle modernen Browser unterstützt) und Unicode ist die einzige Alternative zu lokalen Kodierungen. Das heißt, ich verstehe nicht ganz, was Sie HTTP-Modul verwenden und warum Sie es brauchen, so ist die Situation komplexer sein kann als ich denke.