ASP.NET WebService Возвращает символы Тарабарщины При Выбрасывании Исключений

Question

У меня есть веб-сервис (ASMX) и в нем веб-метод, который выполняет некоторую работу и выдает исключение, если входные данные были недопустимыми.

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

Вернувшись в клиентский JavaScript на веб-странице, в функции обратного вызова error, я отображаю свою ошибку:

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

Это отлично работает, и когда мой веб-метод возвращает (строку), он всегда выглядит идеально.Однако, если одно из моих сообщений об ошибке из моего выброшенного исключения содержит специальный символ, оно неправильно отображается в браузере.Например, если сообщение об ошибке должно было содержать следующее:

Этот ввод недопустим! (это ASCII # 146 там)

Он отображает это:

Этот ввод неверен!

Или:

Вам нравится Хюскер Дю? (ASCII # 252)

Становится:

Тебе нравится Хаускер ДА?

Содержимое сообщений об ошибках поступает из XML-файлов в кодировке UTF-8:

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

И что касается кодировки страницы, то в моем Web.config у меня есть:

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

У меня также есть HTTP-модуль для установки параметров 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;

Я пробовал отключить этот HTTP-модуль, но результат тот же.

Значения, возвращаемые веб-службой (в переменной l_errMsg), выглядят нормально в отладчике VS.Просто, как только клиентский скрипт получает доступ, он отображается неправильно.Я использовал Firebug, чтобы просмотреть ответ, и специальные символы там тоже искажены.Поэтому я нахожу довольно странным, что строки, возвращаемые моим веб-методом, выглядят нормально, даже если в них есть специальные символы.Тем не менее, когда я создаю исключение из веб-метода, специальные символы в его сообщении неверны.Как я могу это исправить?

Answer 1

Вы уверены, что установка "fileEncoding" - это то, что вы хотите, а не "responseEncoding"?Настройка fileEncoding определяет, каким образом веб-сервер будет пытаться прочитать физические файлы .asmx / .aspx с диска, если он не сможет определить кодировку автоматически.Итак, установите значение "utf-8", что означает, что вы должны сохранить все ваши файлы .asmx /.aspx в формате utf-8.Хотя я не думаю, что это имеет отношение к делу.

Искажение, которое вы видите, происходит, когда текст, закодированный как utf-8, анализируется с использованием 8-битной кодировки (т. Е.байтовый поток utf-8 декодируется с использованием 8-разрядного декодера, такого как, в вашем случае, iso-8859-1/ Windows-1252).Таким образом, возможно, что HtmlEncode(), который вы выполняете перед тем, как выбросить () Исключение, неверен в отношении предполагаемой выходной кодировки.Итак, что произойдет, если вы не будете HtmlEncode() выдавать сообщение об ошибке?

(Технически, "ASCII # 252" - это не совсем правильно;ASCII содержит 128 символов;используемый вами апостроф взят из 8-разрядной кодировки, такой как, в вашем случае, iso-8859-1/ Windows-1252.)

Вы уверены, что правильно отключили этот HTTP-модуль?Эта строка выглядит так, как будто это может быть причиной проблемы:

HttpContext.Current.Response.ContentEncoding = l_Enc;

...поскольку это, скорее всего, установка выходной кодировки на 8-битную кодировку (эквивалент кодовой страницы ANSI).

Чтобы поддерживать как можно больше языков, вы должны установить кодировку ответа в utf-8. Это наиболее поддерживаемый формат Unicode в браузерах (осмелюсь предположить, что все современные браузеры поддерживают его), и Unicode является единственной альтернативой локальным кодировкам.Тем не менее, я не совсем понимаю, какой HTTP-модуль вы используете и зачем он вам нужен, поэтому ситуация может быть более сложной, чем я думаю.