Tengo un documento XML aquí que se sirve con un archivo XSL correspondiente . Se deja que la transformación se ejecute en el lado del cliente, sin JavaScript.
Esto funciona bien en IE (horror de choque), pero en Google Chrome, solo muestra los nodos de texto del documento.
Sé que es posible hacer XSL del lado del cliente en Chrome, ya que he visto ejemplos, pero todavía no puedo replicar este éxito por mí mismo.
¿Qué estoy haciendo mal?
Respuestas:
La otra respuesta de Eric a continuación es incorrecta. La declaración del espacio de nombres que mencionó no tuvo nada que ver con el problema.
La verdadera razón por la que no funciona es debido a problemas de seguridad ( consulte el número 4197 , el número 111905 ).
Imagina este escenario:
Recibe un mensaje de correo electrónico de un atacante que contiene una página web como archivo adjunto, que descarga.
Abre la página web ahora local en su navegador.
La página web local crea una <iframe>cuya fuente es https://mail.google.com/mail/ .
Debido a que ha iniciado sesión en Gmail, el marco carga los mensajes en su bandeja de entrada.
La página web local lee el contenido del marco utilizando JavaScript para acceder frames[0].document.documentElement.innerHTML. (Una página web en línea no podría realizar este paso porque provendría de un origen que no es de Gmail; la política del mismo origen haría que la lectura fallara).
La página web local coloca el contenido de su bandeja de entrada en un <textarea>correo electrónico y envía los datos a través de un formulario POST al servidor web del atacante. Ahora el atacante tiene su bandeja de entrada , que puede ser útil para enviar spam o robo de identidad.
Chrome frustra el escenario anterior al imponer restricciones a los archivos locales abiertos con Chrome. Para superar estas restricciones, tenemos dos soluciones:
Intenta ejecutar Chrome con la --allow-file-access-from-files bandera. No lo he probado yo mismo, pero si funciona, su sistema ahora también será vulnerable a escenarios del tipo mencionado anteriormente.
Súbelo a un host y problema resuelto.
xmlnsatributo. Es posible que esto haya cambiado en versiones más recientes de Chrome.
--allow-file-access-from-filesfunciona bien.
En el momento de escribir este artículo, había un error en Chrome que requería un xmlnsatributo para activar el renderizado:
<xsl:stylesheet xmlns="http://www.w3.org/1999/xhtml" ... >
Este era el problema con el que me encontraba al servir el archivo xml desde un servidor .
Si, a diferencia de mí, está viendo el archivo xml desde una file:///URL , entonces las soluciones mencionadas --allow-file-access-from-filesson las que desea.
El problema basado en Chrome no se trata del espacio de nombres xml que es xmlns="http://www.w3.org/1999/xhtml". Sin el atributo de espacio de nombres, tampoco funcionará con IE.
Debido a la restricción de seguridad, debe agregar la --allow-file-access-from-filesbandera cuando inicie Chrome. Creo que los usuarios de linux / * nix pueden hacerlo fácilmente a través de la terminal, pero para los usuarios de Windows, deben abrir las propiedades del acceso directo de Chrome y agregarlo en el destino de destino como se muestra a continuación;
Clic derecho -> Propiedades -> Destino
Aquí hay una ruta completa de muestra con las banderas que uso en mi máquina;
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-file-access-from-files
Espero que mostrar este paso a paso ayude a los usuarios de Windows con el problema, es por eso que agregué esta publicación.
Tuve el mismo problema en localhost. Corriendo por Internet buscando la respuesta y apruebo que agregar --allow-file-access-from-filesfunciona. Trabajo en Mac, así que para mí tuve que pasar por la terminal sudo /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --allow-file-access-from-filese ingresar su contraseña (si tiene una).
Otra pequeña cosa: nada funcionará a menos que agregue a su archivo .xml la referencia a su archivo .xsl de la siguiente manera <?xml-stylesheet type="text/xsl" href="<path to file>"?>. Otra pequeña cosa de la que no me di cuenta de inmediato: debería abrir su archivo .xml en el navegador, no el .xsl.
Bueno, no funciona si el archivo XML (comenzando por el PI estándar:
<?xml-stylesheet type="text/xsl" href="..."?>
para hacer referencia a la hoja de estilo XSL) se sirve como "application / xml". En ese caso, Chrome seguirá descargando la hoja de estilo XSL a la que se hace referencia, pero no se procesará nada, ya que cambiará silenciosamente los tipos de documentos de "application / xml" a "Document" (! ??) y "text / xsl" into " Stylesheet "(! ??), y luego intentará representar el documento XML como si fuera un documento HTML (5), sin ejecutar primero su procesador XSLT. Y no se mostrará nada en la pantalla (cuyo contenido seguirá mostrando la página anterior desde la que se hizo referencia a la página XML, y seguirá girando el icono, como si el documento nunca se hubiera cargado completamente.
Se puede utilizar perfectamente la consola de Chrome, que muestra que todos los recursos están cargados, pero se interpretan incorrectamente.
Así que sí, Chrome actualmente solo procesa archivos XML (con su declaración de hoja de estilo XSL principal opcional), solo si se sirve como "texto / xml", pero no como "aplicación / xml" como debería para XML representado del lado del cliente con un Declaración XSL.
Para los archivos XML servidos como "texto / xml" o "aplicación / xml" y que no contienen una declaración de hoja de estilo XSL, Chrome debe seguir usando una hoja de estilo predeterminada para representarla como un árbol DOM, o al menos como su fuente de texto. Pero no es así, y aquí nuevamente intenta representarlo como si fuera HTML, y falla inmediatamente en muchos scripts (incluido uno interno predeterminado) que intentan acceder a "document.body" para manejar eventos onLoad e inyectar algo de javascript manejador en él.
Un ejemplo de sitio que no funciona como se esperaba (la documentación de Common Lisp) en Chrome, pero funciona en IE que admite XSLT del lado del cliente:
http://common-lisp.net/project/bknr/static/lmman/toc.html
Esta página de índice anterior se muestra correctamente, pero todos los enlaces conducirán a documentos XML con una declaración XSL básica a un documento de hoja de estilo XSL existente, y puede esperar indefinidamente, pensando que los capítulos tienen problemas para descargarse. Todo lo que puede hacer para leer la documentación es abrir la consola y leer el código fuente en la pestaña Recursos.
Consulte http://www.aranedabienesraices.com.ar
Este sitio está construido con XML / XSLT del lado del cliente. Funciona en IE6-7-8, FF, O, Safari y Chrome. ¿Está enviando los encabezados HTTP correctamente? ¿Está respetando la política del mismo origen?
xmlnsatributo.
Lo que dice Eric es correcto.
En el xsl, para el xsl: la etiqueta de la hoja de estilo tiene los siguientes atributos
versión = "1.0" xmlns: xsl = "http://www.w3.org/1999/XSL/Transform" xmlns = "http://www.w3.org/1999/xhtml"
Funciona bien en cromo.
Comencé a probar esto y encontré el problema de seguridad del archivo local / Chrome. Una solución alternativa muy sencilla es colocar el archivo XML y XSL, por ejemplo, en la carpeta pública de Dropbox y obtener enlaces a ambos archivos. Coloque el enlace a la transformación XSL en el encabezado XML. Utilice el enlace XML en Chrome ¡Y FUNCIONA!
Después de 8 años, la situación cambia un poco.
No puedo abrir una nueva sesión de Google Chrome sin otros parámetros y permitir el esquema 'archivo:'.
En macOS hago:
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
Sin estos argumentos, no puedo probar la hoja de estilo XSL en local.