2015-05-14 2 views
0
answers2 = HttpUtility.UrlDecode(Model.FindOne<UserResult>(ur => ur.UserID == user.UserID 
      && ur.ModuleID == 2 
      && ur.TopicID == 9 
      && ur.ActivityID == 2 
      && ur.QuestionID == 2).Results, Encoding.ASCII).Split('|'); 

Поле результата содержит немецкие символы, закодированные как ASCII в базе данных SQL. Я использую массовую отправку SMS-сообщений, которая требует, чтобы специальные символы отправлялись как коды ASCII.HttpUtility.UrlDecode кодировка от UTF-8 до ASCII

У этого нет проблем с декодированием «% 7C» и «% 20», поскольку коды UTF-8 и ASCII для него одинаковы. Если я отправлю символ в UTF-8 (% c3% a4), он отлично работает, но если я верну его обратно в ASCII (% E4), то SMS отправит мне знак вопроса вместо символа.

Схема декодирования ASCII, которую я указал, кажется, не работает, я не уверен, что я делаю неправильно.

+1

Вы должны разработать. Поиск 'UserResult' не имеет отношения к' HttpUtility.UrlDecode' или вашей проблеме с кодировкой. Приведите правильный пример. Как вы сохраняете этот URL-адрес в своей базе данных? Какой тип базы данных? –

ответ

1

%E4 не является ASCII. Если вы хотите использовать такие значения, как это, вы должны будете использовать фактическую кодировку, который вы хотите использовать, например .:

Encoding.GetEncoding("iso-8859-2").GetString(new byte[] { 0xE4 }) 

производит ä, а

Encoding.ASCII.GetString(new byte[] { 0xE4 }) 

производит ?.

ASCII описывает только первые 128 байт-значений. Остальные являются специфическими кодировками, которые удлиняют ASCII. Поэтому в любое время, когда вы пытаетесь декодировать ASCII более чем 128, вы получите ?.

Очевидно, что это также работает в обратном направлении - любой символ, который не входит в ASCII (и ваш ä конечно не) будет закодирован как 63 - также известный как ? :)

Смежные вопросы