web-dev-qa-db-ja.com

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

XMLドキュメント here があり、対応する XSLファイル とともに提供されています。変換は、JavaScriptなしでクライアント側で実行されます。

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

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

何が間違っていますか？

xsltgoogle-chrome
81
Eric

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

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

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

私と違って、xmlファイルを表示している場合[file:/// urlから]、[--allow-file-access-from-filesは必要なものです

14
Eric

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

それが機能しない本当の理由は、 セキュリティ上の懸念による （cf. issue 4197 、 issue 111905 ）です。

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

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

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

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

  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. ホストにアップロードし、問題を解決しました。

112
Pacerier

ローカルホストでも同じ問題が発生しました。インターネットを駆け回って答えを探して、--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ではありません。

5
Setrino

Chromeに基づく問題は、xmlns="http://www.w3.org/1999/xhtml"であるxml名前空間に関するものではありません。 namesspace属性がないと、IEでも動作しません。

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

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

enter image description here

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

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

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

4
Levent Divilioglu

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」として提供され、「application/xml」としてではない場合のみ） XSL宣言を使用してクライアント側でレンダリングされたXMLの場合。

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

Chromeで期待どおりに動作しないサイト（Common LISPのドキュメント）の例ですが、IEで動作し、クライアント側のXSLTをサポートしています：

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

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

3
verdy_p

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

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

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

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

2
John

チェック http://www.aranedabienesraices.com.ar

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

1
user357812

エリックの言うことは正しい。

Xslでは、xsl：stylesheetタグには次の属性があります

version = "1.0" xmlns：xsl = "http://www.w3.org/1999/XSL/Transform" xmlns = "http://www.w3.org/1999/xhtml"

クロムでは正常に動作します。

0
P Subramanian

これをテストし始め、ローカルファイルに遭遇しました/ Chromeセキュリティの問題。非常に簡単な回避策は、たとえばDropboxパブリックフォルダーにXMLファイルとXSLファイルを置き、両方のファイルへのリンクを取得することです。 XMLヘッドのXSL変換へのリンクChrome AND IT WORKS！のXMLリンクを使用してください！

0
Mark Whitener

ファイルをwwwrootに入れてみました。したがって、Chromeでページにアクセスするとき、これはアドレスlocalhost/yourpage.xmlです。

0
MiddleKay

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

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

0
Matteo Gaggiano