Проблемы с кодировкой HTML - символ "Â" отображается вместо " "

У меня есть устаревшее приложение, которое просто начинает плохо себя вести, по какой-то причине я не уверен. Он генерирует кучу HTML, который превращается в отчеты PDF в ActivePDF.

Процесс работает следующим образом:

  • Вытяните HTML-шаблон из БД с помощью токенов в нем для замены (например, "~ CompanyName ~", "~ CustomerName" и т.д.).
  • Заменить токены реальными данными
  • Уточните HTML с помощью простой функции регулярного выражения, которая форматирует значения атрибутов HTML-тегов (обеспечивает кавычки и т.д., поскольку механизм рендеринга ActivePDF ненавидит все, кроме одиночных кавычек вокруг значений атрибутов)
  • Отправляйте HTML в веб-службу, которая создает PDF.

Где-то в этом беспорядке неразрывные пробелы из HTML-шаблона (  s) кодируются как ISO-8859-1, так что они отображаются неправильно как символ "Â" при просмотре документа в браузера (FireFox). ActivePDF запускает эти символы без UTF8.

Мой вопрос: поскольку я не знаю, откуда возникла эта проблема, и у вас нет времени для ее изучения, есть ли простой способ перекодировать или найти и заменить плохие символы? Я попытался отправить его через эту небольшую функцию, которую я сбросил вместе, но она превращает все это в gobbledegook ничего не меняет.

Private Shared Function ConvertToUTF8(ByVal html As String) As String
    Dim isoEncoding As Encoding = Encoding.GetEncoding("iso-8859-1")
    Dim source As Byte() = isoEncoding.GetBytes(html)
    Return Encoding.UTF8.GetString(Encoding.Convert(isoEncoding, Encoding.UTF8, source))
End Function

Любые идеи?

EDIT:

Я сейчас с этим справляюсь, хотя вряд ли это похоже на хорошее решение:

Private Shared Function ReplaceNonASCIIChars(ByVal html As String) As String
    Return Regex.Replace(html, "[^\u0000-\u007F]", " ")
End Function

Ответы

Ответ 1

Где-то в этом беспорядке неразрывные пробелы из HTML-шаблона (  s) кодируются как ISO-8859-1, так что они отображаются неправильно как символ "<" /

Это будет кодирование для UTF-8, а не ISO-8859-1. Неразрушающим символом пробела является байт 0xA0 в ISO-8859-1; при кодировании в UTF-8 это будет 0xC2,0xA0, который, если вы (неправильно) смотрите его как ISO-8859-1, выйдет как " ". Это включает в себя конечный nbsp, который вы можете не заметить; если этого байта нет, то что-то еще измотало ваш документ, и нам нужно посмотреть дальше, чтобы узнать, что.

Что такое регулярное выражение, как работает шаблон? Казалось бы, какой-то подходящий парсер HTML, который был вовлечен где-то, если ваши строки &nbsp; (правильно) превращены в символы U + 00A0, НЕВОЗМОЖНЫЕ ПРОСТРАНСТВА. Если это так, вы можете просто обработать свой шаблон изначально в DOM и попросить его сериализоваться с использованием кодировки ASCII, чтобы сохранить символы, отличные от ASCII, в качестве ссылок на символы. Это также помешает вам выполнять пост-обработку регулярных выражений на самом HTML, что всегда является очень хитроумным бизнесом.

Хорошо, в любом случае, теперь вы можете добавить одно из следующего к вашему документу <head> и посмотреть, правильно ли оно выглядит в браузере:

  • для HTML4: <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
  • для HTML5: <meta charset="utf-8">

Если вы это сделали, любая оставшаяся проблема - это ошибка ActivePDF.

Ответ 2

Если у кого-то была такая же проблема, как у меня, и кодировка была уже правильной, просто выполните это:

  • Скопируйте весь код внутри .html файла.
  • Откройте блокнот (или любой основной текстовый редактор) и вставьте код.
  • Перейти "Файл → Сохранить как"
  • Введите имя файла "example.html" (выберите "Сохранить как тип: Все файлы (.)" )
  • Выберите кодировку как UTF-8
  • Нажмите "Сохранить", и теперь вы можете удалить старый .html файл, и кодировка должна быть исправлена.

Ответ 3

Проблема: Даже я столкнулся с проблемой, когда мы отправляли '£' с некоторой строкой в ​​запросе POST в CRM-систему, но когда мы делали вызов GET из CRM, он возвращал 'Â £ ' с некоторым содержимым строки. Итак, мы проанализировали, что '£' превращался в 'Â £'.

Анализ: Сбой, который мы обнаружили после проведения исследования, заключается в том, что в вызове POST мы установили HttpWebRequest ContentType как "text/xml" , тогда как в GET Call было "text/xml; charset: utf- 8" .

Решение: Итак, в качестве части решения мы включили кодировку: utf-8 в запрос POST, и она работает.

Ответ 4

В моем случае я получал латинский крестик вместо nbsp, даже если страница была правильно закодирована в UTF-8. Ничто из этого не помогло в решении проблемы, и я пробовал все.

В конце концов изменился шрифт для IE (с конкретным браузером css), я использовал Helvetica-Nue в качестве изменения шрифта тела, чтобы Arial разрешил проблему.

Ответ 5

Ну, я тоже получил эту проблему на моих маленьких сайтах, и все, что мне нужно сделать, это настроить фетчер контента для HTML-запросов. перед этим больше я удаляю их больше, чем получил, поэтому просто измените функцию html fit или функцию синтаксического анализа страницы, и она сработала. Его главным образом из-за редакторов HTML в большинстве CMS. как они хранят синтаксический анализ данных, вызванных этой проблемой (в моем случае). Пусть это тоже поможет в вашем случае

Ответ 6

У меня была такая же проблема. По-видимому, это просто потому, что PHP не распознает utf-8.

Сначала я рвал волосы, когда знак "£" продолжал появляться как "Â", несмотря на то, что он выглядел нормально в DreamWeaver. В конце концов я вспомнил, что у меня были проблемы со ссылками относительно индексного файла, когда страницы, если смотреть напрямую, будут работать со слайд-шоу, но не при использовании с include (но это рядом с точкой. В любом случае я задавался вопросом, может ли это быть аналогичная проблема, поэтому вместо того, чтобы помещать на страницу, с которой у меня возникли проблемы, я просто поместил ее в файл index.php - исправленную проблему.

Ответ 7

Причиной этого является то, что PHP не распознает utf-8.

Здесь вы можете проверить его для всех специальных символов в HTML

http://www.degraeve.com/reference/specialcharacters.php