rPman

почему youtube замаскирован звездочками? это стало ругательством?

по теме, лучший способ не бороться с мельницами (гугл периодически меняет структуру страницы и устаревший код быстро становится нерабочим) - использовать проект youtube-dl (питон), вызывая его утилиту как внешнюю

точно знаю были врапперы для c# (гугл выдает старый код, может заработает) если надо именно библиотеку

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

скачиваешь sqlite драйвер

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

Когда то давно давно, Когда писал на visual studio c# winform проект, пользовался классами dataset, являющимися по сути таблицами в оперативной памяти, интерфейс чють ли не мышкой пишется весь, при необходимости сохранить данные на диск всему dataset WriteXml а при старте ReadXml, и все сохранялось и загружалось... Я даже никогда внутрь не заглядывал, Когда пишешь крохотное приложение, о котором через пол года даже не вспомнишь за не надобностью, зачем заморачиваться ещё и про базы данных.

Я к тому, что если сериализация в файл, в любом формате, решит твою проблему и не добавит новых, то почему нет.

Этот простой подход позволяет сэкономить время на разработку за счёт очень не эффективного способа хранения данных

Но есть опасность что форматы хранения от разных версий .net framework будут не совместимы.

Что и главное от кого защищаешься? от этого зависит ответ и он будет сильно разный.

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

Этот вариант подходит только для запущенных служб/приложений а не http rest на основе cgi или модулей веб сервера (для них понадобится запустить свою службу, запросы к которой уже будут уязвимы). Метод не даст абсолютной гарантии, так как имея доступ к файлам кода бакэнда провайдер может их проанализировать и вычислить и подменить методику на менее защищенную, в особо запущенных случаях провайдер может и в оперативной памяти машины покопаться, но это особо сложный и дорогой способ, а значит маловероятен.

В момент запуска приложение запрашивает у стороннего сервиса пароль, сторонний сервис его передает, например после ручного подтверждения оператором/владельцем.
Советы
- не использовать типовые технологии и предлагаемые провайдером инструменты, иначе встает вопрос от кого тогда защищаешься то?
- обязательно реализовать ручное подтверждение оператором, администратор знает когда перезапускается веб сервер и если к нему приедет запрос на отсылку пароля в другое время - повод забеспокоиться
- не делать это вопрос ответной системой (типа бакэнд по rpc обращается к удаленному сервису и тот сразу возвращает пароль), так как ее легко вычислить в коде и симулировать вызов, бакэнд запрашивает, но работа сервиса начнется только после того как к нему приедет соответствующий запрос

p.s. пример простой реализации если нужно защитить данные от приглашенного администратора (вариант с заражением им трояном пока опустим, то другими способами фиксится) - все конфиги в открытом виде хранятся в определенном каталоге, по умолчанию там тестовые данные, для проверки работоспособности проекта, а на боевом сервисе или в режиме 'in production' в этот каталог складываются правильные конфиги, например монтированием из encfs, эту операцию делает специальный человек в момент перезапуска сервера вручную.

Само собой правильно - администратор должен не настройкой заниматься, а создавать и настраивать инструменты автоматического развертывания (например образ docker или конфиги ansible), т.е. минимум два человека - один делает всю работу но не имеет доступа к паролям, только тестовые данные, другой только проверяет работу и запускает в бой.

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

Формат csv для данной задачи наиболее неподходящий, теряется информация о структуре, особенно когда на очередной строчке количество колонок меняется и еще страшнее - если не меняется, что там лежит, что в какой колонке - не известно, машина не прочтет а человек обматерит изобретателя этого бреда.

Вторая проблема - денормализация, вот это объединение записей. Причина простая - реляционные базы данных по определению не хранят достаточно информации для понимания, чем является данные. В некоторых случаях можно что то вытащить из типа индексов (fk и pk) и ограничений constraints но в общем нет. Как понимать связь М-1-М? какую таблицу брать за базовую а какую второстепенной, т.е. что выбирать left join, right join или inner join? Да, для простых справочников, когда таблица является лепестком в графе связей 1-М можно 'смело' связывать такую таблицу, дублируя данные справочника по foreign key индексам, но опять - зачем? ведь при чтении уже не будет видно что использовался справочник.

p.s. Я могу предположить что конечная цель у автора - работа со случайными данными (много мелких проектов, написанных разными людьми с сильно оотличающимися подходами к разработке и способам хранения данных) и извлечение из них осмысленных, к примеру в заранее определенном формате
Когда то давно у меня в дипломной или рядом была проект, в котором в качестве доп инструмента была простая самописная утилита, ее натравливаешь на очередную базу с неизвестной структурой, она проводила простенький анализ структуры и выдавала в интерфейсе таблицы поля и показывала короткий брифинг по каждому выбранному полю (тип связи и пример данных там хранящихся), цель утилиты - указать таблицы и поля, из которых дальше будет извлекаться данные (т.е. дать интерпретацию этим данным). Без этой утилиты работа по определению какое поле чем является достаточно муторная, в имеющихся приложениях по работе с бд нужно много кликать, запускать хоть и заранее написанные запросы и т.п. Может вам лучше это состряпать? Я искал и не нашел, готовые универсальные решения слишком сложны (а смысл в простоте интерфейса).

в c# есть унифицированный инструмент по подключению к базам данных - ado.net (вся возня - в построителе connection string, плюс таскать с собой по больше драйверов от разных бд), плюс есть системный odbc (уже устарел но для старых баз данных это иногда единственный способ подключения) для которого есть поддержка ado.net

DIP из SOLID

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

1. имена файлов и пути, а кодировки?
в разных ос разные правила, разные символы разделители, значимость больших/маленьких букв в именах
2. symbolic и hardlink свихнуться можно
это огромная головная боль для любых кто занимается копированием данных, поведение разнится к примеру, попадает ли путь в пределах каталогов, входящих в копию или нет
3. фичи типа sparce files или reflink (этакий hardlink но не для файла а на его сектора)
существуют задачи, в которых не сохранение и учет этих вещей могут невероятно усложнить восстановление данных (например если данные хранятся в дырявых файлах, логически петабайтового размера, в реальности же занимающие на порядки меньше, восстановить да и скопировать без учета этого будет практически нереально)
4. extended attributes
этим мало кто пользуется (но если пользуются то на столько глубоко, что не сделать резервную копию будет фатально), но помнить об этом надо, особенно когда нужно абстрагироваться от их реализации в ОС
5. права доступа
очень мало кто заморачивается с резервированием этой информации, а она зачастую не менее важна чем сами данные, так как иначе, при восстановлении данных со сложной структурой прав и большим количеством пользователей может превратиться в ад, и даже нести опасность утечки важных данных
6. инкрементальное хранение бакапов
это конечно не обязательно, но системы хранения резервных копий без этой фичи неудобны либо слишком дороги
7. работа с сетевыми nas, инструменты выборочного восстановления, поиск данных
Хранить бакапы локально - это фатальная ошибка, значит доступ к хранилищу должен быть удаленный
А еще, вероятность что понадобится восстановить весь бакап на столько низкая, по сравнению с другими сценариями, и заставлять человека извлекать петабайтовые архивы ради мегабайтового файлика, который удалили по ошибки и решили восстановить из бакапа...

p.s. не придумывай сам, спроси своего руководителя, на сколько глубока кроличья нора, так как к примеру все правильно сделать может тянуть на диплом или еще круче.

p.p.s. совет, не изобретай форматы хранения данных, храни все в файлах, пусть контейнером будет сама файловая система (не вздумай файлы хранить к примеру в БД), но вот за имена файлов придется чтобы отвечал кто то другой (вот тут БД), причем не рекомендуется полностью исключать имена файлов и каталогов из архива, достаточно составить список разрешенных символов (общих для большинства ос и основной кодировки) но это может наложить лимит на структуру данных (например в разных ос разный лимит глубины вложенности или длины символов в пути к файлу), тут же храни extended attributes (так же в виде файлов со своими именами)
Все остальное (настройки, структуру инкрементальных бакапов, права доступа, наличие дыр, symlink/hardlik, reflink и т.п.) так же храни в базе данных, может не так удобно как кажется с первого взгляда, но будет легче восстанавливать.

webview.getSettings().setLoadsImagesAutomatically(false);
webview.getSettings().setBlockNetworkImage(true);
это для android а в вопросе .net

Рональд Макдональд все верно написал, дополню:

Страницы, а точнее данные можно передавать по другим протоколам, например ftp, а в локальной сети можно даже открывать по протоколу smb (только windows) или даже локальные файлы (file:///путь_к_html)), но на сколько я знаю для вопросов безопасности, по умолчанию миксить разные режимы, включая https и http запрещается (если стартовая страница http то наверное можно, но скоро все браузеры начнут громко предупреждать что это плохо, пока только сверху намекают)

Данные можно передавать не только штатным http но и с помощью его расширения websocket, в этом случае можно так же слать сообщения наоборот, от клиента к серверу.

Так же есть протокол webrtc, который позволяет вспомогательные данные загружать/передавать не с/на сервер, а с другими пользователями веб сайта p2p, режим не простой (не все одинаково поддерживают по стандарту), блокируется некоторыми неадекватными (к сожалению многими, например мобильными) провайдерами, но он есть и позволяет неплохо экономить на сетевом трафике для тяжелого медиаконтента.

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

p.s. еще есть интересный стандарт data uri, позволяет размещать контент элемента прямо в адресной строке

data:text/html;charset=utf-8;base64,SGVsbG8gPHNjcmlwdD5hbGVydCgnd29ybGQnKTs8L3NjcmlwdD4=

так же это работает для любых элементов на странице, можно даже картинки так вставлять, только не эффективно

p.p.s. совсем добавлю, еще есть протокол chrome:// или moz-extension:// для доступа к элементам расширений браузера, но тут нет стандарта