У мене є документ 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 позначкою. Я не тестував цього сам, але якщо це спрацює, ваша система тепер також буде вразливою до сценаріїв, згаданих вище.
Завантажте його на хост, і проблема вирішена.
xmlnsатрибута. Це могло змінитися в нових версіях chrome.
--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є тими, які ви хочете
У мене була та ж проблема на 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 / * Нікс користувачі можуть легко це зробити з допомогою терміналу , але і для користувачів вікон, ви повинні відкрити властивості цього ярлика 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" на " Таблиця стилів "(! ??), а потім спробує відобразити документ 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? Ви поважаєте політику того самого походження?
xmlnsатрибут.
Те, що каже Ерік, є правильним.
У xsl тег таблиці стилів xsl: має такі атрибути
версія = "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 без інших параметрів і дозволити схему "файл:".
На 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 локально.