В моем предпоследнем проекте был пользовательский XML, куда заносились данные о товарах и предоставлялись партнерам в качестве рекламных материалов. XML выводился как обычный текст.
Сам XML был составлен по всем «законам жанра» – определение <?xml?> в начале, указание кодировки, главного тега. Все теги были закрыты, ошибок не было.
Браузеры, как Вы знаете, любят отображать XML по-своему. Оформлять его специальным образом. Этим занимается ФайрФокс и ИЕ (для Оперы нужен плагин). Чтобы было понятно о чем я, вот пример.
Но мой XML почему-то так не отображался. Он отображался просто текстом, причем теги «пропадали» (оно и понятно, браузер не знает таких тегов, но не показывает их). Заказчик же, заметив это, решил, что у меня неправильный XML (понятно, что на сам файл это никак не сказывается).
В чем было дело? Оказалось, что есть две причины на такое «неправильное» отображение.
1) Нужно передать заголовок Content-Type: text/xml; charset=utf-8. Отличается от «обычного» он типом контента (обычно text/html). В PHP заголовок передается так: header («Content-Type: text/xml; charset=utf-8″); (до вывода чего-либо, конечно).(к проблеме не относится)
2) По непонятной мне причине XML не может содержать наоборов символов а-ля , но при этом может содержать аналогичные замены для кавычек, например. Также XML не может содержать HTML-теги внутри XML-тегов. То есть может-то может, но тогда браузер будет ругаться на него.
Я написал небольшую функцию, через которую нужно пропустить текст до вывода в XML (скажем, описание товара). Она вырезает теги и некоторые недопустимые комбинации символов.
function xml_check($c){
$c = strip_tags ($c);
$c = str_replace («–», «», $c);
$c = str_replace (« », «», $c);
$c = str_replace («“», «», $c);
return $c;
}
Если посмотреть внимательнее, данные символы «портят» только заголовки, а в основном тексте вполне допустимы. Для того, чтобы их не было в заголовках, имеется в файле rss.format.inc.php cтрока:
return htmlspecialchars(html_entity_decode($resource[’pagetitle’], ENT_QUOTES));
однако проблема в том, что при кодировке UTF8 html_entity_decode работает неверно и подставляет непечатаемые символы. Если дописать:
return htmlspecialchars(html_entity_decode($resource[’pagetitle’], ENT_QUOTES, ’UTF-8’));
Все будет работать правильно.
Конечно, лучше было бы проверять, какая кодировка установлена, и подставлять разные вызовы функции в различных случаях. Также надо внести аналогичные исправления в других местах, например, при формировании имени автора. А вообще в заголовках как-то не слишком уместны…
Очень плохое решение, так как для начала непонятно, зачем нужен preg_replace, когда достаточно str_replace, но дело даже не в этом, а в том, что править так радикально код Ditto плохо, ведь неразрывные пробелы в каких-то случаях могут понадобиться.
Мое решение же состоит в том, чтобы в ditto.class.inc.php на строке 344 заменить