Closed GoogleCodeExporter closed 9 years ago
JSON и XML интерфейсы на санках не работают уже
давным давно. Единсвенное решение, которое
можно реализовать, это доп. загрузка
страницы, где находятся подробности о
изображении. Хотя, я думаю, что будет
достаточно порсто заменять первую часть
ссылки на cs.*
Original comment by catgirlfighter
on 10 Feb 2014 at 8:54
Так я и не писал про 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:
>Хотя, я думаю, что будет достаточно порсто
заменять первую часть ссылки на cs.*
Разные изображения лежат на разных
серверах (иногда это c3, иногда cs и т.п.), не
надо делать никаких принудительных замен,
нужен просто правильный парсинг страниц.
Original comment by MAYTE.CA...@gmail.com
on 10 Feb 2014 at 7:47
Да что ж ты привязался к этому %ext%. Он там
потому, что раньше никаких js-скриптов не
было, и расширение приходилось "угадывать"
(это, внезапно, быстрее, чем парсить
отдельную страницу с картинкой). Т.к. он в
итоге так и не может его угадать, он
оставляет %ext%.
Очевидно, что он не может угадать сервер,
т.к. раньше было достаточно убрать /preview/
чтобы получить ссылку. Быстро взять и
исправить проблему на санках я не могу, т.к.
js-script парсер парсить не умеет. Можно,
конечно, добавить парс страницы с пикчей,
но это определенно будет не сабый быстрый
способ скачки страниц (особенно с учетом
того, что санки имеют привычку подставлять
плашки если ты качаешь слишком много).
Original comment by catgirlfighter
on 11 Feb 2014 at 8:11
Я что ли так плохо все объясняю.
Переходим вот сюда:
http://chan.sankakucomplex.com/?tags=png&commit=Search
Внизу страницы кусок джаваскрипта, в
котором указаны прямые ссылки _до всех_
изображений.
То есть, не надо парсить отдельно страницу
с каждой картинкой, не надо делать никаких
замен подстрочек, не надо угадывать
расширение.
Достаточно регуляркой спарсить @"file_url":".+"@
Original comment by MAYTE.CA...@gmail.com
on 11 Feb 2014 at 10:26
В два захода благополучно выкачал 785 пикч
просто заменяя начало ссылки на cs (в первом
заходе была куча таймаутов, что вполне
нормально для санок). Пока оставлю этот
вариант (т.к. его просто реализовать, в
отличии от "нормального" способа).
Если все-таки найдутся ссылки, которые не
могут быть скачаны с cs.*, то оставляй их в
этом задании, чтобы быть уверенным.
ЗЫ: не все 404 - на самом деле 404. "Подбор"
расширения происходит путем замены
расширения при возникновении ошибки, т.е.
если это будет таймаут, то это тоже
приведет к смене расширения, а последняя 404
- это ошибка, возникающая при попытке
скачать с самым последнем (в нашем случае
swf) расширением. Надо будет подкрутить
проверку, чтобы ошибки определялись более
точно. Т.е. как минимум попробуй скачать
пикчу еще раз, или проверь ее в браузере,
подобрав расширение самостоятельно.
Я тем временем пока подумаю, как можно
сделать вариант получше.
---
Да понял я, что внизу кусок яваскрипта.
Чтобы "проверить регуляркой" этот кусок
яваскрипта нужно в скриптовом механизме
добавить возможность эти регулярки
применять. Nekopaw уже давно не с
захардкодиными скриптами работает, и уж
очевидно не на регулярках.
Original comment by catgirlfighter
on 11 Feb 2014 at 10:39
Почему не используешь HEAD вместо GET при
подборе расширения? Это было бы быстрее и
удобнее.
>уж очевидно не на регулярках
Понятно, что в общем случае парсить HTML
регулярками - это бред. Но корневая функция
nekopaw - это граббинг ссылок, и очень странно,
что еще нет поддержки регулярных выражений.
>Nekopaw уже давно не с захардкодиными
скриптами работает
Еще бы доки написал по внутреннему
скриптовому языку, пользователи бы стали
фиксы делать.
Original comment by MAYTE.CA...@gmail.com
on 11 Feb 2014 at 12:32
>Почему не используешь 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
>Еще бы доки написал по внутреннему
скриптовому языку, пользователи бы стали
фиксы делать.
В планах уже давным давно, но писать
документацию еще ленивее чем кодить.
Original comment by catgirlfighter
on 11 Feb 2014 at 12:56
>возврат ошибки 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
%original_name%, кстати, не работает на санках (так
в название файла и идет).
Original comment by MAYTE.CA...@gmail.com
on 11 Feb 2014 at 2:31
>Зато в ответе будут только заголовки, а не
все содержание страницы с 404 ошибкой.
Добавлю на заметку, такая реализация будет
немного "правильнее". Хотя "на глаз" все
равно ничего не изменится. Еще интересно
будет узнать, как на это отреагируют санки,
позволят ли они мне в течении секунды
перебрать все форматы, или тоже потребует
ставить паузу между запросами. В этом
случае все преимущества HEAD уйдут в трубу.
Поле %original_name% есть только в ex\g.e-hentai, только
с ним и работает.
%% - это поля, для каждого ресурса они могут
быть (и чаще всего) свои. Очевидно, ресурсы,
шарящие движки, скорее всего будут иметь
одинаковые поля (подразумевается, что
однотипные поля будут иметь одинаковые
названия).
Original comment by catgirlfighter
on 11 Feb 2014 at 2:57
Original comment by catgirlfighter
on 2 Apr 2014 at 11:59
Original issue reported on code.google.com by
MAYTE.CA...@gmail.com
on 8 Feb 2014 at 8:03