Как заставить XSLT работать в Chrome?

У меня есть XML - документ здесь , который подается с соответствующим файлом XSL . Преобразование остается выполняться на стороне клиента, без JavaScript.

Это отлично работает в IE (ужас шока), но в Google Chrome просто отображает текстовые узлы документа.

Я знаю, что в Chrome можно использовать XSL на стороне клиента, поскольку я видел примеры этого, но я еще не смог повторить этот успех сам.

Что я делаю не так?

Другой ответ Эрика ниже неверен. Упомянутое им объявление пространства имен не имело ничего общего с проблемой.

Настоящая причина, по которой это не работает, связана с проблемами безопасности (см. Выпуск 4197 , выпуск 111905 ).

Представьте себе такой сценарий:

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

2. Вы открываете в браузере локальную веб-страницу.

3. На локальной веб-странице создается адрес <iframe>, источником которого является https://mail.google.com/mail/ .

4. Поскольку вы вошли в Gmail, фрейм загружает сообщения в ваш почтовый ящик.

5. Локальная веб-страница считывает содержимое фрейма, используя для доступа JavaScript frames[0].document.documentElement.innerHTML. (Веб-страница в Интернете не сможет выполнить этот шаг, потому что она поступит из источника, отличного от Gmail; политика того же происхождения приведет к сбою чтения.)

6. Локальная веб-страница помещает содержимое вашего почтового ящика в папку <textarea>и отправляет данные через форму POST на веб-сервер злоумышленника. Теперь у злоумышленника есть ваш почтовый ящик , который может быть полезен для рассылки спама или идентификации кражи.

Chrome мешает описанному выше сценарию, накладывая ограничения на локальные файлы, открываемые с помощью Chrome. Чтобы преодолеть эти ограничения, у нас есть два решения:

1. Попробуйте запустить Chrome с --allow-file-access-from-files флагом. Я сам не тестировал это, но если это сработает, ваша система теперь также будет уязвима для сценариев, упомянутых выше.

2. Загрузите его на хост, и проблема решена.

На момент написания в chrome была ошибка, требовавшая xmlnsатрибута для запуска рендеринга:

<xsl:stylesheet xmlns="http://www.w3.org/1999/xhtml" ... >

Это была проблема, с которой я столкнулся при обслуживании файла xml с сервера .

Если, в отличие от меня, вы просматриваете xml-файл с file:///URL-адреса , то упомянутые решения --allow-file-access-from-files- это те, которые вам нужны

Проблема, основанная на Chrome, заключается не в пространстве имен xml, которое есть xmlns="http://www.w3.org/1999/xhtml". Без атрибута namesspace он не будет работать и с IE.

Из-за ограничения безопасности вы должны добавить --allow-file-access-from-filesфлаг при запуске Chrome. Я думаю , что Linux / * Никс пользователи могут легко это сделать с помощью терминала , но и для пользователей окон, вы должны открыть свойства этого ярлыка Chrome и добавить его в целевом назначении как ниже;

Щелкните правой кнопкой мыши -> Свойства -> Цель

Вот пример полного пути с флагами, которые я использую на своей машине;

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-file-access-from-files

Я надеюсь, что показ этой пошаговой инструкции поможет пользователям Windows решить эту проблему, поэтому я добавил этот пост.

У меня была такая же проблема на localhost. Бегаю по Интернету в поисках ответа, и я подтверждаю, что добавление --allow-file-access-from-filesработает. Я работаю на Mac, поэтому мне пришлось пройти через терминал sudo /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --allow-file-access-from-filesи ввести свой пароль (если он у вас есть).

Еще одна мелочь - ничего не будет работать, если вы не добавите в свой файл .xml ссылку на файл .xsl следующим образом <?xml-stylesheet type="text/xsl" href="<path to file>"?>. Еще одна мелочь, которую я не понял сразу - вы должны открывать XML-файл в браузере, а не .xsl.

Что ж, это не работает, если файл XML (начиная со стандартного PI:

<?xml-stylesheet type="text/xsl" href="..."?>

для ссылки на таблицу стилей XSL) используется как «application / xml». В этом случае Chrome все равно загрузит указанную таблицу стилей XSL, но ничего не будет отображаться, так как он автоматически изменит типы документов с «application / xml» на «Document» (! ??) и «text / xsl» на « Таблица стилей "(! ??), а затем попытается отобразить документ XML, как если бы это был документ HTML (5), без предварительного запуска его процессора XSLT. И вообще ничего не будет отображаться на экране (содержимое которого будет продолжать показывать предыдущую страницу, с которой была сделана ссылка на XML-страницу, и будет продолжать вращать значок, как если бы документ никогда не загружался полностью.

Отлично можно использовать консоль Chrome, которая показывает, что все ресурсы загружены, но неправильно интерпретируются.

Итак, да, Chrome в настоящее время отображает только XML-файлы (с необязательным объявлением ведущей таблицы стилей XSL), только если он обслуживается как «text / xml», но не как «application / xml», как это должно быть для XML, отображаемого на стороне клиента с Объявление XSL.

Для файлов XML, обслуживаемых как «text / xml» или «application / xml» и не содержащих объявления таблицы стилей XSL, Chrome по-прежнему должен использовать таблицу стилей по умолчанию, чтобы отобразить ее как дерево DOM или, по крайней мере, как источник текста. Но это не так, и здесь он снова пытается отобразить его, как если бы это был HTML, и сразу же выдает ошибки во многих скриптах (включая внутренний по умолчанию), которые пытаются получить доступ к «document.body» для обработки событий onLoad и внедрить некоторый javascript обработчик в нем.

Пример сайта, который не работает должным образом (документация Common Lisp) в Chrome, но работает в IE, который поддерживает XSLT на стороне клиента:

http://common-lisp.net/project/bknr/static/lmman/toc.html

Эта индексная страница выше отображается правильно, но все ссылки будут вести на XML-документы с базовым объявлением XSL для существующего документа таблицы стилей XSL, и вы можете ждать бесконечно долго, думая, что главы не могут быть загружены. Все, что вы можете сделать, чтобы прочитать документацию, - это открыть консоль и прочитать исходный код на вкладке «Ресурсы».

Насколько я могу судить, Chrome ищет заголовок

Тип содержимого: текст / xml

Тогда это работает --- другие итерации не удались.

Убедитесь, что ваш веб-сервер предоставляет это. Это также объясняет, почему он не работает для файлов xml file: // URI.

Проверьте http://www.aranedabienesraices.com.ar

Этот сайт построен на стороне клиента XML / XSLT. Он работает в IE6-7-8, FF, O, Safari и Chrome. Правильно ли вы отправляете заголовки HTTP? Соблюдаете ли вы политику одного происхождения?

Я пробовал поместить файл в wwwroot . Итак, при доступе к странице в Chrome это адрес localhost / yourpage.xml .

То, что говорит Эрик, правильно.

В xsl для тега xsl: stylesheet есть следующие атрибуты

version = "1.0" xmlns: xsl = "http://www.w3.org/1999/XSL/Transform" xmlns = "http://www.w3.org/1999/xhtml"

В хроме отлично работает.

Я начал тестировать это и столкнулся с проблемой безопасности локального файла / Chrome. Очень простой обходной путь - поместить файл XML и XSL, скажем, в общую папку Dropbox и получить ссылки на оба файла. Поместите ссылку на преобразование XSL в заголовок XML. Используйте ссылку XML в Chrome, И ЭТО РАБОТАЕТ!

Спустя 8 лет ситуация немного изменилась.

Я не могу открыть новый сеанс Google Chrome без других параметров и разрешить схему file :.

В macOS я делаю:

open -n -a "Google Chrome" --args \
    --disable-web-security \               # This disable all CORS and other security checks
    --user-data-dir=$HOME/fakeChromeDir    # This let you to force open a new Google Chrome session

Без этих аргументов я не могу протестировать таблицу стилей XSL локально.