＃を含むURLを持つWget

11

のようなURLをダウンロードしようとしていますhttp://www.somesite.com/restaurants.html#photo=22x00085。

単一引用符の間に挿入しましたが、正しいページではないhttp://www.somesite.com/restaurants.htmlのみをダウンロードします。

解決策はありますか？

wget url

— user1289749
ソース

今これをテストすることはできませんが、私が覚えていることから、％20はスペースで動作するので、おそらく％23は＃で動作します（％23は＃のパーセントエンコーディングです）

— -lupincho

3

同じHTMLファイルではないですか？＃は、Webブラウザにページの特定の部分にジャンプするよう指示するだけの場合があります。

— -barlop

20

wget正常に動作しています。URI構文ことを指定フラグメント - #foo部分は-クライアント側の完全に解釈されるべきである、といない文書自体を取得するときに使用。

たとえば、HTMLページの場合、ブラウザは指定されたセクションまでスクロールダウンするか、場合によっては特定の写真を表示するJavaScriptコードをトリガーします。

つまり、wget懸念される限り、URI

... 同じページを指します /restaurants.html。残りの作業は、ブラウザ次第です。restaurants.html#photo=22x00085ブラウザで開くと正常に動作するはずです。

— user1686
ソース

8

適切なリンクにアクセスしないと、どのリンクかわかりませんが、2つのオプションしかありません。

ハッシュは、実際には要求されたドキュメントの名前の一部を形成します。この場合、エンコードできます：

http://www.somesite.com/restaurants.html%23photo=22x00085
それ以外の場合、通常の状況では、http：//www.somesite.com/restaurants.htmlとhttp://www.somesite.com/restaurants.html#photo=22x00085は同じページを指している必要があります。ハッシュの後の部分は、ページをロードした後にブラウザがスクロールするアンカーを単に示しています。サーバーにも送信されません。

しかし、それはあるハッシュはJavaScriptを使用して、特定の写真をロードするために使用される（A-B）であることを、可能性。WgetはJavaScriptを解釈できないので、それについてできることは何もありません。

— デニス
ソース

この方法でURLフラグメントを悪用する多くのサイトを見てきました。リストの一番上にあるのはGoogle自身です。「それが動作する」ので、これは...、多くの人が介護に思えることをRFCの全体の束に違反ではなく

— マイケル・ハンプトン

1

@MichaelHampton：違反しているRFCを正確に指摘できますか？

— user1686

@grawity RFC 2396、パート2.4.3を読むと、＃はURIの一部ではないということがわかります。これはRFC 3986では緩和されているようで、何も定義しないほどあいまいです。

— リッチホモルカ

1

@RichHomolka：「foo＃bar」は実際には「URI参照」と呼ばれ、URI（データの取得に使用）とフラグメント（解釈はユーザーエージェントに委ねられています）で構成されています。フラグメントが実際にHTTPリクエストで送信された場合にのみ違反されます。

— user1686

0

それは画像のURLではありません。スクリプトまたはその他のコードを使用して画像を取得するページのURLです。JavaScriptをオフにしてページをロードしてみてください。それがwgetが取得しているものです。

画像のURLを見つけるには、ブラウザでページにアクセスし、写真を右クリックしてください。URLなど、画像に関する情報を表示するオプションが必要です。

それでもうまくいかない場合は、Flashまたはその他のクライアント側プログラムを介して画像が読み込まれている可能性があります。FiddlerまたはWiresharkを使用して、どのURLがロードされているかを見ることができます。

画像を含むサイトの実際のURLを提供していただければ、画像のロード方法を判断するのに役立ちます。

— ジェレミー・スタイン
ソース