Неправильно, плоскость континуальна, как и каждая планета. Так что к вопросу ответ, конечно, что множества равномощны, но как континуумы, а не счётные.
16-битный код может исполняться 32-битным x86-процессором, поэтому тут как раз не особо проблема. Больше проблем будет вызывать этот код из своего 32-битного (например, нужно будет явно использовать 16-битные регистры и смещения) и переписать под диалект своего ассемблерного компилятора. А вообще при таком объёме может быть проще переписать с нуля, тем более что код не выглядит каким-то страшно сложным.
А, заметил что там extrn-функция есть dos3call, вероятно это прерывание DOS 21h. Увы, тогда нет, без DOS этот код нельзя использовать. Или надо понять какие функции DOS он использует и реализовать их аналоги у себя.
Сергей, такие вещи лучше оформлять комментарием к исходному вопросу, а не отдельным ответом. А ещё лучше выкладывать через сайты типа pastebin.com или gist.github.com.
aleksandr_twitt, функция в Python тоже переменная. Например, есть встроенная функция id, но можно создать переменную id, и функцию id больше нельзя будет использовать.
... Хотя, на самом деле можно. Если заранее присвоить её другой переменной. Для улучшения понимания вот поигрался с функцией id:
Ailteres1, есть очень много способов не дать скачать файлы мимо браузера.
Первый и самый простой (но часто применяющийся и довольно эффективный против самых неискушённых пользователей) - проверка Referer. Когда пользователь скачивает файл браузером, тот подставляет в заголовок Referer адрес страницы. При скачивании можно проверить, что Referer указан и содержит родной домен сайта (а то может и что в нём конкретная страница, чтобы нельзя было наивно передавать главную страницу сайта во все запросы), и в случае отсутствия/неверности выдавать 403 вместо файла. Это также помогает от "хотлинков" - прямых ссылок с чужого сайта на свои файлы - что позволяет чужие файлы отдавать с левого сайта под видом своих собственных.
Развитием этого способа является проверка и других заголовков. В частности, User-Agent программ-качалок часто выдаёт их, что позволяет легко закрыть простой доступ для curl и wget (да, им можно переопределить User-Agent, но неискушённый пользователь и тут может не разобраться). Или можно проверять наличие каких-нибудь Accept-Language, который современные браузеры обычно выставляют, а качалки - нет.
Далее, можно использовать куки. Тогда без посещения сайта из браузера куки не будут выставлены. Конечно, их можно протащить в файлокачалку, но тоже не всякий справится. До кучи можно сверять заголовки: если с теми же куками придёт пользователь с другим User-Agent - это уже признак того, что он больше не использует предыдущий браузер.
И наконец можно выдавать пользователю индивидуальные ссылки, привязанные к его IP и/или кукам, возможно имеющие срок жизни и криптографическую подпись. Если ссылки на файлы имеют вид навроде filename.png?expires=1675719469&ip=111.111.111.111&hash=43c2a45a - то это как раз такой случай.
Это основы, на деле владелец сайта может комбинировать эти подходы или придумывать новые хитрости. В частности, он может считать количество файлов, отданных конкретному пользователю, и блокировать его на сутки при превышении некоего естественного лимита.
Вова, общее решение малореально, так как реализации у всех очень разные. У кого-то подгрузка через ajax, у кого-то в ссылку передаётся номер страницы, у кого-то ещё и размер страницы может настраиваться. Плюс может быть так, что, например, число страниц в принципе ограниченно (пример: nyaa.si принципиально показывает не больше 100 страниц по любому запросу или фильтру).
Также и полученный контент страницы надо парсить индивидуально. Например, там может быть блок рекомендаций, рекламный блок и блок основного контента, оформленные одинаковыми или похожими тэгами. И всё это надо индивидуально учитывать.
Я довольно много всяких разных парсеров писал. Пагинаторы очень разные бывают. Некоторые показывают общее число страниц, некоторые нет (тогда приходится идти по страницам вслепую). У кого-то нумерация с 0, у кого-то с 1. Где-то страница отдаётся по номеру, где-то - по смещению. Бывает так, что первая страница отдаётся в теле, а последующие отдаются ajax, причём в ответе может быть как кусок html для вставки в страницу, так и структурированные данные в json/xml/txt/ещёкакомнитьвиде. Могут быть вставки каких-нибудь странных вещей типа вопроса "а вам действительно 18+ лет для показа последующего контента?" Ещё можно встретить сайты с вебсокетами.
А ещё сайты бывают просто овербольшими. Уверяю, скачать 10000 страниц в один файл это не только медленно, но и неудобно.
У меня налажен подход с готовыми функциями, которые кладут все файлы в кэш, умеют delay между запросами или expiration по времени файла. Парсить сайты с тысячами страниц (иногда ещё и тормознутые) намного удобнее, если не перекачивать уже накопленные данные. Вот, например, у меня тут кэш одного книжного сайта - 72 тыс. файлов.
И как я уже говорил, многие сайты вяло или активно борются с качальщиками. Поэтому приходится с каждым разбираться отдельно. Кому-то достаточно полусекундные задержки, кому-то надо куки из браузера, а кому-то решать капчу каждые 1000 запросов...
KPoseidon, разумеется, я читаю и вижу слово БОТ, а тут регулярно спрашивают, почему БОТ не может получить список подписчиков через БОТ API. Пользователь с собственным клиентским приложением - это не БОТ.
Ну а так вообще надо читать документацию. Мне никогда не нужно было дампить подписчиков, поэтому я не вникал в особенности этого процесса.
И надо не забывать, что канал в Телеграме существенно отличается от группы, работать с ними одинаково часто неверно.
Вова, с другой стороны немного странно, я вроде раньше набредал на книги которые на livelib.ru были выложены с текстом, а сейчас куда ни ткнёшь - там везде "бумажная". И непонятно, есть ли там вообще тексты хоть каких-то книг?
Вова, добро пожаловать в дивный мир парсинга! Где сайты обклеены js, капчами, поведенческим анализом, запросными лимитами итд итп. Готового, конечно же, чаще всего нигде нет, ну кроме как у кого-то где-то по секрету без публичного доступа.
Тут есть два базовых подхода:
1. Изучить, какие запросы делаются при навигации по сайту, и воспроизводить их. Лучший способ с точки зрения скорости, но слишком уж легко детектится и слишком часто ломается при мельчайших изменениях в сайте.
2. Использовать полноценный браузер с автоматизацией работы через Selenium. Более надёжно, но запущенный браузер сожрёт дополнительной памяти. И тоже в принципе может детектиться (но сложнее и есть всякие методы обмана).
Также на многих сайтах придётся бороться с капчами и банами, как собственными сайтовыми, так и Cloudflare/DDOS-Guard/итд. Прыгать с бубном с пачками прокси...
Гугл - советую отказаться от парсинга сразу. Этих парсить любят так сильно, что они защитами обвешаны по самые уши. Нет смысла даже возиться.
Вот livelib.ru может оказаться перспективнее, поскольку не так крут, как гугл. Правда, я не очень понимаю, какой толк парсить книжный магазин. Я парсил книжные сайты, где выложены тексты книг, это поинтереснее будет...
Если речь об общем ключе шифрования, то он генерируется по алгоритму DH обеими сторонами независимо от того, используется ли авторизация по клиентскому сертификату или нет.
Вообще-то это не так делается. Пуши работают даже когда приложение на телефоне не запущено. Реализация может быть как раз с помощью firebase.
Приложение на телефоне постоянно запущенное - это костыль. Тем более что фоновые телефонные приложения по определению могут быть закрыты в любой момент, если понадобятся ресурсы.
Разработка на python для телефона в теории возможна. В теории. Но это неудобно и неэффективно. Если это попытка сделать что-то посерьёзнее "себе на поиграться", то лучше отказаться сразу.
