ASP.NET WebService renvoie des caractères gâchés lors du lancement d'exceptions

Question

J'ai un service Web (ASMX) et une méthode Web qui fonctionne et génère une exception si l'entrée n'est pas valide.

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

Retour en JavaScript côté client sur la page Web, la fonction de rappel d'erreur, j'afficher mon erreur:

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

Cela fonctionne très bien et quand mes déclarations de méthode Web (une chaîne) , ça a toujours l'air parfait. Toutefois, si l'un de mes messages d'erreur provenant d'une exception renvoyée contient un caractère spécial, il est affiché de manière incorrecte dans le navigateur. Par exemple, si le message d'erreur devait contenir les éléments suivants:

Cette entrée n'est pas valide! (c'est un ASCII # 146 là-dedans)

Il affiche ceci:

Cette entrée nâ € ™ t valide!

Ou:

Vous aimez Hüsker Dü? (ASCII # 252)

Devient:

Vous aimez Hüsker Dü?

Le contenu des messages d'erreur provient de fichiers XML avec encodage UTF-8:

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

Et aussi loin que la page de codage concerne, dans mon web.config, j'ai:

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

J'ai aussi un module HTTP pour définir les paramètres 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; 

J'ai essayé disablin g ce module HTTP mais le résultat est le même.

Les valeurs renvoyées par le service Web (dans la variable l_errMsg) sont correctes dans le débogueur VS. C'est juste une fois que le script client est en attente, il s'affiche incorrectement. J'ai utilisé Firebug pour regarder la réponse et les personnages spéciaux sont également mutilés. Donc je trouve assez étrange que les chaînes renvoyées par ma méthode web semblent bien, même s'il y a des caractères spéciaux dans celles-ci. Pourtant, quand je lance une exception de la méthode web, les caractères spéciaux dans son message sont incorrects. Comment puis-je réparer cela?

Answer 1

Etes-vous sûr que la définition de "fileEncoding" est ce que vous voulez, et non "responseEncoding"? La définition du paramètre fileEncoding détermine comment le serveur Web va essayer de lire les fichiers .asmx/.aspx physiques à partir du disque lorsqu'il ne peut pas déterminer automatiquement l'encodage. Donc, paramétrez ceci sur "utf-8" signifie que vous devez sauvegarder tous vos fichiers .asmx/.aspx dans utf-8. Je ne pense pas que cela soit pertinent. Le mangling que vous voyez est quand le texte codé comme utf-8 est analysé en utilisant un encodage de 8 bits (c.-à-d. Qu'un octets de 8 octets est décodé en utilisant un décodeur de 8 bits, comme, dans votre cas, iso -8859-1/Windows-1252). Il est donc possible que HtmlEncode() que vous faites avant de lancer() l'exception soit erroné sur le codage de sortie prévu.Alors que se passe-t-il si vous ne faites pas HtmlEncode() le message d'erreur? (Techniquement, "ASCII # 252" n'est pas tout à fait exact, ASCII a 128 caractères, l'apostrophe que vous utilisez provient d'un encodage de 8 bits comme, dans votre cas, iso-8859-1/Windows- 1252.)

Etes-vous sûr d'avoir désactivé ce module HTTP correctement? Cette ligne semble que cela pourrait être la cause du problème:

HttpContext.Current.Response.ContentEncoding = l_Enc;

... car il est plus probable que le réglage de l'encodage de sortie à un codage 8 bits (la page de code ANSI équivalent).

Pour prendre en charge autant de cultures que possible, vous devez définir le codage de réponse sur utf-8. C'est le format Unicode le plus pris en charge dans les navigateurs (je suppose que tous les navigateurs modernes le supportent), et Unicode est la seule alternative aux encodages locaux. Cela dit, je ne comprends pas parfaitement quel module HTTP vous utilisez et pourquoi vous en avez besoin, donc la situation peut être plus complexe que je ne le pense.