У меня есть XML - документ здесь , который подается с соответствующим файлом XSL . Преобразование остается выполняться на стороне клиента, без JavaScript.
Это отлично работает в IE (ужас шока), но в Google Chrome просто отображает текстовые узлы документа.
Я знаю, что в Chrome можно использовать XSL на стороне клиента, поскольку я видел примеры этого, но я еще не смог повторить этот успех сам.
Что я делаю не так?
Ответы:
Другой ответ Эрика ниже неверен. Упомянутое им объявление пространства имен не имело ничего общего с проблемой.
Настоящая причина, по которой это не работает, связана с проблемами безопасности (см. Выпуск 4197 , выпуск 111905 ).
Представьте себе такой сценарий:
Вы получаете электронное письмо от злоумышленника, содержащее веб-страницу в качестве вложения, которое вы загружаете.
Вы открываете в браузере локальную веб-страницу.
На локальной веб-странице создается адрес <iframe>, источником которого является https://mail.google.com/mail/ .
Поскольку вы вошли в Gmail, фрейм загружает сообщения в ваш почтовый ящик.
Локальная веб-страница считывает содержимое фрейма, используя для доступа JavaScript frames[0].document.documentElement.innerHTML. (Веб-страница в Интернете не сможет выполнить этот шаг, потому что она поступит из источника, отличного от Gmail; политика того же происхождения приведет к сбою чтения.)
Локальная веб-страница помещает содержимое вашего почтового ящика в папку <textarea>и отправляет данные через форму POST на веб-сервер злоумышленника. Теперь у злоумышленника есть ваш почтовый ящик , который может быть полезен для рассылки спама или идентификации кражи.
Chrome мешает описанному выше сценарию, накладывая ограничения на локальные файлы, открываемые с помощью Chrome. Чтобы преодолеть эти ограничения, у нас есть два решения:
Попробуйте запустить Chrome с --allow-file-access-from-files флагом. Я сам не тестировал это, но если это сработает, ваша система теперь также будет уязвима для сценариев, упомянутых выше.
Загрузите его на хост, и проблема решена.
--allow-file-access-from-filesотлично работает.
На момент написания в 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, и вы можете ждать бесконечно долго, думая, что главы не могут быть загружены. Все, что вы можете сделать, чтобы прочитать документацию, - это открыть консоль и прочитать исходный код на вкладке «Ресурсы».
Проверьте http://www.aranedabienesraices.com.ar
Этот сайт построен на стороне клиента XML / XSLT. Он работает в IE6-7-8, FF, O, Safari и Chrome. Правильно ли вы отправляете заголовки HTTP? Соблюдаете ли вы политику одного происхождения?
То, что говорит Эрик, правильно.
В 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 локально.