IRONSOFTWAREHOME
MIT ANDEREN KOMPONENTEN VERGLEICHEN

ZXing.Net vs IronBarcode: Wahl einer .NET Barcode-Bibliothek in 2026

Curtis Chau
Curtis Chau
Updated: 1. August 2026

ZXing.Net's BarcodeReader ist nicht threadsicher. Jeder gleichzeitige Leseprozess in Ihrer Anwendung — jeder parallele ForEach, jede asynchrone Controller-Aktion, die gleichzeitige Anfragen verarbeitet — erfordert eine eigene Leserinstanz. Das bedeutet, dass die Formatkonfiguration pro Instanz wiederholt wird, Bitmap beim Laden und Freigeben pro Aufruf sowie Leserallokation bei jeder Anfrage. Die statische Methode von IronBarcode erledigt die gleiche Arbeit ohne pro Anfrage Allokation. Thread-Sicherheit ist nur ein Punkt auf der Liste: fehlende native PDF-Unterstützung, Fragmentierung des Bindungspakets unter Windows und Linux sowie die Notwendigkeit, jedes Barcode-Format, das gescannt werden soll, anzugeben – dies sind die Merkmale, die dazu führen, dass sich bei ZXing .NET -Projekten im Laufe der Zeit Workarounds ansammeln.

ZXing .NET verstehen

ZXing .NET ist eine Open-Source-Portierung der Java-Bibliothek ZXing ("Zebra Crossing") von Google, die unter der Apache-2.0-Lizenz veröffentlicht und von Michael Jahn auf GitHub gepflegt wird. Es handelt sich um die am häufigsten heruntergeladene Open-Source-Barcode-Bibliothek für .NET mit einer langen Erfolgsgeschichte, die sich über mehr als ein Jahrzehnt erstreckt. Die Bibliothek deckt sowohl das Lesen als auch das Schreiben einer breiten Palette von Barcode-Formaten ab, und ihre kostenlose Lizenz macht sie für Projekte jeder Größe zugänglich, einschließlich Open-Source-Produkte, die Apache-kompatible Abhängigkeiten benötigen.

Die Architektur von ZXing.Net spiegelt seine Ursprünge als Java-Portierung wider. Die BarcodeReader-Klasse ist ein zustandsbehaftetes Objekt: Der Aufruf von Decode schreibt den internen Zustand, was die Instanzen unsicher macht, um sie über Threads hinweg zu teilen. Die korrekte gleichzeitige Nutzung erfordert entweder einen neuen Leser pro Thread oder einen ThreadLocal<BarcodeReader>-Pool — beide legen die Verantwortung für die Threadsicherheit beim Aufrufer. Das Laden von Bildern ist ebenfalls nicht im Kernpaket enthalten; Stattdessen bietet ZXing .NET plattformspezifische Binding-Pakete an, die jeweils eine andere API-Oberfläche bereitstellen.

Zu den wichtigsten architektonischen Merkmalen gehören:

  • Apache 2.0 Lizenz: Kostenlos für kommerzielle und Open-Source-Nutzung, ohne Kosten und ohne Vertriebsverpflichtung.
  • Zustandsbehafteter BarcodeReader: Die BarcodeReader-Instanz ist nicht threadsicher; Für jeden Thread bzw. jede parallele Operation muss eine neue Instanz erstellt werden.
  • Manuelle Formatspezifikation: Aufrufer müssen reader.Options.PossibleFormats vor jedem Dekodieren setzen; Nicht aufgeführte Formate werden stillschweigend ohne Fehlermeldung oder Warnung übersprungen.
  • Keine native PDF-Unterstützung: Die Bibliothek liest nur Bilder; Für die PDF-Eingabe wird eine separate PDF-Rendering-Bibliothek wie beispielsweise PdfiumViewer benötigt, um die Seiten vor der Dekodierung in Bitmaps umzuwandeln.
  • Plattformbindungsfragmentierung: Das Kernpaket bietet keine Bildladefunktion; Separate Bindungspakete (ZXing.Net.Bindings.Windows.Compatibility mit System.Drawing,ZXing.Net.Bindings.ImageSharp / .V2 / .V3mit SixLabors.ImageSharp, plus ZXing.Net.Bindings.SkiaSharp und ZXing.Net.Bindings.Magick) bieten unterschiedliche APIs für verschiedene Bereitstellungsziele.
  • Aktive Community: Probleme, Pull-Anfragen und Diskussionen finden aktiv auf GitHub statt und bieten kostenlosen Support auf Community-Ebene.
  • Breites Formatspektrum: Unterstützt QR-Code, Code 128, Code 39, EAN-13, EAN-8, UPC-A, Data Matrix, PDF 417, Aztec und andere weit verbreitete Symbologien.

Die Stateful Reader Architektur

ZXing.Net's BarcodeReader erfordert eine neue Instanz für jeden Thread oder parallele Operation. Das folgende Muster zeigt die minimale korrekte Konfiguration für die gleichzeitige Verarbeitung:

// ZXing.Net: a new reader instance is created per iteration
Parallel.ForEach(imagePaths, path =>
{
    var reader = new BarcodeReader();
    reader.Options.PossibleFormats = new List<BarcodeFormat>
    {
        BarcodeFormat.QR_CODE,
        BarcodeFormat.CODE_128,
        BarcodeFormat.EAN_13
    };

    using var bitmap = new Bitmap(path);
    var result = reader.Decode(bitmap);

    if (result != null)
        results[path] = result.Text;
});

Das ThreadLocal<BarcodeReader>-Muster verringert die Allokation pro Aufruf, indem eine Instanz pro Thread wiederverwendet wird, fügt jedoch Komplexität bei der Freigabe hinzu. So oder so, Thread-Sicherheit ist die Verantwortung des Anrufers in ZXing.Net.

IronBarcode verstehen

IronBarcode ist eine kommerzielle .NET Barcode-Bibliothek, die von Iron Software entwickelt wurde. Es bietet Barcode-Lesen und -Erzeugung über eine zustandslose statische API: BarcodeReader.Read und BarcodeWriter.CreateBarcode sind die Haupteinstiegspunkte und erfordern keine Instanzerstellung oder Konfiguration vor der Nutzung. Die Bibliothek wird als einzelnes NuGet Paket ausgeliefert, das auf Windows, Linux, macOSund in Docker-Containern identisch läuft, ohne dass plattformspezifische Bindungspakete erforderlich sind.

Die Leseengine von IronBarcode führt eine automatische Formaterkennung für mehr als 50 Barcode-Symbologien durch. Die Anrufer geben nicht an, nach welchen Formaten gesucht werden soll; Die Engine wertet jedes Bild anhand aller unterstützten Formate aus und gibt alle gefundenen Barcodes zurück. Für Anwendungen, die Geschwindigkeit des Scannens gegen Gründlichkeit ausbalancieren müssen, bietet ein ReadingSpeed-Enum (Faster, Balanced, Detailed, ExtremeDetail) Kontrolle ohne Format-Aufzählung erfordern. Die Bibliothek beinhaltet außerdem native PDF-Unterstützung und liest Barcodes direkt aus PDF-Dokumenten auf allen Seiten, ohne dass eine separate PDF-Rendering-Bibliothek erforderlich ist.

Zu den wichtigsten Merkmalen gehören:

  • Kommerzielle Lizenz: Erfordert einen kostenpflichtigen Lizenzschlüssel; Ein Testmodus steht zur Verfügung.
  • Zustandslose statische API: BarcodeReader.Read und BarcodeWriter.CreateBarcode sind threadsichere statische Methoden; Es ist keine Instanzverwaltung erforderlich.
  • Automatische Formaterkennung: Alle über 50 unterstützten Barcode-Formate werden ohne Formatliste erkannt; der Benutzer kann die Geschwindigkeit anstatt des Formatumfangs anpassen.
  • Nativer PDF-Support: BarcodeReader.Read akzeptiert direkt PDF-Dateipfade und verarbeitet alle Seiten ohne externe PDF-Bibliothek.
  • Einzelnes plattformübergreifendes Paket: Ein NuGet Paket, das unter Windows, Linux, macOSund Docker mit derselben API-Oberfläche läuft.
  • Fluent Erzeugungs-API: BarcodeWriter.CreateBarcode gibt ein GeneratedBarcode-Objekt mit eingebauten Ausgabe-Methoden zurück, einschließlich SaveAsPng, SaveAsPdf, ToPngBinaryData und ToStream.
  • Kommerzieller Support: Bezahlte Lizenzen beinhalten den Zugang zum Support-Team von Iron Software mit Service-Level-Vereinbarungen.

Funktionsvergleich

Die folgende Tabelle verdeutlicht die grundlegenden Unterschiede zwischen ZXing .NET und IronBarcode:

FeatureZXing.NetIronBarcode
LizenzApache 2.0(kostenlos)Kommerziell
Thread-SicherheitNicht threadsicher – für jeden Thread ist eine neue Instanz erforderlich.Threadsichere statische API
FormaterkennungManuell — PossibleFormats-Liste erforderlichAutomatisch – über 50 Formate
PDF-LesenNein – benötigt PdfiumViewer oder ein ähnliches Programm.Native — einzelner Methodenaufruf
Windows, Linux, macOS, Docker, Azure, AWS.Separate Bindungspakete pro PlattformEinzelpaket, alle Plattformen
Barcode-GenerierungGibt Bitmap zurück, erfordert manuelles SpeichernFluent API mit integrierter Ausgabe
PreisgestaltungKostenlosAb $999 (Lite) / $1.499 (Plus)

Detaillierter Funktionsvergleich

FeatureZXing.NetIronBarcode
Lektüre
Thread-sicheres LesenNein – Instanzen pro Thread erforderlichJa – statische, zustandslose API
Automatische FormaterkennungNein — PossibleFormats erforderlichJa – alle Formate wurden automatisch erkannt.
Mehrere Barcodes pro BildJa — DecodeMultipleJa – Standardverhalten
PDF-Barcode-LesenNein – externe Bibliothek erforderlichJa – einheimische
Wiederherstellung beschädigter BarcodesTryHarder-FlaggeML-gestützte Bildkorrektur
Geschwindigkeits-/GenauigkeitsabstimmungFormatlistenreduzierungReadingSpeed-Enum
Generation
Code 128 / Code 39JaJa
QR-CodeJaJa
QR-Code mit LogoNeinJa
Farbanpassung des QR-CodesNeinJa
Ausgabe in PNG/JPEG/PDFManuell über System.DrawingEingebaute Ausgabemethoden
Fluent-GenerationenketteNeinJa
Plattform und Bereitstellung
Windows (System.Zeichnen)Ja — ZXing.Net.Bindings.Windows.CompatibilityJa
Linux / DockerJa —ZXing.Net.Bindings.ImageSharp / .V2 / .V3(verschiedene API)Ja – dieselbe API.
macOSJa — ZXing.Net.Bindings.ImageSharp / .V2 / .V3Ja
Docker zusätzliche AbhängigkeitenKann libgdiplus erfordernNone
Einzelnes NuGet-PaketNein – Kern + Bindung + optionales ImageSharpJa
Lizenzierung und Support
LizenztypApache 2.0Kommerziell
KostenKostenlosVon $999
Unterstützung durch die GemeinschaftGitHub Probleme, aktive CommunityJa
Unterstützung für kommerzielle SLAsNeinJa
Open-Source-freundlichJaNein

Thread-Sicherheit und gleichzeitige Verarbeitung

Die Thread-Sicherheit ist der wichtigste operative Unterschied zwischen den beiden Bibliotheken und betrifft mehr Projekte, als die Warnungen in der Dokumentation vermuten lassen.

ZXing .NET -Ansatz

ZXing.Net's BarcodeReader ist ein zustandsbehaftetes Objekt. Wenn Decode aufgerufen wird, wird der interne Zustand geschrieben. Wenn zwei Threads dieselbe Instanz verwenden, kommt es zu einem Wettlauf um die Schreibvorgänge. Die Ergebnisse sind nicht deterministisch: Sie können ein Ergebnis von einem anderen Bild erhalten, ein Nullwert, wo ein Barcode vorhanden ist, oder eine Ausnahme. Der korrekte Ansatz besteht darin, pro Thread einen Reader zu erstellen – das heißt, jeder parallele oder asynchrone Pfad allokiert einen Reader, konfiguriert ihn, verwendet ihn einmal und verwirft ihn anschließend:

// ZXing.Net: one reader instance per parallel operation
Parallel.ForEach(imagePaths, path =>
{
    var reader = new BarcodeReader();
    reader.Options.PossibleFormats = new List<BarcodeFormat>
    {
        BarcodeFormat.QR_CODE,
        BarcodeFormat.CODE_128,
        BarcodeFormat.EAN_13
    };

    using var bitmap = new Bitmap(path);
    var result = reader.Decode(bitmap);

    if (result != null)
        results[path] = result.Text;
});

Das ThreadLocal<BarcodeReader>-Muster verringert die Allokation pro Aufruf, indem ein Leser pro Thread wiederverwendet wird, fügt jedoch Komplexität bei der Freigabe hinzu und erfordert weiterhin die Formatkonfiguration bei jeder Instanz.

IronBarcode Ansatz

IronBarcode's BarcodeReader.Read ist eine zustandslose statische Methode. Es gibt keine Instanz zum Teilen, keine Instanz zum Isolieren und keinen Konfigurationsstatus zum Schützen. Derselbe Aufruf kann von beliebig vielen gleichzeitig laufenden Threads sicher ausgeführt werden:

// IronBarcode: static method — no instance management
var options = new BarcodeReaderOptions
{
    Speed = ReadingSpeed.Balanced,
    ExpectMultipleBarcodes = true,
    MaxParallelThreads = 4
};

Parallel.ForEach(imagePaths, path =>
{
    var result = BarcodeReader.Read(path, options).FirstOrDefault();
    if (result != null)
        results[path] = result.Value;
});

Die Dokumentation von IronBarcode zum asynchronen und multithreadfähigen Barcode-Lesen erläutert das interne Thread-Pooling-Modell. Die MaxParallelThreads-Eigenschaft steuert den Grad der Parallelisierung ohne externe Koordination.

Formaterkennung

Die Formaterkennungsrichtlinie ist der zweite wesentliche operative Unterschied zwischen den beiden Bibliotheken.

ZXing .NET -Ansatz

ZXing.Net erfordert, dass reader.Options.PossibleFormats vor jedem Dekodieren befüllt wird. Wenn ein Barcode-Format nicht aufgeführt ist, wird es nicht erkannt – ohne Fehlermeldung, Warnung oder Teilergebnis:

// ZXing.Net: PossibleFormats list controls which symbologies are decoded
var reader = new BarcodeReader();
reader.Options.PossibleFormats = new List<BarcodeFormat>
{
    BarcodeFormat.QR_CODE,
    BarcodeFormat.CODE_128,
    BarcodeFormat.CODE_39,
    BarcodeFormat.EAN_13,
    BarcodeFormat.EAN_8,
    BarcodeFormat.UPC_A,
    BarcodeFormat.DATA_MATRIX,
    BarcodeFormat.PDF_417
};
reader.Options.TryHarder = true;

using var bitmap = new Bitmap(imagePath);
var results = reader.DecodeMultiple(bitmap);

Wenn jedes Format aufgelistet wird, um Fehler zu vermeiden, verschlechtert sich die Leistung. Werden nur die erwarteten Formate aufgeführt, besteht die Gefahr, dass Bilder aus externen Quellen unbemerkt fehlen. Für ZXing .NET gibt es keinen Mechanismus, um zu melden, dass ein Barcode in einem nicht aufgeführten Format gefunden wurde.

IronBarcode Ansatz

IronBarcode erkennt alle über 50 unterstützten Formate automatisch. Es ist keine Formatliste erforderlich oder akzeptiert:

// IronBarcode: automatic detection across all supported formats
var results = BarcodeReader.Read(imagePath);
foreach (var barcode in results)
{
    Console.WriteLine($"{barcode.Value} ({barcode.Format})");
}

Für Anwendungen, die die Lesegeschwindigkeit gegen die Erkennungsgründlichkeit anpassen, bietet IronBarcode ein ReadingSpeed-Enum — Faster, Balanced, Detailed, ExtremeDetail — ohne Format-Aufzählung. Die Geschwindigkeitsabstimmung beeinflusst, wie aggressiv die Engine jedes Bild verarbeitet, nicht, welche Formate sie berücksichtigt.

PDF-Dokumentunterstützung

Das Lesen von PDFs stellt in ZXing .NET eine strikte Grenze dar: Die Bibliothek bietet keinerlei PDF-Unterstützung.

ZXing .NET -Ansatz

Wenn ein Barcode in eine PDF-Datei eingebettet ist, benötigt ZXing .NET eine externe PDF-Rendering-Bibliothek. Die gebräuchlichste Umgehungslösung verwendet PdfiumViewer, was etwa 20 MB an nativen Binärdateien und eine Seitenrendering-Schleife hinzufügt, die Aufrufer implementieren und warten müssen:

// ZXing.Net: PDF input is handled by PdfiumViewer with a per-page render loop
using var pdfDocument = PdfDocument.Load(pdfPath);

var reader = new BarcodeReader();
reader.Options.PossibleFormats = new List<BarcodeFormat>
{
    BarcodeFormat.QR_CODE,
    BarcodeFormat.CODE_128,
    BarcodeFormat.PDF_417
};

for (int i = 0; i < pdfDocument.PageCount; i++)
{
    string tempPath = Path.Combine(Path.GetTempPath(), $"{Guid.NewGuid()}.png");
    try
    {
        using var pageImage = pdfDocument.Render(i, 200, 200, PdfRenderFlags.CorrectFromDpi);
        pageImage.Save(tempPath, ImageFormat.Png);

        using var bitmap = new Bitmap(tempPath);
        var decoded = reader.DecodeMultiple(bitmap);
        if (decoded != null)
            results.AddRange(decoded.Select(d => d.Text));
    }
    finally
    {
        File.Delete(tempPath);
    }
}

Dieses Muster birgt echte Fehlerquellen: Fehlkonfigurationen der DPI-Ebene führen zu unbemerkten Fehlern, temporäre Dateiberechtigungen versagen in abgesicherten Umgebungen, die nativen Bibliotheken von PdfiumViewer erfordern ein separates Bereitstellungsmanagement, und die Einrichtung funktioniert unter Linux ohne zusätzliche Konfiguration nicht.

IronBarcode Ansatz

IronBarcode liest Barcodes nativ aus PDFs – alle Seiten, alle Formate, keine externen Abhängigkeiten. Der gleiche BarcodeReader.Read-Aufruf akzeptiert direkt PDF-Pfade:

// IronBarcode: one call processes every page of the PDF
var results = BarcodeReader.Read("invoice.pdf");
foreach (var barcode in results)
    Console.WriteLine($"Page {barcode.PageNumber}: {barcode.Value}");

Keine Seitenaufzählung, keine DPI-Konfiguration, keine temporären Dateien und keine separate Bibliothek, die zusammen mit der Anwendung bereitgestellt werden muss.

Plattformbindungen und Bereitstellung

Die Bildverarbeitung von ZXing.Net ist auf plattformspezifische Bindungspakete verteilt, von denen jedes über eine eigene API-Oberfläche verfügt.

ZXing .NET -Ansatz

Das Kernpaket ZXing.Net bietet Dekodierungslogik, aber kein Bildladen. Aufrufer müssen eine Bindung basierend auf ihrem Bereitstellungsziel auswählen:

UmfeldPaketNotizen
Windows-Desktop / WPFZXing.Net.Bindings.Windows.CompatibilityVerwendet System.Drawing — Windows-freundlich; benötigt libgdiplus auf Linux
Linux / Docker/plattformübergreifendZXing.Net.Bindings.ImageSharp / .V2 / .V3Unterschiedliche API-Oberfläche; fügt SixLabors.ImageSharp-Abhängigkeit hinzu (V2/V3 verfolgt wichtige ImageSharp-Versionen)
macOSZXing.Net.Bindings.ImageSharp / .V2 / .V3Gleicher Pfad wie unter Linux

Die praktische Konsequenz ist, dass Windows-Code, der System.Drawing.Bitmap verwendet, auf Linux nicht kompiliert oder ausgeführt wird. Die Containerisierung erfordert den Wechsel der Bindungspakete und das Umschreiben des Codes zum Laden von Bildern:

// Windows binding path — uses System.Drawing
using ZXing.Windows.Compatibility;
using System.Drawing;

var reader = new BarcodeReader();
using var bitmap = new Bitmap(imagePath);
var result = reader.Decode(bitmap);
// Cross-platform path — different package, different API
using ZXing.ImageSharp;
using SixLabors.ImageSharp;
using SixLabors.ImageSharp.PixelFormats;

var reader = new BarcodeReader<Rgba32>();
using var image = Image.Load<Rgba32>(imagePath);
var result = reader.Decode(image);

Die Verwendung der Windows-Bindung auf einem Linux-Host erfordert auch libgdiplus im Docker-Image und fügt dem Container etwa 50 MB hinzu.

IronBarcode Ansatz

IronBarcode liefert ein Paket für alle Plattformen. Der gleiche BarcodeReader.Read(path)-Aufruf wird identisch auf Windows, Linux, macOSund in Docker-Containern kompiliert und ausgeführt. Es werden keine Bindungspakete, keine Plattformbedingungen und keine zusätzlichen Systemabhängigkeiten benötigt. Für Teams, die .NET Anwendungen containerisieren, beschreibt der IronBarcode Docker- und Linux-Setup-Leitfaden das Single-Package-Deployment-Muster detailliert.

API-Generierung

Beide Bibliotheken generieren Barcodes, aber die APIs spiegeln unterschiedliche Designansätze wider.

ZXing .NET -Ansatz

ZXing.Net's BarcodeWriter-Klasse erstellt ein Schreibobjekt, akzeptiert Kodierungsoptionen, ruft Write auf und gibt ein Bitmap zurück, das vom Aufrufer manuell mithilfe von System.Drawing.Imaging gespeichert werden muss:

// ZXing.Net: create writer, set options, call Write, save Bitmap
using ZXing;
using ZXing.Common;
using ZXing.Windows.Compatibility;
using System.Drawing.Imaging;

var writer = new BarcodeWriter
{
    Format = BarcodeFormat.CODE_128,
    Options = new EncodingOptions
    {
        Width = 300,
        Height = 100,
        Margin = 10
    }
};

using var bitmap = writer.Write("PRODUCT-001");
bitmap.Save("output.png", ImageFormat.Png);

Das Speichern in anderen Formaten als PNG oder JPEG, das Speichern in einer PDF-Datei oder das Erzeugen von binärem Ausgabe für eine HTTP-Antwort erfordert zusätzliche System.Drawing-Plumbing, das der Aufrufer implementiert.

IronBarcode Ansatz

IronBarcode's BarcodeWriter.CreateBarcode gibt ein GeneratedBarcode-Objekt zurück, das eingebaute Ausgabemethoden über eine fluente Kette bereitstellt:

// IronBarcode: create and save in one fluent chain
BarcodeWriter.CreateBarcode("PRODUCT-001", BarcodeEncoding.Code128)
    .ResizeTo(300, 100)
    .SaveAsPng("output.png");

Das GeneratedBarcode-Objekt bietet auch .ToPngBinaryData(), .ToJpegBinaryData(), .ToStream() und .SaveAsPdf() — Ausgabeziele, die ZXing.Net erfordert, dass Aufrufer selbst mit System.Drawing implementieren.

API-Mapping-Referenz

ZXing.NetIronBarcodeNotizen
new BarcodeReader()Statisch – keine InstanzBarcodeReader.Read(...) ist ein statischer Aufruf
reader.Options.PossibleFormats = new List<BarcodeFormat> { ... }Nicht erforderlichDie automatische Erkennung deckt alle Formate ab.
reader.Options.TryHarder = trueSpeed = ReadingSpeed.BalancedGenauigkeitsanpassung über BarcodeReaderOptions
reader.Decode(bitmap)BarcodeReader.Read(imagePath)Pfad direkt übergeben — kein Bitmap erforderlich
reader.DecodeMultiple(bitmap)BarcodeReader.Read(imagePath)Gibt immer eine Sammlung zurück
result.Textresult.ValueImmobilie umbenannt
result.BarcodeFormatresult.FormatImmobilie umbenannt
BarcodeFormat.QR_CODEBarcodeEncoding.QRCodeÄnderung der Namenskonvention für Enumerationen
BarcodeFormat.CODE_128BarcodeEncoding.Code128Änderung der Namenskonvention für Enumerationen
BarcodeFormat.EAN_13BarcodeEncoding.EAN13Änderung der Namenskonvention für Enumerationen
new BarcodeWriter { Format = BarcodeFormat.CODE_128, Options = new EncodingOptions { ... } }BarcodeWriter.CreateBarcode(data, BarcodeEncoding.Code128)Statische Fabrikmethode
writer.Write(data) gibt Bitmap zurück.SaveAsPng(path) / .ToPngBinaryData()Eingebaute Ausgabemethoden auf GeneratedBarcode
Keine PDF-Unterstützung – PDFViewer erforderlichBarcodeReader.Read("doc.pdf")Native PDF-Unterstützung
Nicht gewindesicherThreadsichere statische APIKeine Instanzverwaltung erforderlich

Wenn Teams einen Wechsel von ZXing .NET zu IronBarcode erwägen

Mehrere Szenarien veranlassen Entwicklungsteams dazu, IronBarcode als Alternative zu ZXing .NET zu evaluieren.

Gleichzeitige und hocheffiziente Verarbeitung

Eine ZXing .NET Integration, die in einer Single-Thread-Konsolenanwendung korrekt funktioniert, kann nicht-deterministisches Verhalten zeigen, wenn derselbe Code in einen ASP.NET Core Controller verschoben wird, der gleichzeitige Anfragen verarbeitet, oder in einen Hintergrundjob, der Batches parallel verarbeitet. Das von ZXing .NET geforderte Instanzmuster pro Thread bedeutet, dass jede Anfrage oder parallele Aufgabe ein vollständiges Reader-Objekt mit dem zugehörigen konfigurierten Decodersatz zuweist, es einmal verwendet und anschließend verwirft. Mit zunehmendem Anfragevolumen wird dieser Zuteilungsdruck messbar. Teams, die diesen Punkt erreichen – insbesondere solche, die Scan-Pipelines mit hohem Durchsatz in den Bereichen Logistik, Lagerhaltung oder Dokumentenverarbeitung betreiben – suchen oft nach einer Bibliothek, deren Threading-Modell diesen Overhead nicht jedem Aufrufer auferlegt.

Scannen von Dokumenten in gemischten Formaten

Anwendungen, die Dokumente von Dritten akzeptieren, stoßen häufig auf Barcode-Formate, die bei der Konfiguration der Formatliste nicht berücksichtigt wurden. Eine für Code 128 entwickelte Versandintegration empfängt Sendungen von Partnern mittels QR-Codes. Ein medizinisches Dokumentationssystem, das für PDF 417-Begegnungen und Data Matrix-Symbologien eines neuen Geräteherstellers konfiguriert ist. In ZXing .NET führt jeder dieser Fälle zu einem stillen Nullwert anstelle eines Dekodierungsfehlers, was bedeutet, dass der Fehler möglicherweise erst bei einem Fehler in der nachfolgenden Verarbeitung sichtbar wird. Teams, die durch unbemerkte Formatfehler schlechte Erfahrungen gemacht haben – insbesondere in Kontexten, in denen ein übersehener Barcode geschäftliche Konsequenzen hat – beginnen, die Kosten der Formatlistenpflege gegen eine Bibliothek abzuwägen, die Formate automatisch erkennt.

PDF-Barcode-Extraktion

Viele Geschäftsdokumente kommen im PDF-Format an: Rechnungen, Versandmanifeste, Patientenakten, Konformitätsbescheinigungen. ZXing .NET kann diese nicht direkt lesen. Teams, die Barcodes aus PDFs extrahieren müssen, müssen letztendlich eine Rendering-Pipeline auf Basis von ZXing .NET aufbauen und pflegen – sie wählen eine PDF-Bibliothek aus, verwalten deren native Abhängigkeiten, implementieren eine Seitenrender-Schleife, handhaben die DPI-Konfiguration und schreiben eine Bereinigungslogik für temporäre Dateien. Dieser Infrastrukturcode ist keine Barcode-Logik; Es dient einzig und allein dazu, die Lücke zwischen dem, was ZXing .NET akzeptiert (Bitmaps), und dem, was Geschäftsdokumente tatsächlich sind (PDFs), zu schließen. Teams, die diese Brücke pflegen müssen – insbesondere wenn die PDF-Bibliothek selbst Lizenzierungs-, Bereitstellungs- und Plattformüberlegungen mit sich bringt – bevorzugen oft eine einzige Bibliothek, die die gesamte Eingabeoberfläche abdeckt.

Reduzierung der Bindungskomplexität

Projekte, die unter Windows gestartet und später auf Linux oder Docker bereitgestellt werden, stoßen direkt auf die Bindungsfragmentierung von ZXing.Net: Das Windows-Bindungspaket verwendet eine andere API als die plattformübergreifende ImageSharp-Bindung, und der Wechsel zwischen ihnen erfordert die Änderung sowohl der NuGet -Referenzen als auch des Bildladecodes. Teams, die ihre .NET Anwendungen routinemäßig containerisieren oder die gleiche Codebasis auf Entwicklerrechnern (Windows oder macOS) und Produktionsservern (Linux) ausführen, stellen fest, dass die Pflege zweier Codepfade für das Laden von Bildern jede zukünftige Änderung in der Scanschicht erschwert.

Gemeinsame Überlegungen zur Migration

Teams, die von ZXing .NET auf IronBarcode umsteigen, sollten diese spezifischen technischen Änderungen einplanen.

Entfernung der BarcodeReader-Instanziierung

Jeder new BarcodeReader()-Aufruf im Codebasis wird während der Migration entfernt. Das Instanziierungsmuster – Erstellung des Readers, Formatkonfiguration, Laden des Bildes, Dekodierungsaufruf – reduziert sich auf einen einzigen statischen Methodenaufruf. Dateien, die ZXing, ZXing.Common, ZXing.Windows.Compatibility, ZXing.ImageSharp und SixLabors.ImageSharp-Namespaces importieren, haben diese Importe entfernt und durch einen einzigen using IronBarCode; ersetzt.

Entfernung der Konfiguration "Mögliche Formate"

Der reader.Options.PossibleFormats-Zuweisungsblock wird bei jedem Aufrufort gelöscht. IronBarcode führt eine automatische Formaterkennung durch und akzeptiert keine Formatbeschränkungsliste. Das TryHarder-Flag wird durch die ReadingSpeed-Eigenschaft bei BarcodeReaderOptions ersetzt, die den Erkennungsaufwand steuert, ohne den Formatbereich einzuengen.

Bereinigung des Bindungspakets

Die Migration entfernt ZXing.Net, ZXing.Net.Bindings.Windows.Compatibility, alle ZXing.Net.Bindings.ImageSharp-Varianten (.V2 / .V3) und alle PdfiumViewer-Pakete, die hinzugefügt wurden, um das PDF-Lesen zu unterstützen. Wenn libgdiplus zu einem Dockerfile hinzugefügt wurde, um System.Drawing durch die Windows-Bindung auf Linux zu unterstützen, wird auch diese Zeile entfernt. IronBarcode benötigt im Docker-Image keine plattformspezifischen Abhängigkeiten.

Zusätzliche IronBarcode Funktionen

Über die in den obigen Vergleichsabschnitten beschriebenen Funktionen hinaus bietet IronBarcode Folgendes:

  • QR-Code mit Logoeinbettung : Generieren Sie QR-Codes mit einem benutzerdefinierten Logobild in der Mitte, mit automatischer Fehlerkorrektur zur Gewährleistung der Scanbarkeit.
  • Anpassung der QR-Code-Farben : Legen Sie Vorder- und Hintergrundfarben für generierte QR-Codes fest, um ein markenkonformes Erscheinungsbild zu gewährleisten.
  • Barcode-Aufdruck auf PDFs : Barcodes direkt auf bestehende PDF-Seiten an festgelegten Koordinaten schreiben, ohne eine separate PDF-Bibliothek zu benötigen.
  • GS1-Barcode-Unterstützung : Lesen und Generieren von GS1-formatierten Barcodes, einschließlich GS1-128 und GS1 DataBar, die in Lieferketten im Einzelhandel und im Gesundheitswesen verwendet werden.
  • Multithread-Async-Lesen: Eingebaute asynchrone Methoden zur Integration von Barcode-Lesen in await-Pipelines ohne Blockieren.
  • ML-gestützte Bildkorrektur: Automatische Bildverbesserung für beschädigte, verschwommene oder kontrastarme Barcodes, die TryHarder nicht wiederherstellen kann.

.NET-Kompatibilität und Zukunftsfähigkeit

IronBarcode zielt auf .NET Standard 2.0 und höher ab und bietet Kompatibilität mit .NET Framework 4.6.2+, .NET Core 3.1, .NET 5, .NET 6, .NET 7, .NET 8 und .NET 9. Die Bibliothek erhält regelmäßige Updates, die mit Microsofts .NET-Veröffentlichungszyklus übereinstimmen, um sicherzustellen, dass die Kompatibilität mit .NET 10 bei oder nahe der Veröffentlichung verfügbar sein wird. ZXing .NET gewährleistet zudem durch seine NuGet -Paketziele eine breite .NET Kompatibilität, und beide Bibliotheken eignen sich aus dieser Perspektive für moderne .NET Projekte.

Abschluss

ZXing .NET und IronBarcode repräsentieren unterschiedliche Philosophien im Design von Barcode-Bibliotheken. ZXing .NET ist eine zustandsbehaftete, instanzbasierte Bibliothek, die die Thread-Verantwortung, die Formatspezifikation und die PDF-Überbrückung vollständig an den Aufrufer delegiert. IronBarcode ist eine zustandslose Bibliothek mit statischer API, die Threading intern implementiert, Formate automatisch erkennt und PDF-Eingaben nativ verarbeitet. Die praktische Konsequenz dieses Unterschieds ist, dass ZXing .NET Code in Kontexten der Parallelverarbeitung oder Dokumentenverarbeitung dazu neigt, Infrastruktur anzusammeln – pro Thread Instanzmuster, Formatlisten, PDF-Rendering-Pipelines und plattformspezifische Bindungszweige –, während IronBarcode -Code für die gleichen Szenarien keine dieser umgebenden Strukturen benötigt.

ZXing .NET ist eine wirklich gute Wahl für Projekte, die keine Kosten erfordern. Dank der Apache 2.0-Lizenz ist es sowohl mit Open-Source-Projekten als auch mit kommerziellen Produkten kompatibel, die freie Abhängigkeiten bevorzugen. In kontrollierten Umgebungen – bekannten Barcode-Formaten, sauberen Bildern, Single-Thread- oder leicht paralleler Verarbeitung – arbeitet es zuverlässig. Die aktive GitHub Community reagiert zeitnah auf Probleme, und die Bandbreite der abgedeckten Formate ist mit kommerziellen Alternativen vergleichbar. Bei Anwendungen, bei denen diese Bedingungen erfüllt sind, ist der Kostenvorteil von ZXing.Net real und seine technischen Einschränkungen sind beherrschbar.

IronBarcode befasst sich mit Szenarien, in denen die Designbeschränkungen von ZXing.Net zu Betriebskosten führen: gleichzeitige Web-APIs, bei denen die Instanzzuweisung pro Anfrage messbar ist, Dokumentenpipelines, bei denen PDF-Eingabe die Norm und nicht die Ausnahme ist, Scannen in gemischten Formaten, bei dem stillschweigende Fehler ein Geschäftsrisiko darstellen, und plattformübergreifende Bereitstellungen, bei denen zwei Bindungspakete zwei Codepfade bedeuten. Für diese Kontexte erwirbt die kommerzielle Lizenz der Bibliothek ein Threading-Modell, das keine Instanzverwaltung erfordert, eine Formaterkennung, die keine Wartung benötigt, und eine PDF-Unterstützung, die keine zweite Bibliothek erfordert.

Die Entscheidung hängt von den Anforderungen des Projekts ab. Ein Prototyp in einem einzigen Format, ein Open-Source-Scanner oder ein Tool für geringe Stückzahlen, bei dem die Kosten den größten Einfluss haben – in solchen Fällen ist ZXing .NET die richtige Wahl. Eine produktive Web-API, die Dokumente aus externen Quellen über mehrere Threads verarbeitet – hier decken sich die Designannahmen von IronBarcode mit der betrieblichen Realität. Für einen umfassenderen Überblick darüber, wie sich die Bibliotheken hinsichtlich Erkennungsraten und realen Scan-Szenarien vergleichen lassen, bietet der Vergleich der Barcode-Scanner ZXing .NET und IronBarcode zusätzliche Analysen.

Curtis Chau
Technischer Autor

Curtis Chau hat einen Bachelor-Abschluss in Informatik von der Carleton University und ist spezialisiert auf Frontend-Entwicklung mit Expertise in Node.js, TypeScript, JavaScript und React. Leidenschaftlich widmet er sich der Erstellung intuitiver und ästhetisch ansprechender Benutzerschnittstellen und arbeitet gerne mit modernen Frameworks sowie der Erstellung gut strukturierter, optisch ansprechender Handbücher.

...
Weiterlesen

Verwandte Artikel

Key in blue circle

Holen Sie sich sofort Ihren kostenlosen 30-Tage-Testschlüssel.

Your trial license will be sent to your email address

Keine Einschränkungen. 100 % freigeschaltet. Keine Kreditkarte.

bullet_checkedIhr Testlizenzschlüssel wurde Ihnen per E-Mail gesendet.Keine Einschränkungen. 100 % freigeschaltet. Keine Kreditkarte.
  • Logo Aetna
  • Logo NASA
  • Logo GE
  • Logo Porsche
  • Logo USDA
  • Logo Qatar
Join Millions of Engineers who’ve tried IronPDF
AWS-Logo
Booking Badge

Von Millionen von Ingenieur*innen weltweit vertraut

Azure (WebApps, Funktionen v3)
Erhalten Sie Ihre unverbindliche Beratung
Füllen Sie das Formular unten aus oder senden Sie eine E-Mail an sales@ironsoftware.com
Ihre Daten werden immer vertraulich behandelt.
Von Millionen von Ingenieur*innen weltweit vertraut
Azure (WebApps, Funktionen v3)
Erhalten Sie sofort Ihren kostenlosen 30-Tage-Testschlüssel.
Ihr Testlizenzschlüssel wurde Ihnen per E-Mail gesendet.