XSLTをChromeで動作させるにはどうすればよいですか？

対応するXSLファイルとともに提供されるXMLドキュメントがここにあります。変換は、JavaScriptを使用せずに、クライアント側で実行する必要があります。

これはIE（ショックホラー）では正常に機能しますが、Google Chromeでは、ドキュメントのテキストノードを表示するだけです。

例を見たように、Chromeでクライアント側のXSLを実行できることは知っていますが、この成功を自分で再現することはまだできていません。

私は何が間違っているのですか？

エリックによる以下の他の答えは間違っています。彼が言及した名前空間宣言は、問題とは何の関係もありませんでした。

それが機能しない本当の理由は、セキュリティ上の懸念によるものです（問題4197、問題111905を参照）。

このシナリオを想像してみてください。

1. 攻撃者から、ダウンロードしたWebページを添付ファイルとして含む電子メールメッセージを受信します。

2. ブラウザでローカルのWebページを開きます。

3. ローカルWebページは、<iframe>ソースがhttps://mail.google.com/mail/であるを作成します。

4. Gmailにログインしているため、フレームはメッセージを受信トレイに読み込みます。

5. ローカルWebページは、JavaScriptを使用してにアクセスすることにより、フレームのコンテンツを読み取りますframes[0].document.documentElement.innerHTML。（オンラインWebページはGmail以外のオリジンからのものであるため、この手順を実行できません。同一生成元ポリシーにより、読み取りが失敗します。）

6. ローカルWebページは、受信ボックスの内容をに配置<textarea>し、フォームPOSTを介して攻撃者のWebサーバーにデータを送信します。これで、攻撃者は受信トレイを手に入れました。これは、スパムやなりすましに役立つ可能性があります。

Chromeは、Chromeを使用して開かれるローカルファイルに制限を設けることにより、上記のシナリオを阻止します。これらの制限を克服するために、2つの解決策があります。

1. --allow-file-access-from-files フラグを付けてChromeを実行してみてください。私はこれを自分でテストしていませんが、機能する場合は、システムも上記の種類のシナリオに対して脆弱になります。

2. それをホストにアップロードすると、問題が解決します。

これを書いている時点で、レンダリングをトリガーするために属性を必要とするchromeのバグがありましたxmlns。

<xsl:stylesheet xmlns="http://www.w3.org/1999/xhtml" ... >

これは、サーバーからxmlファイルを提供するときに遭遇した問題でした。

私とは異なり、file:///URLからxmlファイルを表示し--allow-file-access-from-filesている場合は、言及されているソリューションが必要なソリューションです。

基づいて問題Chromeは話ではありませんXML名前空間ですxmlns="http://www.w3.org/1999/xhtml"。namesspace属性がないと、IEでも機能しません。

セキュリティ上の制限があるため--allow-file-access-from-files、Chromeを起動するときにフラグを追加する必要があります。linux / * nixユーザーはターミナルを介して簡単にそれを行うことができると思いますが、Windowsユーザーの場合は、Chromeショートカットのプロパティを開き、以下のようにターゲットの宛先に追加する必要があります。

右クリック->プロパティ->ターゲット

これは、私のマシンで使用するフラグを含むフルパスのサンプルです。

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --allow-file-access-from-files

このステップバイステップを示すことが、Windowsユーザーの問題の解決に役立つことを願っています。これが、この投稿を追加した理由です。

ローカルホストでも同じ問題が発生しました。答えを探してインターネットを走り回って、私は追加が--allow-file-access-from-filesうまくいくことを承認します。私はMacで作業しているので、ターミナルsudo /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --allow-file-access-from-filesを経由してパスワードを入力する必要がありました（パスワードがある場合）。

もう1つの小さなこと-次のように.xmlファイルに.xslファイルへの参照を追加しない限り何も機能しません<?xml-stylesheet type="text/xsl" href="<path to file>"?>。私がすぐに気づかなかったもう1つの小さなことは、.xslではなくブラウザで.xmlファイルを開く必要があることです。

XMLファイルの場合は機能しません（標準のPIから開始：

<?xml-stylesheet type="text/xsl" href="..."?>

XSLスタイルシートを参照するため）は「application / xml」として提供されます。その場合、Chromeは参照されているXSLスタイルシートをダウンロードしますが、ドキュメントタイプを「application / xml」から「Document」（！??）に、「text / xsl」を「」にサイレントに変更するため、何もレンダリングされません。スタイルシート」（！??）を実行すると、最初にXSLTプロセッサを実行せずに、XMLドキュメントをHTML（5）ドキュメントであるかのようにレンダリングしようとします。また、画面には何も表示されません（そのコンテンツには、XMLページが参照された前のページが引き続き表示され、ドキュメントが完全に読み込まれなかったかのようにアイコンが回転し続けます。

Chromeコンソールを完全に使用できます。これは、すべてのリソースが読み込まれていることを示していますが、誤って解釈されています。

そうです、Chromeは現在XMLファイル（オプションの先頭のXSLスタイルシート宣言を含む）のみをレンダリングします。これは「text / xml」として提供される場合のみであり、クライアント側でレンダリングされたXMLの場合のように「application / xml」としては提供されません。 XSL宣言。

「text / xml」または「application / xml」として機能し、XSLスタイルシート宣言を含まないXMLファイルの場合でも、Chromeはデフォルトのスタイルシートを使用してDOMツリーとして、または少なくともテキストソースとしてレンダリングする必要があります。しかし、そうではなく、ここでもHTMLであるかのようにレンダリングしようとし、onLoadイベントを処理してjavascriptを挿入するために「document.body」にアクセスしようとする多くのスクリプト（デフォルトの内部スクリプトを含む）ですぐにバグが発生しますその中のハンドラー。

Chromeでは期待どおりに機能しないが、クライアント側のXSLTをサポートするIEでは機能するサイトの例：

http://common-lisp.net/project/bknr/static/lmman/toc.html

上記のインデックスページは正しく表示されますが、すべてのリンクは、既存のXSLスタイルシートドキュメントへの基本的なXSL宣言を含むXMLドキュメントに移動します。章のダウンロードに問題があると考えて、無期限に待つことができます。ドキュメントを読むためにできることは、コンソールを開いて[リソース]タブのソースコードを読むことだけです。

私が知る限り、Chromeはヘッダーを探しています

コンテンツタイプ：text / xml

その後、動作します---他の反復は失敗しました。

Webサーバーがこれを提供していることを確認してください。また、file：// URIxmlファイルで失敗する理由についても説明します。

http://www.aranedabienesraices.com.arを確認してください

このサイトは、XML / XSLTクライアント側で構築されています。IE6-7-8、FF、O、Safari、Chromeで動作します。HTTPヘッダーを正しく送信していますか？同一生成元ポリシーを尊重していますか？

ファイルを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ヘッドに配置します。ChromeでXMLリンクを使用してください。

8年後、状況は少し変わりました。

他のパラメータがないとGoogleChromeの新しいセッションを開くことができず、「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スタイルシートをテストできません。