ASP.NET WebService renvoie des caractères de type charabia 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);
} 

De retour dans JavaScript côté client sur la page Web, sur la fonction de rappel d'erreur, j'affiche mon erreur:

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

Cela fonctionne très bien et lorsque ma méthode Web renvoie (une chaîne), elle a toujours l’air parfaite. Toutefois, si l'un de mes messages d'erreur provenant d'une exception levée contient un caractère spécial, celui-ci 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! (il s'agit d'un code ASCII n ° 146 à cet endroit)

Il affiche ceci:

Cette entrée n'est pas valide!

Ou:

Aimez-vous Hüsker Dü? (ASCII n ° 252)

devient:

Aimez-vous Hüsker Dü?

Le contenu des messages d'erreur provient de fichiers XML codés en UTF-8:

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

En ce qui concerne le codage de page, dans mon Web.config, j'ai:

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

J'ai également 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é de désactiver ce module HTTP mais le résultat est identique.

Les valeurs renvoyées par le service Web (dans la variable l_errMsg) sont correctes dans le débogueur de VS. Ce n'est qu'une fois que le script client est en attente, il ne s'affiche pas correctement. J'ai utilisé Firebug pour examiner la réponse et les caractères spéciaux y sont également mutilés. Je trouve donc assez étrange que les chaînes renvoyées par ma méthode Web aient l’air parfait, même si elles contiennent des caractères spéciaux. Pourtant, lorsque je lance une exception à la méthode Web, les caractères spéciaux de son message sont incorrects. Comment puis-je résoudre ce problème?

Answer 1

Êtes-vous sûr de définir le " fileEncoding " est ce que vous voulez, et non pas "responseEncoding"? La définition de fileEncoding détermine la manière dont le serveur Web essaiera de lire les fichiers physiques .asmx / .aspx à partir du disque lorsqu'il ne pourra pas déterminer le codage automatiquement. Par conséquent, définissez cette option sur " utf-8 " signifie que vous devez sauvegarder tous vos fichiers .asmx / .aspx dans utf-8. Je ne pense pas que ce soit pertinent cependant.

Le problème que vous constatez se produit lorsque le texte encodé en tant que utf-8 est analysé à l'aide d'un encodage à 8 bits (c'est-à-dire qu'un flux de flux utf-8 est décodé à l'aide d'un décodeur à 8 bits, tel que, dans votre cas, l'iso). 8859-1 / Windows-1252). Il est donc possible que le HtmlEncode () que vous faites avant de lancer l'exception (Exception) soit erroné à propos du codage de sortie prévu. Alors que se passe-t-il si le message d'erreur n'est pas HtmlEncode ()?

(Techniquement, "ASCII # 252" n'est pas tout à fait correct; l'ASCII comporte 128 caractères; l'apostrophe que vous utilisez provient d'un codage sur 8 bits tel que, dans votre cas, iso-8859-1 / Windows- 1252.)

Êtes-vous sûr d'avoir bien désactivé ce module HTTP? Cette ligne semble être à l'origine du problème:

HttpContext.Current.Response.ContentEncoding = l_Enc;

... puisqu'il est très probable que le codage de sortie soit défini sur un codage sur 8 bits (l'équivalent de la page de code ANSI).

Pour prendre en charge autant de cultures que possible, vous devez définir le codage de la réponse sur utf-8. Il s'agit du format Unicode le plus pris en charge dans les navigateurs (je suis sûr que tous les navigateurs modernes le prennent en charge), et Unicode. est la seule alternative aux encodages locaux. Cela dit, je ne comprends pas tout à fait le module HTTP que vous utilisez et pourquoi vous en avez besoin. La situation risque donc d'être plus complexe que je ne le pense.