Вот интересно. Мы живем в эпоху нейросетей дипфейков и всяких там co-pilot которые чуть ли не за тебя код пишут. А вот старая бородатая задача такая как парсинг адресов осталась до сих пор нерешённой. Честное слово где там знаменитые проблемы Гильберта? Ну да ладно. Ворчу я.
Вот тут Респ - это республика. Сокращение тоесть. А могло-бы быть и Рес. И Респуб. Короче вы поняли. Fuzzy.
Я-бы предложил скачать все справочники ФИАС. Проиндексировать их триграммами и также построить соответствие для данного адреса. После такой процедуры мы сможем нечётко тегнуть какие элементы могут быть (!) взяты из какого справочника.
Далее обратите внимание что Завьяловский может быть и городом и еще бох знает чем. Но упускать такой кейс нельзя ибо взято из справочника гордов.
Дальше - матчинг. Мы заполняем то что есть. И отбрасываем противоречия. Почему мой подход лучше? Потому что он не завязан строго на порядок элементов в адресе. Вот в США например адрес пишут ровно наоборот. Тоесть практики разные бывают. И адресная строка вообще никак не формализуется. А что касается квартал-дом-строение-корпус-дробь-квартира - ойойой там конь не валялся. Эту сущность я-бы оставил как есть.
Это одна из фундаментальных проблем криптографии и криптоанализа.
Чтобы подделать нужно знать алгоритм и ключ. Алгоритмы обычно известны.
AES, Blowfish e.t.c. Их можно перебрать. С вариациями длины ключа там будет
несколько сотен. С ключом сложнее. Современная инфо-безопасность требует
ключи до 256 бит. Поэтому их даже в цикле перебрать невозможно. Получается
астрономически большое число итераций.
Несколько мыслей. Насколько я помню zip-формат ничего не знает о многотомных архивах. И видео-файлы обычно не архивируются. Тоесть пользы от упаковки их в архив обычно никакой.
Не советую читать Кнута. Вы просто зря потеряете время. Если нужно быстро понять базовые алгоритмы сортировки и поиска - то лучше Никлаус Вирт или Седжвик. Кнут слишком нуден и растягивает на 4 тома то что можно выложить в брошюре. Говорю с позиции практика так как мне Кнут и его выдумки не пригодились. Говорю выдумки потому что Кнут все четыре тома вас будет грузить исходниками на виртуальном процессоре MMIX которого не существует в природе. А зачем вам это душное душнилово?
Вот Седжвик есть в вариациях на Java/C++/C. Берите его. У Вирта - Паскаль что тоже вобщем хорошо для изучения.
Вообще сомнительно что это хоть где-то кроме Google Colab можно поднимать.
Тут и более простые задачи lambdas требуют кардинального переписывания при переходе с AWS на GCP.
А вы говорите - модель.
Тут скорее всего не формат важен а стратегия в целом. Как бэкапируется и где хранится.
Например для Моих Документов может быть один подход (архивом bzip2) а для фолдера
с фильмами по другому (rzync). Это обеспечит и скорость и управляемость хозяйством.
Полностью поддерживаю Сергея с правилом 3-2-1.
Если у вас будут ошибки или физические повреждения носителя то вам не особо поможет Fat/ExFat.
Главным вопросом будет - "где вторая копия" ? А кустарные методы восстановления - мы опустим.
Слишком это всё спорно и без гарантий.
очень резко сужает наши возможности. И мы никак не сможем это требование
обеспечить если будем вульгарно прыгать с одного компиллятора на другой (MinGW)
или спорить о С++ или C.
Я думаю Александр полностью ответил на вопрос. Стандартное средство - wget. И оно работает для 80% сайтов. Должно работать.
Другое дело что современные сайты из всех сил сопротивляются скачиванию. И поэтому для них
очень трудно искать какой-то стандартный подход. Задача еще осложняется анти-капчей и прочими
вопросами которые просто wget не решает.
Если например смотреть в сторону Селениума и прочих браузеров которые эмулируют полноценную интеракцию - то даже они требуют ручной доводки и конфигурирования. И это уж точно никак не пользователский подход. Это скорее какая-то разработка.
Вобщем я кликаю что решение вопроса есть. И можно дальше ничего и не искать.
zilevsky, некоторые небольшие кусочки бинарных данных (токены, ключи, сертификаты) хранят в базе в виде строк в кодировке Base64 или BinHex. Это удобно. Они обычно не больше 4к. И есть удобство кидать их через клипборд во время разработки и тестирования.
Но если данные большие и будет нагрузка (много пользователей захотят читать много документов) - то надо хранить в дисковых хранилищах. А в базе просто класть Url на файлик который лежит где-то там.
Вообще база с точки зрения суммарной стоимости владения - всегда дороже чем дисковое хранилище. Базу надо беречь и не пихать в нее нереляционные данные. Исторически базы были созданы для хранения коротких строчек и чисел. И если в них класть блобы - то таблица всегда деградирует по производительности. И бэкапы становятся безумно долгие и малополезные.
Автор загрузись с загрузочной флешки Ubuntu. И сделай такую команду.
nmcli dev wifi
Вот что она покажет - будем считать исходными данными. У тебя-ж тема - сетевое администрирование а не Windows. Вот давай сетями заниматься.