Wybór biblioteki C# do konwersji HTML na PDF w 2026 roku sprowadza się do jednej decyzji: który silnik renderujący pasuje do dokumentów, które faktycznie tworzysz. Na .NET 10 pole dzieli się na trzy grupy. Silniki oparte na przeglądarce (Chromium przez PuppeteerSharp,Playwrightlub wbudowana wersja) dokładnie renderują nowoczesny CSS i JavaScript. Biblioteki programistyczne (iText, PdfSharp) tworzą pliki PDF z niestandardowych analizatorów i wymieniają nowoczesną wierność względem sieci na niewielki rozmiar. Narzędzia do układów z kodu (QuestPDF) całkowicie pomijają HTML. To porównanie przedstawia każdą opcję z działającym kodem C#, kryterium oceny, oryginalnymi testami wydajności i warunkami licencji, które decydują o tym, co możesz wysyłać.

TL;DR: krótka odpowiedź i najszybciej działający kod

Aby dokładnie renderować obecny CSS i JavaScript, użyj silnika jakości przeglądarki. Darmową opcją jestPuppeteerSharplub Playwright, które dostarczają wyjście o jakości Chrome, ale wymagają zarządzania oddzielnym procesem przeglądarki i dużym binarnym plikiem. Komercyjna opcja osadza Chromium w pakiecie, nie pozostawiając nic do zainstalowania lub uruchomienia oddzielnie. Dla prostych statycznych dokumentów wystarczy lekka biblioteka taka jak PdfSharp. Dla układów zdefiniowanych kodem bez źródła HTML,QuestPDFto najkrótsza droga.

Najszybsza ścieżka pracy do PDF za pomocą wbudowanego silnika to jedno wywołanie renderowania:

using IronPdf;

// The embedded Chromium engine ships inside the package, so no browser is launched or downloaded
var renderer = new ChromePdfRenderer();
// One synchronous call parses the HTML string and produces an in-memory PDF document
var pdf = renderer.RenderHtmlAsPdf("<h1>Invoice</h1><p>Generated from HTML.</p>");
// Write the rendered document to disk
pdf.SaveAs("output.pdf");

using IronPdf;

// The embedded Chromium engine ships inside the package, so no browser is launched or downloaded
var renderer = new ChromePdfRenderer();
// One synchronous call parses the HTML string and produces an in-memory PDF document
var pdf = renderer.RenderHtmlAsPdf("<h1>Invoice</h1><p>Generated from HTML.</p>");
// Write the rendered document to disk
pdf.SaveAs("output.pdf");

Pełne porównanie, testy i szczegóły licencji znajdują się poniżej.

Tablica szybkich rekomendacji według scenariusza

Dopasuj swoje ograniczenie do wyboru przed przeczytaniem dogłębnego omówienia.

| Jeśli potrzebujesz |Zalecany wybór| Dlaczego | |---|---|---| |Nowoczesny CSS, Flexbox, Grid, czcionki sieciowe na dużą skalę|IronPDF (wbudowane Chromium)|Dokładne renderowanie, szybkie podglądy, brak zewnętrznej przeglądarki do wdrożenia| |Darmowe renderowanie jakości przeglądarki, gotowość do zarządzania operacjami|PuppeteerSharp lub Playwright|Prawdziwe Chromium, licencja MIT, większa objętość wdrożenia| |Prosty statyczny HTML, brak JavaScript|PdfSharp z HtmlRenderer|Lekki, darmowy, ograniczony do starszego CSS| |Programistyczne układy stałe, brak źródła HTML|QuestPDF|Płynne API C#, bardzo szybkie, nie jest renderowaniem HTML| |Zero infrastruktury, przetwarzanie hostowane|API HTML-do-PDF|Brak silnika renderującego do utrzymania w aplikacji| |Starszy projekt na wkhtmltopdf|Migracja do silnika Chromium|wkhtmltopdf jest zarchiwizowany, zawodzi na obecnym CSS i niesie krytyczne CVE SSRF|

Dlaczego konwersja HTML na PDF jest trudna w C#

Przeglądarki renderują płynne treści na ekrany; PDF wymaga stron stałych, dokładnych wymiarów i ścisłej paginacji. Różnica między tymi dwoma modelami określa sukces lub porażkę bibliotek. Pięć kryteriów je odróżnia i dotyczą każdej narzędzia niezależnie od dostawcy.

1. Silnik renderujący i nowoczesny CSS: silnik, który analizuje HTML i CSS, jest głównym czynnikiem różnicującym. Obecne szablony polegają na CSS Flexbox do wyrównania, CSS Grid do układu dwuwymiarowego, @font-face do typografii i SVG do zasobów wektorowych. Silniki oparte na starych forkach WebKit lub niestandardowych analizatorach mają tendencję do cichego zawodzenia i zapadania stylizowanych układów w pionowy stos. Poprawne przetwarzanie reguł @media print jest równie ważne przy przekształcaniu układu ekranu na papier.

2. WykonanieJavaScripti oczekiwanie na render: wiele dzisiejszej zawartości jest zbudowane po stronie klienta. Biblioteki wykresów, takie jak Chart.js, i ramy jednostronicowe, takie jak Blazor WebAssembly, konstruują DOM za pomocąJavaScriptprzed ukończeniem strony. Biblioteka bez silnikaJavaScriptprodukuje puste wykresy lub strony częściowo załadowane, co sprawia, że zdolność do wykonania skryptów i oczekiwanie na sygnał gotowości do renderowania jest decydująca dla dynamicznych dokumentów.

3. Waga wdrożenia i zimny start: narzędzia, które napędzają zewnętrzną bezgłową przeglądarkę, pobierają setki megabajtów binariów, zwiększając obrazy kontenerów i spowalniając zimne starty. W środowiskach bezserwerowych, takich jak AWS Lambda lub Azure Functions, gdzie pamięć i przestrzeń są ograniczone, waga kontenera może zadecydować, czy biblioteka jest w ogóle realna.

4. Licencja i jej zasięg prawny: licencja reguluje więcej niż tylko koszt. Pole .NET PDF obejmuje warunki liberalne (MIT, Apache 2.0), warunki copyleft (AGPLv3), które mogą wymagać ujawnienia swojego źródła dla aplikacji sieciowych, poziomy społecznościowe ograniczone przychodami i wieczyste licencje komercyjne. Zły wybór może stworzyć zobowiązanie, które ujawnia się dopiero podczas audytu.

5. Wydajność i pamięć na dużą skalę: biblioteka, która działa dobrze w teście konsolowym, może się zatrzymać przy równoczesnym API sieciowym. Niektóre przesyłają pracę strumieniem; inne ładują cały dokument do pamięci naraz i wyzwalają pauzy w zbieraniu śmieci podczas zadań wsadowych. Zimny start, ciepłe renderowanie i pamięć na renderowanie to trzy oddzielne pomiary, z których każde wymaga uwagi.

Biblioteki, każda z działającym kodem

Najpierw pojawiają się opcje darmowe i open-source. Każdy poniższy fragment skompilowano i uruchomiono na .NET 10, a silniki Chromium pokazują zarówno wejście z ciągi znaków HTML, jak i URL, ponieważ obsługują oba.

PuppeteerSharp

PuppeteerSharp to port .NET Puppeteer Node.js Google, pierwszy raz wydany w 2017 roku. Napędza instancję bezgłowego Chromium za pomocą Chrome DevTools Protocol. Jest organizatorem procesów raczej niż biblioteką pracującą w procesie: aplikacja pobiera wersję Chromium z BrowserFetcher, uruchamia przeglądarkę, ustawia treść strony i tworzy plik PDF.

using PuppeteerSharp;
using System.Threading.Tasks;

public class PuppeteerExample
{
    public async Task GeneratePdfAsync()
    {
        // Download a matching Chromium build if it is not already present (the 100-300 MB fetch)
        await new BrowserFetcher().DownloadAsync();

        // Start a headless browser process; await using disposes it to avoid orphaned processes
        await using var browser = await Puppeteer.LaunchAsync(new LaunchOptions { Headless = true });
        // Open a fresh tab to work in
        await using var page = await browser.NewPageAsync();

        // Load the HTML directly into the page instead of navigating to a URL
        await page.SetContentAsync("<h1>Invoice Report</h1><p>Rendered with PuppeteerSharp.</p>");
        // Drive Chrome's print pipeline to emit the PDF file
        await page.PdfAsync("puppeteer_output.pdf");
    }
}

using PuppeteerSharp;
using System.Threading.Tasks;

public class PuppeteerExample
{
    public async Task GeneratePdfAsync()
    {
        // Download a matching Chromium build if it is not already present (the 100-300 MB fetch)
        await new BrowserFetcher().DownloadAsync();

        // Start a headless browser process; await using disposes it to avoid orphaned processes
        await using var browser = await Puppeteer.LaunchAsync(new LaunchOptions { Headless = true });
        // Open a fresh tab to work in
        await using var page = await browser.NewPageAsync();

        // Load the HTML directly into the page instead of navigating to a URL
        await page.SetContentAsync("<h1>Invoice Report</h1><p>Rendered with PuppeteerSharp.</p>");
        // Drive Chrome's print pipeline to emit the PDF file
        await page.PdfAsync("puppeteer_output.pdf");
    }
}

Aby uchwycić żywy URL zamiast ciągu znaków, najpierw nawiguj do niego przed wywołaniem:

// Navigate the tab to a live URL so the loaded page becomes the render source
await page.GoToAsync("https://example.com");
// Capture whatever is currently displayed as a PDF
await page.PdfAsync("from_url.pdf");

// Navigate the tab to a live URL so the loaded page becomes the render source
await page.GoToAsync("https://example.com");
// Capture whatever is currently displayed as a PDF
await page.PdfAsync("from_url.pdf");

Mocne strony:

• Renderowanie odpowiada Google Chrome, z pełnym wsparciem Flexbox, Grid i fontów sieciowych.
• WykonujeJavaScripti może czekać na bezczynność sieci przed uchwyconiem.
• Licencja MIT, więc użycie komercyjne nie wiąże się z żadnym obowiązkiem copyleft.

Ograniczenia:

• Pierwsze uruchomienie pobiera wersję Chromium o rozmiarze od 100 MB do 300 MB.
• Każda instancja przeglądarki zużywa znaczącą pamięć, więc równoczesne partie potrzebują puli przeglądarek.
• Brak wbudowanego wyjścia PDF/A lub PDF/UA.

License: MIT. Użyj, gdy chcesz darmowe wyjście o wierności Chrome, a zespół może przejąć nakład operacyjny. Aby uzyskać skoncentrowane porównanie tego kompromisu, zobacz PorównaniePuppeteerSharpvs IronPDF.

###Playwrightfor .NET

Playwright jest utrzymywany przez Microsoft jako rama automatyzacji wieloprzeglądarkowej dla Chromium, WebKit i Firefox. Zespoły ponownie wykorzystują go do HTML na PDF przez Page.PdfAsync, chociaż generowanie PDF działa tylko z Chromium. Konfiguracja pobiera binaria przeglądarki przez jednorazowy krok instalacji.

using Microsoft.Playwright;
using System.Threading.Tasks;

public class PlaywrightExample
{
    public async Task GeneratePdfAsync()
    {
        // Create thePlaywrightdriver that manages the installed browser binaries
        using var playwright = await Playwright.CreateAsync();
        // PDF output is Chromium-only, so launch the Chromium build specifically
        await using var browser = await playwright.Chromium.LaunchAsync();
        // Open a new page (tab) to render into
        var page = await browser.NewPageAsync();

        // Set the HTML content in place rather than navigating to a URL
        await page.SetContentAsync("<html><body><h1>Sales Dashboard</h1></body></html>");
        // Emit the PDF with an explicit A4 page format
        await page.PdfAsync(new PagePdfOptions { Path = "playwright_output.pdf", Format = "A4" });
    }
}

using Microsoft.Playwright;
using System.Threading.Tasks;

public class PlaywrightExample
{
    public async Task GeneratePdfAsync()
    {
        // Create thePlaywrightdriver that manages the installed browser binaries
        using var playwright = await Playwright.CreateAsync();
        // PDF output is Chromium-only, so launch the Chromium build specifically
        await using var browser = await playwright.Chromium.LaunchAsync();
        // Open a new page (tab) to render into
        var page = await browser.NewPageAsync();

        // Set the HTML content in place rather than navigating to a URL
        await page.SetContentAsync("<html><body><h1>Sales Dashboard</h1></body></html>");
        // Emit the PDF with an explicit A4 page format
        await page.PdfAsync(new PagePdfOptions { Path = "playwright_output.pdf", Format = "A4" });
    }
}

Przed pierwszym uruchomieniem zainstaluj przeglądarkę za pomocą pwsh bin/Debug/net10.0/playwright.ps1 install chromium (lub wywołaj równoważny punkt wejścia do instalacji w kodzie).

Dla żywego URL najpierw nawiguj do strony:

// Load a live URL so its rendered DOM becomes the PDF source
await page.GotoAsync("https://example.com");
// Export the loaded page as an A4 PDF
await page.PdfAsync(new PagePdfOptions { Path = "from_url.pdf", Format = "A4" });

// Load a live URL so its rendered DOM becomes the PDF source
await page.GotoAsync("https://example.com");
// Export the loaded page as an A4 PDF
await page.PdfAsync(new PagePdfOptions { Path = "from_url.pdf", Format = "A4" });

Gdzie się wyróżnia:

• wspierany przez Microsoft z aktywnym cyklem wydań.
• Niskie opóźnienie pierwszego renderowania, gdy przeglądarka jest uruchomiona.
• Dokładnie renderuje nowoczesne standardy sieciowe iJavaScriptpo stronie klienta.

Haczyk:

• Ta sama ciężka objętość binarna i zarządzanie przeglądarką co PuppeteerSharp.
• Pamięć rośnie bez ostrożnego zarządzania kontekstem przeglądarki.
• Wyjście PDF jest cechą uboczną ścieżki wydruku Chrome, więc brakuje mu funkcji manipulacji dokumentami.

License: MIT. Idealne, gdy projekt już używaPlaywrightdo testowania i chce darmowego renderowania obok niego.

wkhtmltopdf (via DinkToPdf)

Przez ponad dekadę wkhtmltopdf było domyślnym narzędziem HTML na PDF. W .NET zazwyczaj używany jest przez DinkToPdf, opakowanie C# nad natywną biblioteką libwkhtmltox. API opakowania jest czyste, ale problemem jest ukryty pod spodem silnik.

using DinkToPdf;

public class DinkToPdfExample
{
    public void GeneratePdf()
    {
        // SynchronizedConverter serializes calls into the non-thread-safe native libwkhtmltox library
        var converter = new SynchronizedConverter(new PdfTools());

        // Describe the document: global page settings plus one or more HTML content objects
        var doc = new HtmlToPdfDocument
        {
            // Set the paper size and the output file path for the whole document
            GlobalSettings = { PaperSize = PaperKind.A4, Out = "legacy_output.pdf" },
            // Each object is a chunk of HTML to render into the PDF
            Objects = { new ObjectSettings { HtmlContent = "<h1>Legacy Report</h1>" } }
        };

        // Hand the descriptor to the native engine, which writes the file defined in Out
        converter.Convert(doc);
    }
}

using DinkToPdf;

public class DinkToPdfExample
{
    public void GeneratePdf()
    {
        // SynchronizedConverter serializes calls into the non-thread-safe native libwkhtmltox library
        var converter = new SynchronizedConverter(new PdfTools());

        // Describe the document: global page settings plus one or more HTML content objects
        var doc = new HtmlToPdfDocument
        {
            // Set the paper size and the output file path for the whole document
            GlobalSettings = { PaperSize = PaperKind.A4, Out = "legacy_output.pdf" },
            // Each object is a chunk of HTML to render into the PDF
            Objects = { new ObjectSettings { HtmlContent = "<h1>Legacy Report</h1>" } }
        };

        // Hand the descriptor to the native engine, which writes the file defined in Out
        converter.Convert(doc);
    }
}

Ten kod skompiluje się, ale uruchomienie go na czystym komputerze rzuca System.DllNotFoundException: Unable to load DLL 'libwkhtmltox', dopóki natywne binaria nie są skopiowane do katalogu wyjściowego. Ten krok zależności natywnej jest pierwszym znakiem tarcia przy wdrażaniu, jakie przynosi ten silnik.

Plusy:

• Szybki zimny start, bez potrzeby inicjalizacji nowoczesnej przeglądarki.
• Niska pamięć, około 50 MB na render.

Minusy:

• Silnik QtWebKit, z którego korzysta (migawka WebKit z lat 2012-2013, z której Qt zrezygnowało w 2015 roku i usunięte w 2016 roku) nie potrafi renderować Flexbox, Grid ani nowoczesnego JavaScript.
• Repozytorium wkhtmltopdf zostało zarchiwizowane 2 stycznia 2023 roku, a ostatnie wydanie, 0.12.6, pochodzi z czerwca 2020 roku.
• Zawiera CVE-2022-35583, błąd Server-Side Request Forgery oceniony na CVSS 9.8 (krytyczny), który jest niezałatany, ponieważ projekt nie jest już utrzymywany.

Licencja: Sam DinkToPdf jest na licencji MIT, ale łączy binaria wkhtmltopdf na licencji LGPLv3, więc wynikające obowiązki pochodzą z wkhtmltopdf. Odpowiedni dla starszych części przepływu pracy czekających na migrację, z ryzykiem bezpieczeństwa w zasięgu wzroku. Zobacz Porównanie wkhtmltopdf vs IronPDF dla pełnego obrazu migracji.

PdfSharp and HtmlRenderer

PdfSharp jest szeroko stosowaną biblioteką open-source, ale częstym błędnym założeniem jest, że konwertuje HTML samodzielnie. Nie robi tego. PdfSharp dostarcza API rysowania niskopoziomowego opartego na współrzędnych. Aby konwertować HTML, połącz go z mostem społeczności HtmlRenderer.PdfSharp, który analizuje HTML i wywołuje polecenia rysowania PdfSharp.

using PdfSharp;
using TheArtOfDev.HtmlRenderer.PdfSharp;

public class PdfSharpExample
{
    public void GeneratePdf()
    {
        string html = "<h1>Simple Title</h1><p>Statically rendered text.</p>";

        // The HtmlRenderer bridge parses the HTML and emits PdfSharp drawing commands onto an A4 page
        var pdf = PdfGenerator.GeneratePdf(html, PageSize.A4);
        // Persist the resulting PdfSharp document to disk
        pdf.Save("simple_document.pdf");
    }
}

using PdfSharp;
using TheArtOfDev.HtmlRenderer.PdfSharp;

public class PdfSharpExample
{
    public void GeneratePdf()
    {
        string html = "<h1>Simple Title</h1><p>Statically rendered text.</p>";

        // The HtmlRenderer bridge parses the HTML and emits PdfSharp drawing commands onto an A4 page
        var pdf = PdfGenerator.GeneratePdf(html, PageSize.A4);
        // Persist the resulting PdfSharp document to disk
        pdf.Save("simple_document.pdf");
    }
}

Dwa szczegóły konfiguracji są ważne na .NET 10. Most oczekuje na stronę kodową Windows-1252, której nie ma domyślnie w nowoczesnym .NET, więc zarejestruj ją raz na początku z Encoding.RegisterProvider(CodePagesEncodingProvider.Instance). Łączenie mostu z nowszym pakietem PdfSharp 6.x również psuje się w czasie wykonywania z MissingMethodException, więc pozwól HtmlRenderer pobrać własny kompatybilny PdfSharp zamiast przypinania najnowszego.

Co działa:

• Zdecydowanie liberalna licencjaMITbez ograniczeń przychodu.
• Lekki, bez natywnych binariów lub ładowaczy przeglądarek.
• Napisany w czystym C#, co upraszcza wdrożenie na różnych systemach operacyjnych.

Co się psuje:

• Most HTML jest ograniczony do HTML 4.01 i CSS Level 2, i zobaczył jednorazowy zestaw wydań w końcu 2025 roku po dziewięciu latach bezczynności.
• Brak wykonania JavaScript.
• Reguły wydruku takie jak page-break-inside: avoid są nieobsługiwane, co powoduje, że wiersze tabeli dzielą się przez strony.

License: PdfSharp MIT, HtmlRenderer BSD-3-Clause. Pierwszorzędny wybór dla prostych statycznych dokumentów bez skomplikowanego układu. Dla analizy cecha po cesze, zobacz Porównanie PdfSharp vs IronPDF.

QuestPDF

QuestPDF obiera inną ścieżkę: odrzuca HTML i definiuje układy w C# za pomocą płynnego API. Dla danych, które pochodzą jako obiekty, a nie znaczniki, to usuwa krok generowania HTML tylko po to, by go później analizować.

using QuestPDF.Fluent;
using QuestPDF.Helpers;
using QuestPDF.Infrastructure;

public class QuestPdfExample
{
    public void GeneratePdf()
    {
        // The revenue-gated license tier must be declared before any document is built
        QuestPDF.Settings.License = LicenseType.Community;

        // Compose the layout in C# through the fluent API; no HTML anywhere
        var document = Document.Create(container =>
        {
            container.Page(page =>
            {
                // Define the physical page size and margins
                page.Size(PageSizes.A4);
                page.Margin(2, Unit.Centimetre);
                // Place content into named page regions (header and body)
                page.Header().Text("Programmatic Invoice").FontSize(24);
                page.Content().Text("This document is generated without HTML.");
            });
        });

        // Run the layout engine and write the composed document to a file
        document.GeneratePdf("fluent_layout.pdf");
    }
}

using QuestPDF.Fluent;
using QuestPDF.Helpers;
using QuestPDF.Infrastructure;

public class QuestPdfExample
{
    public void GeneratePdf()
    {
        // The revenue-gated license tier must be declared before any document is built
        QuestPDF.Settings.License = LicenseType.Community;

        // Compose the layout in C# through the fluent API; no HTML anywhere
        var document = Document.Create(container =>
        {
            container.Page(page =>
            {
                // Define the physical page size and margins
                page.Size(PageSizes.A4);
                page.Margin(2, Unit.Centimetre);
                // Place content into named page regions (header and body)
                page.Header().Text("Programmatic Invoice").FontSize(24);
                page.Content().Text("This document is generated without HTML.");
            });
        });

        // Run the layout engine and write the composed document to a file
        document.GeneratePdf("fluent_layout.pdf");
    }
}

Mocne strony:

• Bardzo szybki, ponieważ pomija analizę DOM i układ przeglądarki.
• Przewidywalna, liniowa pamięć, która odpowiada zadaniom wsadowym o dużej przepustowości.
• Aplikacja towarzysząca oferuje podgląd na żywo i gorące przeładowanie podczas projektowania.

Słabe strony:

• To jest silnik układu, a nie renderowanie HTML, więc nie może konwertować URL lub istniejącego szablonu HTML.
• Istniejące dokumenty HTML lub Razor będą potrzebowały pełnoprawego przepisania w płynne API.
• Licencja przeszła zMITna modele ograniczone przychodem.

Licencja: Licencja społecznościowa (darmowa dla firm o rocznych przychodach poniżej 1 000 000 USD) lub płatna wersja Professional i Enterprise. Pasuje do dokumentów o stałym układzie zdefiniowanych przez kod napędzanych danymi strukturalnymi. Zobacz PorównanieQuestPDFvs IronPDF dla rozważenia HTML w stosunku do płynnego układu.

iText (pdfHTML)

iText 7 i 8 są rozpoznawane za programistyczną manipulację PDF, a dodatek pdfHTML konwertuje HTML. W przeciwieństwie do narzędzi Chromium, pdfHTML używa własnego analizatora, który mapuje tagi HTML do obiektów iText zamiast uruchamiania przeglądarki.

using iText.Html2pdf;
using System.IO;

public class iTextExample
{
    public void GeneratePdf()
    {
        string html = "<h1>Report</h1><p>Converted with pdfHTML.</p>";

        // Open the destination stream; using ensures the file handle is released after writing
        using var dest = File.Create("output.pdf");
        // pdfHTML maps the HTML tags to iText objects and writes them to the stream (no browser involved)
        HtmlConverter.ConvertToPdf(html, dest);
    }
}

using iText.Html2pdf;
using System.IO;

public class iTextExample
{
    public void GeneratePdf()
    {
        string html = "<h1>Report</h1><p>Converted with pdfHTML.</p>";

        // Open the destination stream; using ensures the file handle is released after writing
        using var dest = File.Create("output.pdf");
        // pdfHTML maps the HTML tags to iText objects and writes them to the stream (no browser involved)
        HtmlConverter.ConvertToPdf(html, dest);
    }
}

Na nowym projekcie to rzuca, dopóki nie dodasz pakietu itext7.bouncy-castle-adapter, który iText wymaga dla swojej ścieżki kryptograficznej. Ta dodatkowa zależność jest łatwa do przeoczenia i powoduje nieprzezroczysty błąd bez niej.

Zalety:

• Głębokie manipulacje PDF, podpisywanie i redagowanie w całym ekosystemie iText.
• Produkuje PDF/A i PDF/UA z semantycznego HTML, co pasuje do prac zgodności.
• Szybki czas uruchamiania, ponieważ nie uruchamia przeglądarki.

Wady:

• Brak wykonania skryptów, więc dynamiczna zawartość nie jest renderowana.
• Funkcje CSS3, takie jak Grid, są nieobsługiwane i zawodzą cicho.
• Licencja AGPLv3 wymaga komercyjnej licencji dla aplikacji zamkniętego źródła, a duże pliki są buforowane w całości zamiast strumieniowane.

Licencja: AGPLv3 lub Komercyjna. Wybierz go do ciężkiej manipulacji PDF i prac związanych z zgodnością z kontrolowanym, statycznym HTML. Aby uzyskać szczegóły licencji i manipulacji, zobacz Porównanie iText 7 vs IronPDF.

IronPDF

IronPDF osadza silnik Chromium w swoim pakiecie NuGet i udostępnia go przez API C#, więc nic zewnętrznego nie musi być uruchamiane ani zgrupowane. Leży pomiędzy darmowymi narzędziami przeglądarkowymi a bibliotekami programistycznymi, wymieniając koszt licencji na wierność renderowania według jakości przeglądarki, bez potrzeby zarządzania przeglądarką.

using IronPdf;
using System.Threading.Tasks;

public class IronPdfExample
{
    public async Task GeneratePdfAsync()
    {
        // Create the in-process Chromium renderer (no external browser to launch)
        var renderer = new ChromePdfRenderer();
        // Turn on theJavaScriptengine so client-side chart scripts execute before capture
        renderer.RenderingOptions.EnableJavaScript = true;
        // Wait 500 ms after load to let JavaScript-built content settle before rendering
        renderer.RenderingOptions.WaitFor.RenderDelay(500);

        // Render the HTML string asynchronously into an in-memory PDF
        var pdf = await renderer.RenderHtmlAsPdfAsync("<h1>Quarterly Report</h1><div class='chart'></div>");
        // Save the finished PDF to disk
        pdf.SaveAs("report.pdf");
    }
}

using IronPdf;
using System.Threading.Tasks;

public class IronPdfExample
{
    public async Task GeneratePdfAsync()
    {
        // Create the in-process Chromium renderer (no external browser to launch)
        var renderer = new ChromePdfRenderer();
        // Turn on theJavaScriptengine so client-side chart scripts execute before capture
        renderer.RenderingOptions.EnableJavaScript = true;
        // Wait 500 ms after load to let JavaScript-built content settle before rendering
        renderer.RenderingOptions.WaitFor.RenderDelay(500);

        // Render the HTML string asynchronously into an in-memory PDF
        var pdf = await renderer.RenderHtmlAsPdfAsync("<h1>Quarterly Report</h1><div class='chart'></div>");
        // Save the finished PDF to disk
        pdf.SaveAs("report.pdf");
    }
}

Ten sam render przekształca URL na PDF za pomocą jednego wywołania:

// RenderUrlAsPdf fetches and renders the live page in one call, no navigation step needed
var fromUrl = new ChromePdfRenderer().RenderUrlAsPdf("https://example.com");
// Write the captured page to disk
fromUrl.SaveAs("from_url.pdf");

// RenderUrlAsPdf fetches and renders the live page in one call, no navigation step needed
var fromUrl = new ChromePdfRenderer().RenderUrlAsPdf("https://example.com");
// Write the captured page to disk
fromUrl.SaveAs("from_url.pdf");

Również renderuje widoki Razor i MVC na PDF i bezpośrednio odzyskuje pliki HTML. Pełne omówienie funkcji znajduje się w Poradnik HTML do PDF.

Zalety:

• Renderowanie w jakości przeglądarki, które obsługuje Grid, Flexbox i skrypty po stronie klienta.
• Implementacja bez zewnętrznych wykonywalnych plików ani grup przeglądarek.
• Generuje PDF/A i stosuje podpisy cyfrowe, co odróżnia go od ram testowych.

Wady:

• Wymagana licencja komercyjna, brak darmowej wersji produkcyjnej.
• Po nowym wdrożeniu pierwsze renderowanie niesie jednorazowy koszt inicjalizacji, potem kolejne renderowania utrzymują szybki tor ciepłego procesu.

Licencja: Komercyjna, wieczysta. Użyj, kiedy ważny jest obecny CSS na dużą skalę, a priorytety to zmniejszenie nakładów operacyjnych przy jednoczesnym utrzymaniu wysokiej wierności.

Pełna Tabela Porównawcza

Jeden wiersz na bibliotekę, z uwzględnioną kolumną licencji, ponieważ bezpośrednio wpływa na decyzję darmowe vs płatne.

| Biblioteka |Silnik|JavaScript| Nowoczesny CSS |Waga wdrożenia| Licencja | Najlepsze dla | |---|---|---|---|---|---|---| |IronPDF|Osadzone Chromium| Tak | Pełna |Lekki (NuGet)| Komercjalne |Nowoczesny CSS na dużą skalę| |PuppeteerSharp|Zewnętrzny Chromium| Tak | Pełna |Ciężki (pobranie binarne)|MIT|Darmowe renderowanie przeglądarki| |Playwright|Zewnętrzny Chromium| Tak | Pełna |Ciężki (pobranie binarne)|MIT|Nowoczesne darmowe renderowanie| | wkhtmltopdf |Stary QtWebKit| Ograniczone |Słaby|Średni (biblioteki natywne)|LGPLv3 (opakowanie MIT)|Przepływy pracy dziedziczone| |PdfSharp + HtmlRenderer|Rysowanie niestandardowe| Nie | Ograniczone |Lekki|MIT / BSD-3|Prosty statyczny HTML| |QuestPDF|Programistyczny| Nie dotyczy | Nie dotyczy |Lekki|Społeczność / Płatne|Układy zdefiniowane w kodzie| |iText pdfHTML| Niestandardowy parser | Nie | Ograniczone |Medium|AGPLv3 / Komercyjna| Manipulacja plikami PDF |

Zweryfikuj każdą komórkę w bieżącej wersji każdej biblioteki przed integracją, ponieważ licencje i wsparcie dla silnika mogą się zmieniać.

Darmowe vs Płatne: kiedy każda z opcji jest właściwa

Narzędzia, które są "darmowe", mogą ukrywać operacyjne i prawne koszty w polu .NET PDF, więc nazwanie przypadków, kiedy darmowe narzędzie jest właściwym wyborem, jest uczciwym punktem startowym.

Darmowa biblioteka open-source wystarcza do nieskomplikowanych, statycznych dokumentów, niskiej objętości lub zespołu, który ma zdolność operacyjną do zarządzania zewnętrznymi procesami. Paragon ciężki w tekst z niewyszukaną stylizacją renderuje się dobrze z PdfSharp na licencji MIT. Gdzie zespół już uruchamiaPlaywrightdo testów i rozwiązał problem z konteneryzacją, ponowne użycie go do okazjonalnych zleceń PDF jest wydajne.

Darmowe oprogramowanie nie oznacza darmowej implementacji. Ukryty koszt open-sourceowych przeglądarek bezgłowych ujawnia się w godzinach utrzymania: organizowanie cyklu życia przeglądarki, aby serwer nie zawieszał się pod obciążeniem, konfigurowanie zależności do bibliotek współdzielonych Linuksa na obrazy kontenerów i absorbowanie kosztów infrastruktury ciężkich procesów przeglądarkowych. Dla trywialnych statycznych dokumentów płatny silnik przeglądarkowy to przesada, a lekka darmowa biblioteka jest lepszym wyborem.

Komercyjna biblioteka Chromium staje się uzasadniona, gdy praca wymaga dokładnego CSS3 na dużą skalę, dostępnego wyjścia PDF/UA i prostoty wdrożenia ponad kosztem pozyskania. Komercyjne licencjonowanie również usuwa narażenie na copyleft. Dodanie biblioteki AGPLv3, takiej jak iText, do platformy SaaS może zobowiązać firmę do wydania jej źródła, chyba że zakupiona jest licencja komercyjna. Prawdziwe porównanie to całkowity koszt posiadania: czas operacyjny i ryzyko prawne po jednej stronie, opłaty licencyjne po drugiej.

Benchmarki

Każda liczba poniżej pochodzi z praktycznego uruchomienia na jednym komputerze, więc traktuj je jako wskaźniki. Dokument testowy to faktura z 30 wierszami używająca CSS Grid w nagłówku i osadzona wykres słupkowy JavaScript. Testowanie przeprowadzono na standardowej stacji roboczej Windows na .NET 10. Każda ciepła liczba to średnia z ośmiu renderów po pierwszym, a szczytowa pamięć to szczytowy zestaw roboczy procesu .NET plus jakiekolwiek procesy potomne przeglądarki, które on uruchomił.

| Biblioteka |Zimny start (na proces)|Ciepłe renderowanie (średnia z 8)|Szczytowa pamięć| |---|---|---|---| |IronPDF|345 ms|202 ms|406 MB| |PuppeteerSharp|746 ms|204 ms|611 MB| |Playwright|588 ms|132 ms|515 MB| |wkhtmltopdf, iText, PdfSharp| sub-second | not comparable |50 do 120 MB|

Po rozgrzaniu, trzy silniki przeglądarkowe renderują ten sam dokument w około 130 do 200 ms, przy czymPlaywrightjest najszybszy w tym teście, a IronPDFiPuppeteerSharpsą tuż za nim. Na zimnym starcie, osadzony silnik wystartował najszybciej tutaj, ponieważ działa wewnątrz procesu bez potrzeby uruchamiania oddzielnej przeglądarki, choć pierwsze renderowanie po nowym wdrożeniu absorbuje koszty inicjalizacji silnika, które dalsze starty pomijają. Narzędzia starsze i użytkownicze (wkhtmltopdf, iText, PdfSharp) startują poniżej sekundy i używają najmniej pamięci, ale ta korzyść jest nieistotna dla dokumentu testowego, ponieważ nie mogą poprawnie renderować jego układu Grid ani wykresu JavaScript. wkhtmltopdf w ogóle nie mógł działać bez uprzednio dostarczonych jego natywnych binariów.

Luka w wierności pokazuje się w wyjściu. Silnik przeglądarkowy renderuje nagłówek CSS Grid, stylizowaną tabelę i wykres słupkowy JavaScript:

Ten sam dokument przez PdfSharp z HtmlRenderer pomija nagłówek grid, stylizację nagłówka tabeli i wykres JavaScript:

Który powinieneś użyć?

Krótki werdykt dla każdego powszechnego scenariusza:

• Ramy CSS i wynik jednostronicowy: tylko renderer klasy przeglądarki nadąża.
• Prosty statyczny HTML lub pokwitowania tekstowe: PdfSharp i mały darmowy stos to wystarczy.
• Programistyczne, zdefiniowane przez dane układy bez znaczników:QuestPDFdociera najszybciej.
• Darmowe renderowanie przeglądarki z możliwością operacyjną:PuppeteerSharplub Playwright.
• Zero infrastruktury: hostowane API HTML-do-PDF.
• Migracja dziedziczona z wkhtmltopdf: przejdź na osadzony silnik dla bezpieczeństwa i obsługi CSS.

Gdy ciężki wynikowski CSS-framework spotyka się z potrzebą niskiego operacyjnego,IronPDFjest pierwszym osadzonym wyborem, podczas gdy darmowe narzędzia przeglądarkowe pozostają właściwym wyborem dla zespołów, które mogą przejąć operacje nad przeglądarką bezgłową.

Rozważania dotyczące wdrożeń

Największe tarcie w generowaniu dokumentów .NET to przepaść między biblioteką, która działa na laptopie z systemem Windows a taką, która nie działa na kontenerze Linuksa. Wybór biblioteki oznacza przewidywanie, gdzie się je dostarcza.

W Dockerze, zorganizowane przeglądarki takie jakPuppeteerSharpiPlaywrightpotrzebują bazowego obrazu z zależnościami Linuksa dla Chromium, w tym libnss3, libatk-bridge2.0-0 i libgbm1. Microsoft publikuje obrazyPlaywright.NET pod mcr.microsoft.com/playwright/dotnet (na przykład tag v1.NN.0-noble) aby to pokryć, i te obrazy zbliżają się do jednego gigabajta. Osadzone silniki omijają nadmiar poprzez dostarczanie pakietów NuGet per-architektura, takie jak IronPdf.Linux, które zawierają natywne binaria i utrzymują standardowy aspnet bazowy obraz pracujący bez ręcznych kroków apt-get.

AWS Lambda stawia inny mur. Wymusza twardy limit 250 MB na rozpakowany pakiet wdrożenia, a pojedyncza wersja bezgłowego Chromium waży 150 MB do 300 MB. To czyni standardowe wdrożenia zipPuppeteerSharplubPlaywrightniepraktycznymi i popycha zespoły do Lambda opartej na kontenerach, co pozwala na do 10 GB kosztem gorszego zimnego startu.

Azure App Service dodaje własne ograniczenia na obu systemach operacyjnych. Windows App Service Sandbox blokuje większość wywołań User32 i GDI32, tym samym łamiąc ścieżki renderingowe zależne od GDI. Wdrożenie DinkToPdf na Linux App Service oznacza kopiowanie niezarządzanych plików .so do katalogu wyjściowego i instalowanie zależności jak libfontconfig1 i libxrender1; brak jednego z nich pojawi się jako nieprzezroczysty System.DllNotFoundException. To są te same problemy z zależnościami natywnymi i piaskownicą, które potwierdził bieg weryfikacyjny.

Wniosek i rekomendacja

Pole C# HTML do PDF na .NET 10 nagradza dopasowanie narzędzia do dokumentu. Pełny silnik przeglądarki to podstawa dla ram i układów responsywnych CSS i stron napędzanych JavaScript, a podział między darmowymi a komercyjnymi rzeczywiście jest podziałem między wysiłkiem operacyjnym a kosztem licencji. Biblioteki programistyczne pozostają wydajne dla stałych, statycznych układów, aQuestPDFjest najszybszą drogą, kiedy dane wejściowe to dane strukturalne, a nie znaczniki. wkhtmltopdf znajduje się w planach migracyjnych tylko ze względu na zarchiwizowany silnik i niezałatany błąd SSRF. Dla zespołów, które chcą dokładnego renderowania bez dużego nakładu operacyjnego,IronPDFjest domyślnym osadzonym wyborem, z dostępem do URL do PDF, renderowania widoku Razor, wyjścia PDF/A i podpisów cyfrowych z tego samego API, podczas gdyPuppeteerSharpiPlaywrightpozostają silnymi darmowymi wyborami tam, gdzie cykl życia przeglądarki jest czymś, co zespół może opanować.

Spróbuj samodzielnie na własnym HTML

Jeśli dokładne renderowanie z lekkim kosztem wdrożenia pasuje do Twojego projektu, możesz rozpocząć darmowy test IronPDF i uruchomić tę samą testową fakturę na swoich własnych szablonach przed zaangażowaniem.IronPDFjest budowany przez Iron Software, której biblioteki .NET obejmują również OCR, kody kreskowe, Word i Excel.

Dziękujemy za przeczytanie. Każda biblioteka, na którą się zdecydujesz, musi pasować do dokumentu przed Tobą.