Изтегляне на HTML през прокси преди анализ с Html Agility Pack
Съчетайте конфигуриран през прокси HttpClient с Html Agility Pack, като държите мрежовите грешки отделно от анализа на HTML.
using var handler = new HttpClientHandler
{
UseProxy = true,
Proxy = new WebProxy("http://proxy.example:8080")
};
using var client = new HttpClient(handler);
string html = await client.GetStringAsync(
"https://www.example.com/catalog");
var document = new HtmlAgilityPack.HtmlDocument();
document.LoadHtml(html);Този модерен .NET фрагмент използва System.Net и System.Net.Http. Конфигурираният клиент управлява мрежовото маршрутизиране, а Html Agility Pack получава върнатия HTML низ. Запазете подходящо конфигуриран клиент за текуща работа, вместо да пресъздавате неговите пулове за всяка страница.
За този пример с публична страница неудостоверен кандидат от списъка с HTTP проксита може да замени посредника. Сменете дестинацията отделно. URL адресът на сайта запазва своята TLS идентичност. Удостоверените прокси данни за достъп принадлежат на WebProxy; нито данните за достъп на сайта, нито изключената проверка ги заместват.
GetStringAsync третира неуспешните HTTP статуси като грешки. Не превръщайте неуспешното изтегляне в празен HtmlDocument. Ако приложението се нуждае от заглавки, подробности за статуса или тяло на грешка, използвайте HTTP операция, ориентирана към отговора, и я прегледайте преди анализа.
Методът за низ избягва безусловно допълнително преобразуване на сурови байтове в UTF-8. Ако изтегляте байтове умишлено, пренесете изискванията за кодиране на отговора и документа към декодирането.
LoadHtml създава анализиран документ; той не изпълнява скриптове, не зарежда стилове и не следва връзки. Разрешавайте следващите относителни връзки спрямо местоположението на отговора и помнете, че елементите, изобразени от браузъра, може да липсват в изтегления изходен код. Всеки отговор трябва да създава свой собствен документ, дори когато заявките споделят един и същ конфигуриран HTTP клиент.