У меня есть XML-документ здесь, который подается с соответствующим XSL файл. Преобразование остается исполняемым на стороне клиента, без JavaScript.
Это отлично работает в IE (ужасный ужас), но в Google Chrome просто отображаются текстовые узлы документа.
Я знаю, что в Chrome можно сделать XSL-клиент на стороне клиента, поскольку я видел его примеры, но я еще не смог воспроизвести этот успех сам.
Что я делаю неправильно?
На момент написания сообщения была ошибка chrome, для которой требуется атрибут xmlns для запуска рендеринга:
<xsl:stylesheet xmlns="http://www.w3.org/1999/xhtml" ... >
Это была проблема, с которой я столкнулся при работе с XML файлом с сервера.
Если в отличие от меня, вы просматриваете xml файл с URL-адреса file:///, то решения, относящиеся к --allow-file-access-from-files, вам нужны
Другой ответ, приведенный Эриком, неверен. В названии пространства имен, которое он упомянул, не было ничего общего с этой проблемой.
Настоящая причина, по которой она не работает, из-за проблем с безопасностью (см. issue 4197, issue 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. Я сам не тестировал это, но если это сработает, ваша система также будет уязвима для сценариев подобного рода.
Загрузите его на хост, и проблема будет решена.
У меня была такая же проблема на 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.
Проблема, основанная на Chrome, относится не к пространству имен xml, которое xmlns="http://www.w3.org/1999/xhtml". Без атрибута namesspace он не будет работать и с IE.
Из-за ограничения безопасности вам нужно добавить флаг --allow-file-access-from-files при запуске хром. Я думаю, что пользователи linux/* nix могут легко это сделать через терминал, но для пользователей Windows, вы должны открыть свойства ярлыка Chrome и добавить его в целевом назначении как показано ниже;
Щелкните правой кнопкой мыши → Свойства → Цель
Вот пример полного пути с флагами, которые я использую на своей машине;
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-file-access-from-files
Я надеюсь, что показ этого шаг за шагом поможет пользователям Windows для проблемы, поэтому я добавил этот пост.
Ну, это не сработает, если файл XML (начиная со стандартного PI:
<?xml-stylesheet type="text/xsl" href="..."?>
для ссылки на таблицу стилей XSL) используется как "application/xml". В этом случае Chrome по-прежнему будет загружать таблицу стилей XSL, на которую ссылается, но ничего не будет отображаться, так как она беззвучно изменяет типы документов из "application/xml" в "Document" (!??) и "text/xsl" в "Stylesheet" (!??), а затем попытается отобразить 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 обработчик в нем.
Пример сайта, который не работает должным образом (общая 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-заголовки? Вы уважаете политику одного и того же происхождения?
Насколько я могу судить, Chrome ищет заголовок
Content-Type: text/xml
Затем он работает, другие итерации потерпели неудачу.
Убедитесь, что ваш веб-сервер предоставляет это. Он также объясняет, почему это не удается для файлов://URI xml.
Я попытался поместить файл в 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 и IT WORKS!