Comment puis-je faire fonctionner XSLT en chrome?
J'ai un document XML ici qui est servi avec un fichier fichier XSL correspondant . La transformation est laissée à exécuter côté client, sans JavaScript.
Cela fonctionne bien dans IE (horreur du choc), mais dans Google Chrome, il n’affiche que les nœuds de texte du document.
Je sais qu'il est possible d'utiliser XSL côté client dans Chrome, comme j'en ai vu des exemples, mais je ne suis pas encore en mesure de reproduire moi-même ce succès.
Qu'est-ce que je fais mal?
Au moment de la rédaction de ce document, il existait un bogue dans chrome qui nécessitait un attribut xmlns pour déclencher le rendu:
<xsl:stylesheet xmlns="http://www.w3.org/1999/xhtml" ... >
C'est le problème que je rencontrais lorsque je servais le fichier XML d'un serveur.
Si contrairement à moi, vous visualisez le fichier XML à partir d'une URL file:///, les solutions mentionnant --allow-file-access-from-files sont celles que vous souhaitez.
L'autre réponse ci-dessous par Eric est fausse. La déclaration d'espace de nommage qu'il a mentionnée n'avait rien à voir avec le problème.
La vraie raison pour laquelle cela ne fonctionne pas est pour des raisons de sécurité (cf. numéro 4197 , numéro 111905 ).
Imaginez ce scénario:
Vous recevez un courrier électronique d'un attaquant contenant une page Web en pièce jointe, que vous téléchargez.
Vous ouvrez la page Web maintenant local dans votre navigateur.
La page Web locale crée un
<iframe>dont la source est https://mail.google.com/mail/ .Comme vous êtes connecté à Gmail, le cadre charge les messages dans votre boîte de réception.
La page Web locale lit le contenu du cadre en utilisant JavaScript pour accéder à
frames[0].document.documentElement.innerHTML. (Une page Web en ligne ne pourrait pas exécuter cette étape car elle proviendrait d'une origine non Gmail; la règle de même origine entraînerait l'échec de la lecture.)La page Web locale place le contenu de votre boîte de réception dans un
<textarea>et soumet les données via un formulaire POST au serveur Web de l'attaquant. Maintenant l'attaquant a votre boîte de réception, ce qui peut être utile pour spammer ou identifier un vol.
Chrome déjoue le scénario ci-dessus en mettant en place des restrictions sur les fichiers locaux ouverts à l'aide de Chrome. Pour surmonter ces restrictions, nous avons deux solutions:
Essayez d’exécuter Chrome avec le
--allow-file-access-from-filesflag. Je n'ai pas testé cela moi-même, mais si cela fonctionne, votre système sera désormais également vulnérable aux scénarios du type mentionné ci-dessus.Téléchargez-le sur un hôte et le problème est résolu.
J'ai eu le même problème sur localhost. Courir sur Internet à la recherche de la réponse et j'approuve que l'ajout de --allow-file-access-from-files fonctionne. Je travaille sur Mac, donc pour moi, j’ai dû passer par le terminal Sudo /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --allow-file-access-from-files et entrer votre mot de passe (si vous en avez un).
Autre petite chose: rien ne fonctionnera à moins d’ajouter à votre fichier .xml la référence à votre fichier .xsl comme suit: <?xml-stylesheet type="text/xsl" href="<path to file>"?>. Une autre petite chose que je ne savais pas tout de suite: vous devriez ouvrir votre fichier .xml dans un navigateur, pas le .xsl.
Le problème basé sur Chrome ne concerne pas l'espace de noms xml, qui est xmlns="http://www.w3.org/1999/xhtml". Sans l'attribut namesspace, cela ne fonctionnera pas non plus avec IE.
En raison de la restriction de sécurité, vous devez ajouter l'indicateur --allow-file-access-from-files lorsque vous démarrez Chrome. Je pense que les utilisateurs de linux/* nix peuvent le faire facilement via le terminal, mais pour les utilisateurs de Windows, vous devez ouvrir le raccourci properties du raccourci Chrome et l’ajouter à la destination cible comme indiqué ci-dessous;
Clic droit -> Propriétés -> Cible
Voici un exemple de chemin complet avec les drapeaux que j'utilise sur ma machine;
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-file-access-from-files
J'espère que montrer cette étape par étape aidera les utilisateurs de Windows à résoudre ce problème, c'est pourquoi j'ai ajouté ce post.
Eh bien cela ne fonctionne pas si le fichier XML (à partir du PI standard:
<?xml-stylesheet type="text/xsl" href="..."?>
pour référencer la feuille de style XSL) est servi en tant que "application/xml". Dans ce cas, Chrome téléchargera toujours la feuille de style XSL référencée, mais rien ne sera rendu, car les types de document "application/xml" seront silencieusement modifiés en "Document" (! ??) et "text/xsl" en " Stylesheet "(! ??), puis tentera de restituer le document XML comme s'il s'agissait d'un document HTML (5), sans exécuter au préalable son processeur XSLT. Et rien du tout ne sera affiché à l'écran (dont le contenu continuera à afficher la page précédente à partir de laquelle la page XML a été référencée et continuera à faire pivoter l'icône, comme si le document n'avait jamais été chargé complètement.
Vous pouvez parfaitement utiliser la console Chrome, qui montre que toutes les ressources sont chargées, mais elles sont interprétées de manière incorrecte.
Donc, oui, Chrome ne rend actuellement que les fichiers XML (avec sa déclaration facultative de feuille de style XSL en tête), uniquement s'il est servi en tant que "text/xml", mais pas en tant qu '"application/xml" Déclaration XSL.
Pour les fichiers XML "text/xml" ou "application/xml" qui ne contiennent pas de déclaration de feuille de style XSL, Chrome doit toujours utiliser une feuille de style par défaut pour la restituer sous forme d'arborescence DOM ou au moins de source de texte. Mais ce n’est pas le cas, et là encore, il tente de le restituer comme si c’était du HTML, et corrige immédiatement de nombreux scripts (y compris un script interne par défaut) qui tente d’accéder à "document.body" pour gérer les événements onLoad et injecter du gestionnaire en elle.
Un exemple de site qui ne fonctionne pas comme prévu (documentation Common LISP) dans Chrome, mais fonctionne dans IE, qui prend en charge le XSLT côté client:
http://common-LISP.net/project/bknr/static/lmman/toc.html
La page d'index ci-dessus s'affiche correctement, mais tous les liens conduisent à des documents XML avec une déclaration XSL de base vers un document de feuille de style XSL existant. Vous pouvez donc attendre indéfiniment, en pensant que le téléchargement des chapitres pose problème. Tout ce que vous pouvez faire pour lire la documentation consiste à ouvrir la console et à lire le code source dans l'onglet Ressources.
Autant que je sache, Chrome recherche l'en-tête.
Type de contenu: text/xml
Ensuite, cela fonctionne - les autres itérations ont échoué.
Assurez-vous que votre serveur Web fournit cela. Cela explique également pourquoi il échoue pour les fichiers file: // URI xml.
Vérifier http://www.aranedabienesraices.com.ar
Ce site est construit avec XML/XSLT côté client. Cela fonctionne sur IE6-7-8, FF, O, Safari et Chrome . Envoyez-vous les en-têtes HTTP correctement? Respectez-vous la politique de même origine?
Ce que dit Eric est correct.
Dans le fichier xsl, la balise xsl: stylesheet a les attributs suivants
version = "1.0" xmlns: xsl = "http://www.w3.org/1999/XSL/Transform" xmlns = "http://www.w3.org/1999/xhtml"
Cela fonctionne très bien en chrome.
J'ai commencé à tester cela et je me suis heurté au problème de sécurité local du fichier/Chrome. Une solution de contournement très simple consiste à placer les fichiers XML et XSL, par exemple dans le dossier public de Dropbox, et à obtenir des liens vers les deux fichiers. Placez le lien vers la transformation XSL dans la tête XML. Utilisez le lien XML dans Chrome AND IT WORKS!
J'ai essayé de mettre le fichier dans le répertoire wwwroot . Ainsi, lors de l'accès à la page dans Chrome, il s'agit de l'adresse localhost/yourpage.xml .
Après 8 ans, la situation est un peu modifiée.
Je ne parviens pas à ouvrir une nouvelle session de Google Chrome sans autres paramètres et j'autorise le schéma 'fichier:'.
Sur macOS je fais:
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
Sans ces arguments, je suis incapable de tester la feuille de style XSL en local.