ASP.NET WebService возвращает символы Gibberish при создании исключений

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 на веб-странице, в функции обратного вызова я отображаю свою ошибку:

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

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

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

Это отображает это:

Этот ввод недействителен!

Или:

Вам нравится Hüsker Dü? (ASCII # 252)

Становится:

Нравится ли вам Hüsker Dü?

Содержимое сообщений об ошибках поступает из файлов 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 (), который вы делаете перед throw () в Exception, неверен в отношении предполагаемой выходной кодировки. Так что произойдет, если вы не 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 вы используете и зачем он вам нужен, поэтому ситуация может быть более сложной, чем я думаю.