1

サンプルのブックマークレットを作成して、現在の Web ページのソース コードを取得し、それをバリデーターに渡そうとしています。Validator はオンライン Web サイトではなく、javascript と html ファイルの束を含むフォルダーです。javascript ブックマークレット コードを使用して file:///C:/Users/Electrifyings/Desktop/Validator/Main.html ファイルを開き、新しく開いたウィンドウのテキスト領域にソース コードを配置しようとしていますが、私が認識していないいくつかの理由で機能していません。

アルゴリズムを使用したサンプルコードは次のとおりです。

javascript:(function(){var t = document.body.innerHTML;window.open('file:///C:/Users/RandomHero/Desktop/test.html',_self);document.getElementById("validator_textarea")=t;})()

手順は次のとおりです。

  1. 変数で現在の Web ページのソース コードを取得します。
  2. ローカルに保存された HTML Web ページを現在のウィンドウまたは新しいウィンドウまたは新しいタブで開きます (どちらの方法でも問題ありませんが、うまくいきません)。
  3. 変数のソース コードを、新しく開いた HTML ファイルのバリデータ テキスト領域に配置します。

上記のコードをさまざまなバリエーションで試しましたが、新しいウィンドウを開く部分で行き詰まりました。新しいウィンドウをまったく開いていないか、ファイルをロードせずに空白のウィンドウを開いています。

この問題について何かお役に立てれば幸いです。どうもありがとうございました。

ところで、

Windows 7 x64、IE、Firefox、Chrome を試しました。すべての最新の安定したビルド。ブラウザ側の問題ではないと思いますが、javascript コードが file:/// プロトコルで URI を開かないことに関連するものです。さらに詳細が必要な場合はお知らせください。:)

4

1 に答える 1

1

アクセスした Web ページを開いて欲しくありませんfile://c:/Program Files/Quicken/YourSensitiveTaxInfoか? 間違って「悪い」Web サイト (ハッカーによって侵害された安っぽい Web サイトまたは良い Web サイト) にアクセスすると、インター Web 上の悪意のある人々が突然あなたの個人情報にアクセスできるようになります。それはひどいでしょう。

ブラウザの作成者はこれを知っており、そのため、Javascript コードがユーザーのローカル コンピュータ上のファイルにアクセスできないように、非常に厳しい制限を設けています。これがあなたの計画の邪魔になっているものです。

ソリューション？

  • バリデーター全体をブックマークレットに組み込みます (非常に小さい場合を除き、動作しない可能性があります)。
  • バリデータ コードを Web のどこかに配置する
  • プラグインを作成します (ユーザーはプラグインのインストールを選択する必要があるため、Web ページよりもはるかに自由度が高くなります ... Firefox や Chrome などの場合、プラグインは基本的に単なる Javascript ですが)

* * 編集 * *

  • 純粋なクライアント側の実装に限定しない場合の追加のボーナスソリューション:
    1. ブックマークレットで通常の (HTML) フォームをページに追加します。
    2. ページにiframeも追加（CSSスタイリングで非表示にすればOK）
    3. iframe を指すようにフォームの target 属性を設定します。これにより、ユーザーがフォームを送信し、サーバーがその送信に返信したときに、サーバーの返信が通常のようにページを置き換えるのではなく、(非表示の) iframe に送られるようになります。
    4. ファイル入力をフォームに追加します。Javascript を使用してその入力内のファイルにアクセスすることはできませんが、ブックマークレットではなくサーバーがアクセスするため、問題ありません。
    5. フォームの送信を受け取り、送信されたファイルを読み取り、そのファイルを応答として返すサーバー側スクリプトを作成します。つまり、POST できる URL があり、POST の内容にファイルがあると、そのファイルの内容で応答します。
    6. ユーザーがファイル入力を使用してバリデーターファイルを選択し、それをサーバーにアップロードできるようになったので、サーバーは取得したばかりのファイルで応答し、そのファイルは iframe のコンテンツとして表示されます。
    7. これで、(iframe 内で) 苦労して取得したファイルがようやくできたので$('#thatIframe').html()、ファイルにアクセスできます。現在のページのソースを保存してから、ページ全体をそのアップロードされたファイルで置き換える (そして、保存したページのソースを新しいバリデータ ページに戻す) か、アップロードされたバリデータ ファイルのコンテンツを使用して、その他の操作を行うことができます。

もちろん、ファイルがコンピューターごとに変わらない場合は、バリデーター ファイルを送り返すサーバーを用意するだけで、すべてを簡単に行うことができます。これは、静的ファイルを提供するだけでよいため、ロジックがまったくない純粋な Apache サーバーである可能性があります。

いずれにせよ、このアプローチを採用し、新しいファイル アップロード スクリプトが最初の Web ページと同じサーバー上にない場合、クロスドメイン スクリプトの制限という新しいセキュリティ上の問題が発生します。ただし、これらの制限はローカル ファイル アクセスの制限よりもはるかに厳しくないため、それらを回避する方法があります (JSONP、クロスサイト ポリシー ファイルなど)。これらの手法を説明する素晴らしいスタック オーバーフローの投稿が既に山ほどあるので、ここであえて繰り返すことはしません。

それが役立つことを願っています。

于 2012-06-29T17:08:35.317 に答える