У меня есть веб-служба (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, чтобы посмотреть на ответ, и там тоже были искажены специальные символы. Поэтому мне кажется довольно странным, что строки, возвращаемые моим веб-методом, выглядят нормально, даже если в них есть специальные символы. Тем не менее, когда я генерирую исключение из веб-метода, специальные символы в его сообщении неверны. Как я могу это исправить?





Вы уверены, что установка «fileEncoding» - это то, что вы хотите, а не «responseEncoding»? Настройка fileEncoding определяет, как веб-сервер будет пытаться читать физические файлы .asmx / .aspx с диска, если он не может определить кодировку автоматически. Итак, установка этого параметра на «utf-8» означает, что вы должны сохранять все свои файлы .asmx / .aspx в utf-8. Я не думаю, что это актуально.
Искажение, которое вы видите, - это когда текст, закодированный как utf-8, анализируется с использованием 8-битной кодировки (т.е. байтовый поток utf-8 декодируется с использованием 8-битного декодера, например, в вашем случае iso-8859-1 / Windows-1252). Таким образом, возможно, что HtmlEncode (), который вы выполняете перед throw () с исключением, неверен в отношении предполагаемой выходной кодировки. Итак, что произойдет, если вы не 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-модуль вы используете и зачем он вам нужен, поэтому ситуация может быть более сложной, чем я думаю.