croot / nekopaw

Automatically exported from code.google.com/p/nekopaw
1 stars 0 forks source link

Не скачиваются изображения с Sankaku #192

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
1. Пытаемся скачать картинки с sankaku по 
любому тегу (удобный тег - png, всего две 
картинки, обе в png-формате)
2. Вытягивается список изображений
2. http://..../<название>.%ext%: HTTP/1.1 404 Not Found

Во-первых, %ext% не заменяется реальным 
расширением файла.
Во-вторых, даже если смотреть прямой URL до 
изображения, который вытащила nekopaw, он все 
равно оказывается неверным. Судя по всему, 
он генерируется из preview_url просто удалением 
/preview, что работает далеко не всегда. Бывает 
так, например, что превью лежит на 
c2.sankakucomplex.com, а оригинал - на cs.sankakucomplex.com. И 
тот, и тот URL указаны внизу странице в 
JSON-блоке внутри JS-скрипта.

nekopaw 2.0.2.107а

Original issue reported on code.google.com by MAYTE.CA...@gmail.com on 8 Feb 2014 at 8:03

GoogleCodeExporter commented 9 years ago
JSON и XML интерфейсы на санках не работают уже 
давным давно. Единсвенное решение, которое 
можно реализовать, это доп. загрузка 
страницы, где находятся подробности о 
изображении. Хотя, я думаю, что будет 
достаточно порсто заменять первую часть 
ссылки на cs.*

Original comment by catgirlfighter on 10 Feb 2014 at 8:54

GoogleCodeExporter commented 9 years ago
Так я и не писал про XML/JSON-интерфейсы. Сейчас 
в nekopaw не работает скачивание и через 
парсинг HTML (либо работает некорректно). Как 
минимум, неправильно определяется прямая 
ссылка до изображения и расширение файла, я 
в первом сообщении же подробно указал. 
Попробуйте скачать все изображения по тегу 
png (их там всего два), сразу станет все 
понятно.

А про JSON я упомянул потому, что внизу 
HTML-страницы есть джаваскрипт-блок вроде 
такого:

<script type="text/javascript">
Post.register({"tags":"...","height":900,"preview_height":150,"preview_url":"htt
p://c2.sankakucomplex.com/data/preview/a9/74/a974276b3e01756aa96074417fb43b07.jp
g","status":"active","parent_id":null,"sample_url":"http://cs.sankakucomplex.com
/data/a9/74/a974276b3e01756aa96074417fb43b07.png?3389684","author":"Kevin2790","
sample_width":849,"sample_height":900,"change":8573281,"width":849,"has_children
":false,"rating":"e","md5":"a974276b3e01756aa96074417fb43b07","score":15,"id":33
89684,"preview_width":141,"file_url":"http://cs.sankakucomplex.com/data/a9/74/a9
74276b3e01756aa96074417fb43b07.png?3389684"});
</script>

Из него удобно выдирать сразу _правильные_ 
прямые ссылки на изображения.

Original comment by MAYTE.CA...@gmail.com on 10 Feb 2014 at 7:45

Attachments:

GoogleCodeExporter commented 9 years ago
>Хотя, я думаю, что будет достаточно порсто 
заменять первую часть ссылки на cs.*
Разные изображения лежат на разных 
серверах (иногда это c3, иногда cs и т.п.), не 
надо делать никаких принудительных замен, 
нужен просто правильный парсинг страниц.

Original comment by MAYTE.CA...@gmail.com on 10 Feb 2014 at 7:47

GoogleCodeExporter commented 9 years ago
Да что ж ты привязался к этому %ext%. Он там 
потому, что раньше никаких js-скриптов не 
было, и расширение приходилось "угадывать" 
(это, внезапно, быстрее, чем парсить 
отдельную страницу с картинкой). Т.к. он в 
итоге так и не может его угадать, он 
оставляет %ext%.
Очевидно, что он не может угадать сервер, 
т.к. раньше было достаточно убрать /preview/ 
чтобы получить ссылку. Быстро взять и 
исправить проблему на санках я не могу, т.к. 
js-script парсер парсить не умеет. Можно, 
конечно, добавить парс страницы с пикчей, 
но это определенно будет не сабый быстрый 
способ скачки страниц (особенно с учетом 
того, что санки имеют привычку подставлять 
плашки если ты качаешь слишком много).

Original comment by catgirlfighter on 11 Feb 2014 at 8:11

GoogleCodeExporter commented 9 years ago
Я что ли так плохо все объясняю.

Переходим вот сюда: 
http://chan.sankakucomplex.com/?tags=png&commit=Search
Внизу страницы кусок джаваскрипта, в 
котором указаны прямые ссылки _до всех_ 
изображений. 
То есть, не надо парсить отдельно страницу 
с каждой картинкой, не надо делать никаких 
замен подстрочек, не надо угадывать 
расширение.

Достаточно регуляркой спарсить @"file_url":".+"@

Original comment by MAYTE.CA...@gmail.com on 11 Feb 2014 at 10:26

GoogleCodeExporter commented 9 years ago
В два захода благополучно выкачал 785 пикч 
просто заменяя начало ссылки на cs (в первом 
заходе была куча таймаутов, что вполне 
нормально для санок). Пока оставлю этот 
вариант (т.к. его просто реализовать, в 
отличии от "нормального" способа).

Если все-таки найдутся ссылки, которые не 
могут быть скачаны с cs.*, то оставляй их в 
этом задании, чтобы быть уверенным.

ЗЫ: не все 404 - на самом деле 404. "Подбор" 
расширения происходит путем замены 
расширения при возникновении ошибки, т.е. 
если это будет таймаут, то это тоже 
приведет к смене расширения, а последняя 404 
- это ошибка, возникающая при попытке 
скачать с самым последнем (в нашем случае 
swf) расширением. Надо будет подкрутить 
проверку, чтобы ошибки определялись более 
точно. Т.е. как минимум попробуй скачать 
пикчу еще раз, или проверь ее в браузере, 
подобрав расширение самостоятельно.

Я тем временем пока подумаю, как можно 
сделать вариант получше.

---
Да понял я, что внизу кусок яваскрипта. 
Чтобы "проверить регуляркой" этот кусок 
яваскрипта нужно в скриптовом механизме 
добавить возможность эти регулярки 
применять. Nekopaw уже давно не с 
захардкодиными скриптами работает, и уж 
очевидно не на регулярках.

Original comment by catgirlfighter on 11 Feb 2014 at 10:39

GoogleCodeExporter commented 9 years ago
Почему не используешь HEAD вместо GET при 
подборе расширения? Это было бы быстрее и 
удобнее.
>уж очевидно не на регулярках
Понятно, что в общем случае парсить HTML 
регулярками - это бред. Но корневая функция 
nekopaw - это граббинг ссылок, и очень странно, 
что еще нет поддержки регулярных выражений.
>Nekopaw уже давно не с захардкодиными 
скриптами работает
Еще бы доки написал по внутреннему 
скриптовому языку, пользователи бы стали 
фиксы делать.

Original comment by MAYTE.CA...@gmail.com on 11 Feb 2014 at 12:32

GoogleCodeExporter commented 9 years ago
>Почему не используешь HEAD вместо GET при 
подборе расширения? Это было бы быстрее и 
удобнее.
Не быстрее (возврат ошибки 403, 404 или read timeout 
всегда занимает одно и то же время), не 
удобнее (т.к. разница лишь только в том, что 
в исходнике будет написано вместо GET - HEAD). 
Если ты имеешь ввиду получать расширение 
во время получения ссылки, то это лишь 
лишняя нагрузка на сервер, т.к. есть 
вероятность, что ты не станешь качать эту 
ссылку, так что выгоднее получать 
расширение уже во время скачки.

> Но корневая функция nekopaw - это граббинг 
ссылок, и очень странно, что еще нет 
поддержки регулярных выражений.
Получение ссылок в текущем варианте 
происходит тем же способом, как и всех 
остальных данных. Т.е. реализация регулярок 
просто стала не нужна. "Все остальные" 
данные доверить регуляркам нельзя [Parsing Html 
The Cthulhu Way].
Фактически, это первый случай, когда 
регулярки потребовались.

Original comment by catgirlfighter on 11 Feb 2014 at 12:53

GoogleCodeExporter commented 9 years ago
>Еще бы доки написал по внутреннему 
скриптовому языку, пользователи бы стали 
фиксы делать.

В планах уже давным давно, но писать 
документацию еще ленивее чем кодить.

Original comment by catgirlfighter on 11 Feb 2014 at 12:56

GoogleCodeExporter commented 9 years ago
>возврат ошибки 403, 404 или read timeout всегда 
занимает одно и то же время
>в исходнике будет написано вместо GET - HEAD
Зато в ответе будут только заголовки, а не 
все содержание страницы с 404 ошибкой. Кроме 
того, что не надо получать лишнюю 
информацию, сам сервер HEAD отдаст быстрее, 
чем полный GET (особенно на каких-нибудь 
медленных серверах). 
Вообще можно делать HEAD, получать строчку 
HTTP-ответа (до первого CRLF) и дальше обрывать 
соединение.

Original comment by MAYTE.CA...@gmail.com on 11 Feb 2014 at 2:16

GoogleCodeExporter commented 9 years ago
%original_name%, кстати, не работает на санках (так 
в название файла и идет).

Original comment by MAYTE.CA...@gmail.com on 11 Feb 2014 at 2:31

GoogleCodeExporter commented 9 years ago
>Зато в ответе будут только заголовки, а не 
все содержание страницы с 404 ошибкой.
Добавлю на заметку, такая реализация будет 
немного "правильнее". Хотя "на глаз" все 
равно ничего не изменится. Еще интересно 
будет узнать, как на это отреагируют санки, 
позволят ли они мне в течении секунды 
перебрать все форматы, или тоже потребует 
ставить паузу между запросами. В этом 
случае все преимущества HEAD уйдут в трубу.

Поле %original_name% есть только в ex\g.e-hentai, только 
с ним и работает.

%% - это поля, для каждого ресурса они могут 
быть (и чаще всего) свои. Очевидно, ресурсы, 
шарящие движки, скорее всего будут иметь 
одинаковые поля (подразумевается, что 
однотипные поля будут иметь одинаковые 
названия).

Original comment by catgirlfighter on 11 Feb 2014 at 2:57

GoogleCodeExporter commented 9 years ago

Original comment by catgirlfighter on 2 Apr 2014 at 11:59