Scrapy, хеш-тег на URL

Question

Я нахожусь в середине проекта по утилизации с использованием Scrapy.

Я понял, что Scrapy вырезает URL из хеш-тега до конца.

Вот вывод из оболочки:

[s]   request    <GET http://www.domain.com/b?ie=UTF8&node=3006339011&ref_=pe_112320_20310580%5C#/ref=sr_nr_p_8_0?rh=n%3A165796011%2Cn%3A%212334086011%2Cn%3A%212334148011%2Cn%3A3006339011%2Cp_8%3A2229010011&bbn=3006339011&ie=UTF8&qid=1309631658&rnid=598357011>
[s]   response   <200 http://www.domain.com/b?ie=UTF8&node=3006339011&ref_=pe_112320_20310580%5C>

Это действительно влияет на мою утилизацию, потому что после нескольких часов попыток выяснить, почему какой-то элемент не был выбран, я понял, что HTML-код, предоставленный длинным URL-адресом, отличается от того, который предоставляется коротким URL-адресом.один.Кроме того, после некоторого наблюдения содержание меняется в некоторых критических частях.

Есть ли способ изменить это поведение, чтобы Scrapy сохранил весь URL?

Спасибо за ваши отзывы и предложения.

Answer 1

---

Это не то, что сама скрапа может измениться - часть, следующая за хешем в URL-адресе, представляет собой идентификатор фрагмента , который используется клиентом (scrapy здесь, обычно браузер).сервера.

Что, вероятно, происходит, когда вы выбираете страницу в браузере, так это то, что страница содержит некоторый JavaScript, который просматривает идентификатор фрагмента, загружает некоторые дополнительные данные через AJAX и обновляет страницу.Вам нужно будет посмотреть, что делает браузер, и посмотреть, сможете ли вы его эмулировать - инструменты разработчика, такие как Firebug или инспектор Chrome или Safari, упростят это.

Например, если вы перейдете к http://twitter.com/also, вы перенаправлены на http://twitter.com/#!/also. Фактический URL, загруженный браузером, это просто http://twitter.com/,, но эта страница затем загружает данные (http://twitter.com/users/show_for_profile.json?screen_name=also), которые используются для создания страницы,и в данном случае это просто данные JSON, которые вы можете проанализировать самостоятельно. Это можно увидеть с помощью Network Inspector в Chrome.

Answer 2

Похоже, это невозможно.Проблема не в ответе, а в запросе, который прерывает URL.

Его можно получить из Javascript - как window.location.hash.Оттуда вы можете отправить его на сервер, например, с помощью Ajax, или закодировать его и поместить в URL-адреса, которые затем можно будет передать на серверную сторону.

Могу ли я прочитатьхэш-часть URL в моем серверном приложении (PHP, Ruby, Python и т. д.)?

Зачем вам эта часть, которая удаляется, если сервер не получаетэто из браузера?Если вы работаете с Amazon - я не видел проблем с такими URL.

Answer 3

На самом деле, при вводе этого URL в веб-браузере, он также будет отправлять только часть до хэш-тега на веб-сервер.Если содержимое отличается, возможно, это связано с тем, что на странице имеется некоторый javascript, который - на основе содержимого части хэш-тега - изменяет содержимое страницы после ее загрузки (скорее всего, XmlHttpRequestсделано для загрузки дополнительного контента).