shurshur

В первую очередь проверить, что на исходном сайте не используется rel=noreferrer.
https://developer.mozilla.org/en-US/docs/Web/HTML/...

Из соображений безопасности открытие ресурсов по внешним ссылкам многие почтовые клиенты и почтовые сервисы не делают вообще. Тем более когда речь явно идёт о картинке размера 1x1, которую могут игнорировать намеренно (лучше уж тогда не указывать размеры, пусть клиент скачает картинку эту 1x1 и узнает размер только после этого).

Надо понимать, что E-mail - это канал с негарантированной доставкой до получателя без шансов проверить факт доставки/прочтения. Письмо может вообще не дойти до получателя, может дойти до "Спама", может дойти но сразу пойти в под нож - но мы об этом не узнаем. Все эти пиксельные картинки, оборачивания ссылок в персонально трекируемые, "запрос подтверждения" - всё эти попытки хоть как-то обойти эти ограничения всё равно ни к чему получателя не обязывают. Получатель может всё это полностью проигнорировать.

Или, как вариант, картинку почтовый сервис получателя может скачать заранее и положить в кэш, что также ничего не означает о получении письма. Её также может скачать антивирус почтового сервиса или получателя, чтобы проверить.

Я всегда принципиально отказываюсь от всех подтверждающих получение действий и фокусов, потому что если отправитель ПОЛЕНИЛСЯ приаттачить все картинки к письму - то значит я посмотрю на его письмо без картинок и по ссылкам переходить не буду вообще. Не заслужил. Ничего ценного в таких письмах я ещё ни разу не видел.

Единственное, для чего все эти средства помогают - примерно оценивать степень прочтения в сравнении с предыдущим опытом. Скажем, вчера письмо прочитало 30% получателей, это может означать что его прочитало, например,на самом деле 60%, но лишь половина подвержена трекингу. А если сегодня прочитало 10%, значит, что-то случилось: письмо хуже дошло до получателей, письмо хуже привлекло их внимание... (Все цифры, конечно, от балды, они имеют иллюстративный характер)

Да и вообще, в наше время почту читает всё меньше людей.

По-моему, тут типичная попытка решить простую задачу дурацким способом.

Пользователь получает сообшение с inline-кнопкой. Вот пусть он эту кнопку и нажмёт, а бот получит в callback_query_handler событие с callback_data и обработает. Зачем ещё какое-то цитирование?

Или тут попытка в кнопке хранить данные, которые при цитировании ещё и якобы можно будет достать? Сама идея дурацкая. Если надо к сообщениям хранить какие-то данные, то их надо хранить в самом боте: в базе данных, в хранилище FSM, да хотя бы in memory в переменных.

Переходим по ссылке: https://wa.me/номер_телефона - получаем чат с контактом - в углу есть трубка для созвона.

Однако в последнее время есть сообщения, что у некоторых пользователей это не работает, и им возвращается сообщение, что данный номер неверен. Но я не смог это воспроизвести. Проверял браузерную версию и клиент WA под андроид. Возможно, это какое-то особое поведение, и возможно оно используется для борьбы со спамерами, использующими нелегально Web API.

Люди всё правильно говорят. Это не тот вопрос, которым следует заниматься способному в лучшем случае к NoCode управленцу. Так-то найти куски кода, который делает что-то, не так сложно. По ключевым словам легко найти практически что угодно на гихабе, хабре, stackoverflow, куче форумов, в документации к конкретным языкам и библиотекам. Сейчас ещё и расплодились агрегаторы кода, которые по ключевым словам выдёргивают фрагменты кода из кучи опенсурсных проектов, иногда бывают полезны, но чаще раздражают....

Но даже если найти кусок кода или название библиотеки (на что уйдёт пять минут) - а что дальше? Чтобы понять, что делает этот кусок кода, какие у него достоинства и недостатки, какие ограничения - это нужна уже компетенция квалифицированного программиста. А вдруг этот код или эта библиотека жалко помрёт, если вместо скромных 100 байт из тестового набора скормить мегабайт осмысленных данных?

Программист намного более эффективно проведёт отбор вариантов (сразу выкинув лишь кажущиеся перспективными, но совершенно бестолковые варианты, делающие не то, что надо, или не так, как это разумно), а затем более квалицифированно разберёт всё, что осталось. Конечно, можно ему сказать "я тут видел XXX и YYY, которые кажутся интересными" (и это не запрещено - почему бы и не сказать?), но программист всё равно сделает этот же поиск с нуля ещё раз и выберет ZZZ, который управленец выкинул при отборе, потому что ошибочно посчитал, что он тут не годится.

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

Средствами Bot API невозможно по username получить id. Серьёзни, никак. Я недавно отвечал на похожий вопрос https://qna.habr.com/q/1224466

Но в указанном узком сценарии возможно сделать такое, но с оговорками.

Во-первых, придётся явно сохранять связку username-id для всех пользователей, пишущих боту.

Во-вторых, не у всех пользователей есть username.

В-третьих, пользователь может в любой момент сменить свой username, и бот об этом не узнает.

По реализации всё достаточно просто: при каждом поступающем сообщении запоминаем пару username-id в базе, а для нужной команды достаём.

Изначально бот мог писать только тем пользователям, которые по своей инициативе первыми написали боту. После одного из обновлений появилось дополнительное правило: бот может писать пользователям, которые подписаны на канал, в котором данный бот числится админом. А также если пользователь перешёл по ссылке-инвайту и оставил заявку на вступление. Если же пользователь покинул канал, то ни одно из этих условий выполняться не будет, и отправка сообщений таким пользователям невозможна никак.

Не надо выкладывать такую длинную простыню, в которой трудно что-либо найти...

Ссылка https://photos.app.goo.gl/6LckVsFKRfKy9ANu6 не является прямой ссылкой на фотографию, да и страница, на которую эта ссылка делает редирект, не является фотографией.

В Bot API невомзожно получить id пользователя по его имени. Возможно только через получение события, с этим пользователем связанное (например, пользователь написал сообщение, пользователь вступил в группу где есть бот, итд). В полученной информации будет и id пользователя, и его username (только если он у пользователя есть).

Это можно обойти использованием клиентского API (библиотеки telethon, pyrogram). Но этот API выполняет запросы от реального пользователя Telegram, поэтому если злоупотреблять запросами, можно получить бан не бота, а прям своего живого аккаунта.

От себя рекомендую этой фигнёй не страдать, у Bot API есть свои понятные сценарии работы, и в рамках них id пользователя можно получить вполне легально именно тогда, когда это имеет смысл в рамках функциональности бота.

Viber Bot (в девичестве Viber Public Account) невозможно добавить в чат. Он может лишь принимать личные входяшие сообщения от пользователей. Да, это сильно меньше, чем позволяет Telegram, но, к сожалению, других возможностей нет.

Такой вопрос надо начинать с предметной области. Какая она? Если это текст с формулами, то ничто другое даже близко не сравнится по удобству.

Корректировка макета страницы в TeX вообще обычно не представляет проблемы, а в упомянутом примере именно это и требовалось. Более того, скилл поиска ответов по вопросам, связанным с TeX, прокачивается достаточно быстро. Есть много списков команд различной степени подробности, куча готовых решений (в том числе поиском на этом сайте и SO), множество всевозможных пакетов в CTAN...

Вообще, TeX умеет безумно сложные вещи, о которых многие даже не подозревают. Например, в знаменитом TeXbook от автора TeX есть пример рисования кривых дракона. Язык TeXа является тьюринг-полным.

Я ввёл в гугле "zpool replace disk in mirror" и получил вагон ссылок по теме, первая же из которых ведёт на официальную документацию на русском языке на сайте Oracle.

Тут сразу несколько ошибок.

Во-первых, класс discord.ext.commands.Bot унаследован от discord.Client - он расширяет возможность последнего функционалом команд. Использовать оба не нужно.

Во-вторых, созданный экземпляр этого класса bot нигде не используется.

В-третьих, в классе discord.Client нет декоратора command - он есть только в commands.Bot.

Ну и наконец оба класса, очевидно, требуют передачи параметра intents, ведь их конструктор в итоге вызовет один и тот же код, который на эти intents ругнётся.

Правильно discord.Client вообще выкинуть - он тут не нужен.

Например, можно автоматически создавать колонки под недостающие параметры по мере анализа. Можно завести словарь, который отображает названия характеристик в номер колонки, если при парсинге страницы обнаружена новая характеристика, которой в словаре нет - добавлять новую запись со следующим номером колонки. При создании новой строчки в выходнойм файле по именам параметров определять их позиции в массиве и подставлять.

Другой вариант: разные категории помещать на разные листы (в случае с csv писать в разные файлы, ну или перейти на xlsxwriter). В этом случае таблица будет не такой разреженной, что в некоторых случаях может быть более удобно удобно.

Набираем locate имя_файла. Если ругается что такой команды нет - ставим то что предлагает (думаю, в кали такой же подсказыватель, как в убунте) - и команда появится. При установке вроде даже должен сразу и базу создать, если нет - запустить updatedb из-под root.

locate ищет не на диске, а в индексе, который обновляется ежедневно из cron. Поэтому свежесозданных файлов он не найдёт. Но зато он ищет очень быстро.