mayton2019

Как определить зашифрована ли строка с помощью функции openssl_encrypt или не зашифрована?

Такого метода вобщем-то нету. Но если openssl_encrypt возвращает строку в кодировке base64 - то эта строка будет
иметь характерный "хвостик" в виде символов равно (padding) для добивания строки кратного байтам размера.
И все прочие символы имеют равномерное (шумящее) распределение.

Но если я прикольнулся и изначально положил в openssl_encrypt такую подобную вышеуказанной, то тогда
нет возможности определить была она зашифрована, или я просто прикольнулся.

Разбей строку по амперсандам. А потом - по знаку равно.

Да. Ты правильно выбрал преобразование Хафа для кругов (окружностей). Только у тебя должен
быть pipeline из последовательного применения фильтров.

1) Сначала обесцветить картинку.
2) Применить фильтр границ. На этом этапе круги появятся
3) Ты заранее знаешь диаметр круга - желательно его вбить в настройки чтоб Хаф не искал все-все радиусы
которые возможны.
4) Ну и далее - твой метод должен их найти.

Найти посредника. Пообщать ему процент.

Возьми еще штук 10 SD-шек.

Если ты пошел по пути физика-экспериментатора - то эксперимент должен воспроизводиться и в статистике
показать что ты прав.

Также у тебя не должно быть системной ошибки. Может они горят по другой причине.

Так вроде лучше

for (int i = 0; i < 10; i++) {
        cout << i << endl;
}

Вопрос наверное распадается на несколько направлений. GSM/CDMA/3g e.t.c.
В зависимости от стандарта связи или протокола там будут разные свойства.

Наверное если вопрос стоит о сертификации - то да. Я думаю что можно 100% отвечать
уверенно. Щас ни один современный стандарт связи не идет без encryption. Это что-то
уж очень древнее вроде "пейджнговой" связи или "телекса" могли пулять в эфир открытые тексты.

Другое дело что лично вам с этого никакой пользы нет. Спецслужбы слушают на том
уровне стека где этот траф обычно уже расшифрован.

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

20 лет назад этот вопрос был полнонстью решен с помощью технологий XML/XSLT/XPath.
Языки C#/dotNet, Java поддерживают этот стек. И много других языков и библиотек.

Потом еще создавали более простые вещи. Шаблонизаторы. Velocity, FreeMarker. Они немножко
переворачивают постановку. Но их тоже можно рассмотреть.

Хранить html код в столбце поста кажется нецелесообразным.

С точки зрения суммарной стоимости владения (TCO) база данных всегда будет дороже
чем файловая система. А самым дешевым будут хранилища типа Amazon S3, MS Blob, G-Drive.
Ну если пересчитать удельно сколько стоит гигабайт.

Хранить каждый элемент поста отдельно в бд со следующим содержанием (element_name, position, content, post_id),

Тут - непонятно. Но есть такое эвристическое правило дизайна
хороших NoSQL систем. Все данные для запроса должны лежать физически рядышком
и не требовать дополнительных действий. В идеале - для отдачи поста вы должны сделать
один единсвтвенный SELECT без joins и без подзапросов и агрегаций и без CONNECT-BY.

Почитай по ключевому слову - Кластеризация.

диоды мигают в хаотичном порядке, как-будто перепутаны все жилы.

Чепуха какая-то. Какие выводы мы здесь должны сделать из хаотичного мигания?

Я вот так рассуждаю. Когда ничего непонятно - инженер должен отбросить сложные инструменты - и
взять простые. Бери мультиметр и проверяй целостность жил. И сопротивление изоляции между жил.

Свич убери вообще чтоб не мешал. Закольцуй кабель в кольцо чтоб было удобно мерять.

Ну я когда учил - группировал слова по тематике. Например спорт, природа, путешествия.
С какого на какой язык делать vocab - не имеет значения. Но важно слово тут-же начать применять.
Некоторые слова я разбирал на их составные части. Напрмер Pine-apple. Water-melon.
Если ты используешь карточки - то можно на них рисовать скетчи и это тоже помогает заучивать.

Некоторые слова включаются в устойчивые выражения и только в них и существуют.
Их надо знать в контексте. (do the washing up, carry on, eat out).

У меня вот со временами (tense) проблема. Все что past tense я просто заучиваю. Потому что базовая
формула из учебников просто для меня не работает в разговорной речи. Я - торможу и не успеваю
сформулировать мысль. Вот как-то так.

72 в десятой степени будет 3 743 906 242 624 487 424

Вот такое число. В физических величинах это будет ... эээ 3 квинтиллиона с хвостиком.

Эта задачка не на регулярки а на программирование. Если у вас есть список этих URL в виде CSV, то надо брать язык который вы знаете (PHP или Node) и писать логику нормализации. А потом унификации. Например.

Input:

habr.ru
habr.ru/test.htm
https://habr.ru
habr.ru/yyy
www.habr.ru
https://habr.ru

нормализуем. Отбрасываем например название протокола

habr.ru
habr.ru/test.htm
habr.ru
habr.ru/yyy
www.habr.ru
habr.ru

Сортируем

habr.ru
habr.ru
habr.ru
habr.ru/test.htm
habr.ru/yyy
www.habr.ru

И вот они дубли 3 штуки. Можете итератором пройти и собрать. Или сделать agg/count в языке где
такое с коллекциями делают.

И никаких регулярок.

В 2000х годах хакеры, используя метод радужных таблиц (rainbow tables) научились находить пароль по известному хешу
за вполне короткое время если обладали заранее расчитанной базой этих таблиц. И если они знали
какая хеш-функция работала. Особенно для Windows NTLM у них ловко выходило. И при условии
что пароль был корткий. До 8 символов например. Для большего пароля база росла экспоненциально.

Противостоять этому методу можно было легко. Для каждой единицы программного обеспечения
нужно было создать соль (salt) и на уровне алгоритма и добавлять ее к паролям везде. Логику алгоритма
аутентификации это вообще не меняло но зато отбрасывало злоумышленников во времени намного назад.

Теперь стандартные наборы таблиц не работали. Им нужно для вашего софта персонально генерить свой сет
таблиц. Даже на видеокартах этот процесс очень долгий и сами таблички занимают много гигабайт. Короче
никому это было не нужно и salt является надежным убийцей радуги.

В криптографии есть аналогия с вектором инициализации IV для симметричных шифров.

В процессе обучения сигмоид очень важен т.к. он обеспечивает сходимость алгоритма. Направление грубо говоря.

Насчет рабочего режима модели я не скажу. Но вроде-как нейросети очень толерантны к элементной базе. В 20м веке считалось что нейроны вообще нужно строить не на софте а в виде транзисторной логики. Или на биологических элементах (уж каких я не знаю).

Практически если у тебя уже есть софт и модель то замена одно функции на другую в коде это дело одной
минуты. Лямбду заменить. Или еще один класс унаследовать.