IRONSOFTWAREHOME
COMPARAR CON OTROS COMPONENTES

ZXing.Net vs IronBarcode: Elegir una biblioteca de códigos de barras .NET en 2026

Curtis Chau
Curtis Chau
Updated: 1 de agosto de 2026

ZXing.Net's BarcodeReader no es seguro para hilos. Cada ruta de lectura concurrente en su aplicación — cada ForEach paralelo, cada acción de controlador asíncrona que maneja solicitudes simultáneas — requiere su propia instancia de lector. Eso significa configuración de formato repetida por instancia, carga y disposición de Bitmap por llamada, y asignación de lector en cada solicitud. El método estático de IronBarcode maneja el mismo trabajo sin asignación por solicitud. La seguridad de los subprocesos es solo uno de los puntos de la lista: la falta de compatibilidad nativa con PDF, la fragmentación de los paquetes de enlace entre Windows y Linux, y la necesidad de especificar cada formato de código de barras que se pretende escanear; estas son las características que provocan que los proyectos .NET con ZX acumulen soluciones alternativas con el tiempo.

Comprender ZXing .NET

ZXing .NET es una adaptación de código abierto de la biblioteca Java ZXing ("Zebra Crossing") de Google, publicada bajo la licencia Apache 2.0y mantenida por Michael Jahn en GitHub. Es la biblioteca de códigos de barras de código abierto más descargada para .NET, con una larga trayectoria que se remonta a más de una década. La biblioteca abarca tanto la lectura como la escritura en una amplia gama de formatos de códigos de barras, y su licencia gratuita la hace accesible para proyectos de todos los tamaños, incluidos los productos de código abierto que requieren dependencias compatibles con Apache.

La arquitectura de ZXing.Net refleja sus orígenes como una adaptación de Java. La clase BarcodeReader es un objeto con estado: llamar a Decode escribe estado interno, lo que hace que las instancias no sean seguras para compartir entre hilos. El uso concurrente correcto requiere ya sea un nuevo lector por hilo o un grupo de ThreadLocal<BarcodeReader> — ambos de los cuales colocan la responsabilidad de seguridad de hilos en el llamador. La carga de imágenes tampoco está incluida en el paquete principal; En cambio, ZXing .NET proporciona paquetes de enlace específicos para cada plataforma, cada uno de los cuales expone una interfaz API diferente.

Las características arquitectónicas clave incluyen:

  • Licencia Apache 2.0: Gratuita para uso comercial y de código abierto, sin coste alguno y sin necesidad de contactar con el departamento de ventas.
  • Lector de Códigos de Barra con Estado: La instancia de BarcodeReader no es segura para hilos; Se debe crear una nueva instancia por cada hilo o por cada operación paralela.
  • Especificación Manual de Formato: Los llamadores deben establecer reader.Options.PossibleFormats antes de cada decodificación; Los formatos que no aparecen en la lista se omiten silenciosamente sin ningún error ni advertencia.
  • Sin soporte nativo para PDF: la biblioteca solo lee imágenes; La entrada de archivos PDF requiere una biblioteca de renderizado de PDF independiente, como PdfiumViewer, para convertir las páginas en mapas de bits antes de la decodificación.
  • Fragmentación de la vinculación de la plataforma: el paquete principal no proporciona carga de imágenes; paquetes de vinculación separados (ZXing.Net.Bindings.Windows.Compatibility usando System.Drawing,ZXing.Net.Bindings.ImageSharp / .V2 / .V3usando SixLabors.ImageSharp, además de ZXing.Net.Bindings.SkiaSharp y ZXing.Net.Bindings.Magick) exponen diferentes APIs para diferentes objetivos de implementación.
  • Comunidad activa: Los problemas, las solicitudes de extracción y los debates son activos en GitHub, lo que proporciona soporte a nivel de comunidad sin coste alguno.
  • Amplia compatibilidad de formatos: Admite códigos QR, Code 128, Code 39, EAN-13, EAN-8, UPC-A, Data Matrix, PDF 417, Aztec y otras simbologías de uso común.

La arquitectura del lector estatal

El BarcodeReader de ZXing.Net requiere una nueva instancia para cada hilo u operación paralela. El siguiente patrón muestra la configuración mínima correcta para el procesamiento concurrente:

// 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;
});

El patrón ThreadLocal<BarcodeReader> reduce la asignación por llamada reutilizando una instancia por hilo, pero agrega complejidad de disposición. De cualquier forma, la seguridad de hilos es responsabilidad del llamador en ZXing.Net.

Entendiendo IronBarcode

IronBarcode es una biblioteca comercial de códigos de barras .NET desarrollada por Iron Software. Proporciona lectura y generación de códigos de barras a través de una API estática sin estado: BarcodeReader.Read y BarcodeWriter.CreateBarcode son los puntos de entrada principales, y ninguno requiere creación o configuración de instancias antes de su uso. La biblioteca se distribuye como un único paquete NuGet que se ejecuta de forma idéntica en Windows, Linux, macOSy dentro de contenedores Docker sin necesidad de paquetes de enlace específicos de la plataforma.

El motor de lectura de IronBarcode realiza una detección automática del formato en más de 50 simbologías de códigos de barras. Quienes llaman no especifican qué formatos buscar; El motor evalúa cada imagen comparándola con todos los formatos compatibles y devuelve todos los códigos de barras encontrados. Para aplicaciones que necesitan equilibrar la velocidad de escaneo con la exhaustividad, un enum ReadingSpeed (Faster, Balanced, Detailed, ExtremeDetail) brinda control sin requerir enumeración de formato. La biblioteca también incluye compatibilidad nativa con PDF, lo que permite leer códigos de barras directamente desde documentos PDF en todas las páginas sin necesidad de una biblioteca de renderizado de PDF independiente.

Las características clave incluyen:

  • Licencia comercial: Requiere una clave de licencia de pago; El modo de prueba está disponible para su evaluación.
  • API Estática Sin Estado: BarcodeReader.Read y BarcodeWriter.CreateBarcode son métodos estáticos seguros para hilos; No se requiere administración de instancias.
  • Detección automática de formato: Se detectan los más de 50 formatos de código de barras compatibles sin necesidad de una lista de formatos; los usuarios priorizan la velocidad en lugar del alcance del formato.
  • Soporte Nativo de PDF: BarcodeReader.Read acepta rutas de archivos PDF directamente, procesando todas las páginas sin una biblioteca PDF externa.
  • Paquete único multiplataforma: Un único paquete NuGet se ejecuta en Windows, Linux, macOSy Docker con la misma interfaz API.
  • API de Generación Fluida: BarcodeWriter.CreateBarcode devuelve un objeto GeneratedBarcode con métodos de salida integrados que incluyen SaveAsPng, SaveAsPdf, ToPngBinaryData, y ToStream.
  • Soporte comercial: Las licencias de pago incluyen acceso al equipo de soporte de Iron Software con compromisos de nivel de servicio.

Comparación de características

La siguiente tabla destaca las diferencias fundamentales entre ZXing .NET e IronBarcode:

CaracterísticaZXing.NetIronBarcode
LicenciaApache 2.0(gratuito)Comercial
Seguridad de hilosNo es seguro para subprocesos: se requiere una nueva instancia por cada subproceso.API estática segura para subprocesos
Detección de formatoManual — lista de PossibleFormats requeridaAutomático: más de 50 formatos
Lectura de PDFNo — requiere PdfiumViewer o similarNativo: llamada a un solo método
Soporte de PlataformaPaquetes de enlace separados por plataformaPaquete único, todas las plataformas
Generación de códigos de barrasDevuelve Bitmap, requiere guardado manualAPI fluida con salida integrada
PreciosGratisDesde $999 (Lite) / $1,499 (Plus)

Comparación detallada de características

CaracterísticaZXing.NetIronBarcode
Lectura
Lectura segura para subprocesosNo, se requieren instancias por hilo.Sí, API estática sin estado
Detección automática de formatoNo — PossibleFormats requeridoSí, todos los formatos se detectan automáticamente.
Varios códigos de barras por imagenSí — DecodeMultipleSí — comportamiento predeterminado
Lectura de códigos de barras PDFNo — se requiere biblioteca externaSí, nativo
Recuperación de códigos de barras dañadosbandera TryHarderCorrección de imágenes mediante aprendizaje automático
Ajuste de velocidad/precisiónReducción de lista de formatoenum ReadingSpeed
Generación
Código 128 / Código 39
Código QR
Código QR con logotipoNo
Personalización del color del código QRNo
Salida a PNG/JPEG/PDFManual vía System.DrawingMétodos de salida integrados
Cadena de generación fluidaNo
Plataforma y despliegue
Ventanas (Dibujo del sistema)Sí — ZXing.Net.Bindings.Windows.Compatibility
Linux / DockerSí —ZXing.Net.Bindings.ImageSharp / .V2 / .V3(API diferente)Sí, la misma API.
macOSSí — ZXing.Net.Bindings.ImageSharp / .V2 / .V3
Dependencias adicionales de DockerPuede requerir libgdiplusNone
Paquete NuGet únicoNo — núcleo + enlace + ImageSharp opcional
Licencias y soporte
Tipo de licenciaApache 2.0Comercial
CosteGratisA partir de 749
Apoyo de la comunidadProblemas en GitHub , comunidad activa
Soporte para SLA comercialesNo
Compatible con el código abiertoNo

Seguridad de subprocesos y procesamiento concurrente

La seguridad de los subprocesos es la diferencia operativa más importante entre las dos bibliotecas, y afecta a más proyectos de lo que podrían sugerir las advertencias de la documentación.

Enfoque ZXing .NET

El BarcodeReader de ZXing.Net es un objeto con estado. Cuando se llama a Decode, se escribe el estado interno. Si dos hilos comparten la misma instancia, se produce una condición de carrera en las escrituras. Los resultados no son deterministas: puede obtener un resultado de una imagen diferente, un valor nulo donde existe un código de barras o una excepción. El enfoque correcto consiste en crear un lector por hilo, lo que significa que cada ruta paralela o asíncrona asigna un lector, lo configura, lo usa una vez y lo descarta:

// 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;
});

El patrón ThreadLocal<BarcodeReader> reduce la asignación por llamada reutilizando un lector por hilo, pero agrega complejidad de disposición y todavía requiere configuración de formato en cada instancia.

Enfoque IronBarcode

El BarcodeReader.Read de IronBarcode es un método estático sin estado. No hay ninguna instancia que compartir, ninguna instancia que aislar y ningún estado de configuración que proteger. La misma llamada se ejecuta de forma segura desde cualquier número de hilos concurrentes:

// 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;
});

La documentación de IronBarcode sobre la lectura de códigos de barras asíncrona y multihilo explica el modelo interno de agrupación de hilos. La propiedad MaxParallelThreads controla el grado de paralelismo sin requerir coordinación externa.

Detección de formato

La política de detección de formato es la segunda diferencia operativa significativa entre las dos bibliotecas.

Enfoque ZXing .NET

ZXing.Net requiere que reader.Options.PossibleFormats esté poblado antes de cada decodificación. Si un formato de código de barras no aparece en la lista, no se detectará, sin error, sin advertencia y sin resultado parcial:

// 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);

Si se enumeran todos los formatos para evitar omisiones, el rendimiento se degrada. Si solo se enumeran los formatos esperados, existe el riesgo de que se produzcan errores silenciosos cuando las imágenes provienen de fuentes externas. ZXing .NET no dispone de ningún mecanismo para informar de que ha encontrado un código de barras en un formato no listado.

Enfoque IronBarcode

IronBarcode detecta automáticamente los más de 50 formatos compatibles. No se requiere ni se acepta ninguna lista de formatos:

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

Para aplicaciones que ajustan la velocidad de lectura contra la exhaustividad de detección, IronBarcode expone un enum ReadingSpeedFaster, Balanced, Detailed, ExtremeDetail — sin requerir enumeración de formato. La optimización de la velocidad afecta a la agresividad con la que el motor procesa cada imagen, no a los formatos que considera.

Compatibilidad con documentos PDF

La lectura de archivos PDF es una limitación insalvable en ZXing .NET: la biblioteca no ofrece ningún tipo de soporte para PDF.

Enfoque ZXing .NET

Cuando un código de barras llega incrustado en un PDF, ZXing .NET requiere una biblioteca externa de renderizado de PDF. La solución alternativa más común utiliza PdfiumViewer, que añade aproximadamente 20 MB de binarios nativos y un bucle de renderizado de página que los usuarios deben implementar y mantener:

// 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);
    }
}

Este patrón presenta modos de fallo reales: una configuración incorrecta de DPI provoca fallos silenciosos, los permisos de archivos temporales fallan en entornos restringidos, las bibliotecas nativas de PdfiumViewer requieren una gestión de implementación independiente y la configuración no funciona en Linux sin una configuración adicional.

Enfoque IronBarcode

IronBarcode lee códigos de barras de archivos PDF de forma nativa : todas las páginas, todos los formatos, sin dependencias externas. La misma llamada BarcodeReader.Read acepta rutas de PDF directamente:

// 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}");

Sin enumeración de páginas, sin configuración de DPI, sin archivos temporales y sin biblioteca independiente para implementar junto con la aplicación.

Enlaces de plataforma e implementación

El manejo de imágenes de ZXing.Net se distribuye entre paquetes de enlace específicos de la plataforma, cada uno con una interfaz API diferente.

Enfoque ZXing .NET

El paquete central ZXing.Net proporciona lógica de decodificación pero no carga de imagen. Los usuarios deben elegir un enlace en función de su destino de implementación:

AmbientePaqueteNotas
Escritorio de Windows / WPFZXing.Net.Bindings.Windows.CompatibilityUsa System.Drawing — compatible con Windows; necesita libgdiplus en Linux
Linux / Docker/multiplataformaZXing.Net.Bindings.ImageSharp / .V2 / .V3Superficie API diferente; añade la dependencia SixLabors.ImageSharp (V2/V3 sigue las versiones principales de ImageSharp)
macOSZXing.Net.Bindings.ImageSharp / .V2 / .V3El mismo camino que en Linux.

La consecuencia práctica es que el código de Windows usando System.Drawing.Bitmap no se compila ni se ejecuta en Linux. La contenerización requiere cambiar los paquetes de enlace y reescribir el código de carga de imágenes:

// 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);

Usar la vinculación de Windows en un host Linux también requiere libgdiplus en la imagen de Docker, añadiendo aproximadamente 50 MB al contenedor.

Enfoque IronBarcode

IronBarcode envía un único paquete para todas las plataformas. La misma llamada BarcodeReader.Read(path) se compila y corre de forma idéntica en Windows, Linux, macOSy dentro de contenedores Docker. No se requieren paquetes de enlace, ni condicionales de plataforma, ni dependencias de sistema adicionales. Para los equipos que utilizan contenedores para aplicaciones .NET , la guía de configuración de Docker y Linux de IronBarcode cubre en detalle el patrón de implementación de paquete único.

API de generación

Ambas bibliotecas generan códigos de barras, pero sus API reflejan enfoques de diseño diferentes.

Enfoque ZXing .NET

La clase BarcodeWriter de ZXing.Net crea un objeto escritor, acepta opciones de codificación, llama a Write, y retorna un Bitmap que los llamadores deben guardar manualmente usando System.Drawing.Imaging:

// 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);

Guardar en formatos distintos a PNG o JPEG, guardar en un PDF o producir salida binaria para una respuesta HTTP requieren una plomería adicional de System.Drawing que el llamador implementa.

Enfoque IronBarcode

El BarcodeWriter.CreateBarcode de IronBarcode devuelve un objeto GeneratedBarcode que proporciona métodos de salida integrados a través de una cadena fluida:

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

El objeto GeneratedBarcode también expone .ToPngBinaryData(), .ToJpegBinaryData(), .ToStream(), y .SaveAsPdf() — objetivos de salida que ZXing.Net requiere que los llamadores implementen ellos mismos usando System.Drawing.

Referencia de mapeo de API

ZXing.NetIronBarcodeNotas
new BarcodeReader()Estático: ninguna instanciaBarcodeReader.Read(...) es una llamada estática
lector.Opciones.FormatosPosibles = nueva lista<BarcodeFormat> { ... }No es necesarioLa detección automática cubre todos los formatos.
reader.Options.TryHarder = trueSpeed = ReadingSpeed.BalancedAjuste de precisión vía BarcodeReaderOptions
reader.Decode(bitmap)BarcodeReader.Read(imagePath)Pase ruta directamente — no se necesita Bitmap
reader.DecodeMultiple(bitmap)BarcodeReader.Read(imagePath)Siempre devuelve una colección
result.Textresult.ValuePropiedad renombrada
result.BarcodeFormatresult.FormatPropiedad renombrada
BarcodeFormat.QR_CODEBarcodeEncoding.QRCodeCambio en la convención de nomenclatura de enumeraciones
BarcodeFormat.CODE_128BarcodeEncoding.Code128Cambio en la convención de nomenclatura de enumeraciones
BarcodeFormat.EAN_13BarcodeEncoding.EAN13Cambio en la convención de nomenclatura de enumeraciones
new BarcodeWriter { Format = BarcodeFormat.CODE_128, Options = new EncodingOptions { ... } }BarcodeWriter.CreateBarcode(data, BarcodeEncoding.Code128)Método de fábrica estática
writer.Write(data) devuelve Bitmap.SaveAsPng(path) / .ToPngBinaryData()Métodos de salida integrados en GeneratedBarcode
No admite archivos PDF; requiere PdfiumViewer.BarcodeReader.Read("doc.pdf")Compatibilidad nativa con PDF
No es seguro para subprocesosAPI estática segura para subprocesosNo se necesita administración de instancias

Cuando los equipos consideran pasar de ZXing .NET a IronBarcode

Diversos escenarios llevan a los equipos de desarrollo a evaluar IronBarcode como una alternativa a ZXing .NET.

Procesamiento concurrente y de alto rendimiento

Una integración de ZXing .NET que funciona correctamente en una aplicación de consola de un solo hilo puede presentar un comportamiento no determinista cuando el mismo código se traslada a un controlador ASP.NET Core que gestiona solicitudes concurrentes, o a un trabajo en segundo plano que procesa lotes en paralelo. El patrón de instancia por hilo que requiere ZXing .NET implica que cada solicitud o tarea paralela asigna un objeto lector completo con su conjunto de decodificadores configurado, lo usa una vez y lo descarta. A medida que aumenta el volumen de solicitudes, esta presión de asignación se vuelve cuantificable. Los equipos que llegan a este punto, en particular aquellos que gestionan sistemas de escaneo de alto rendimiento en logística, almacenamiento o procesamiento de documentos, suelen buscar una biblioteca cuyo modelo de subprocesos no imponga esta sobrecarga a cada usuario.

Escaneo de documentos de formato mixto

Las aplicaciones que aceptan documentos de terceros suelen encontrarse con formatos de código de barras que no se previeron al configurar la lista de formatos. Una integración de envíos creada para Code 128 recibe un envío de un socio mediante códigos QR. Un sistema de registros médicos configurado para encuentros PDF 417 con simbologías Data Matrix de un nuevo proveedor de equipos. En ZXing .NET, cada uno de estos casos produce un valor nulo silencioso en lugar de un error de decodificación, lo que significa que el fallo puede no manifestarse hasta que falle el procesamiento posterior. Los equipos que han sufrido las consecuencias de errores de formato silenciosos, especialmente en contextos donde un código de barras omitido tiene repercusiones comerciales, comienzan a sopesar el coste del mantenimiento de la lista de formatos frente a una biblioteca que detecta los formatos automáticamente.

Extracción de códigos de barras PDF

Muchos documentos comerciales llegan en formato PDF: facturas, manifiestos de envío, historiales de pacientes, certificados de cumplimiento. ZXing .NET no puede leerlos directamente. Los equipos que necesitan extraer códigos de barras de archivos PDF terminan creando y manteniendo una canalización de renderizado sobre ZXing .NET : seleccionando una biblioteca de PDF, gestionando sus dependencias nativas, implementando un bucle de renderizado de página, manejando la configuración de DPI y escribiendo lógica de limpieza para archivos temporales. Ese código de infraestructura no es lógica de código de barras; Su única función es salvar la brecha entre lo que ZXing .NET acepta (mapas de bits) y lo que realmente son los documentos comerciales (PDF). Los equipos que se ven obligados a mantener este puente, especialmente cuando la propia biblioteca de PDF tiene sus propias consideraciones sobre licencias, implementación y plataforma, suelen preferir una única biblioteca que gestione toda la superficie de entrada.

Reducción de la complejidad de la unión

Los proyectos que se inician en Windows y posteriormente se implementan en Linux o Docker se topan directamente con la fragmentación de enlaces de ZXing.Net: el paquete de enlace de Windows utiliza una API diferente a la del enlace multiplataforma ImageSharp, y cambiar entre ellos requiere modificar tanto las referencias de NuGet como el código de carga de imágenes. Los equipos que, por práctica habitual, utilizan contenedores para sus aplicaciones .NET , o que ejecutan el mismo código fuente en máquinas de desarrollo (Windows o macOS) y servidores de producción (Linux), descubren que mantener dos rutas de código para la carga de imágenes añade fricción a cada cambio futuro en la capa de escaneo.

Consideraciones comunes sobre la migración

Los equipos que estén migrando de ZXing .NET a IronBarcode deben planificar estos cambios técnicos específicos.

Eliminación de instancias de lector de códigos de barras

Cada llamada new BarcodeReader() en la base de código se elimina durante la migración. El patrón de instanciación —creación del lector, configuración del formato, carga de la imagen, llamada de decodificación— se reduce a una única llamada a un método estático. Los archivos que importan los espacios de nombres de ZXing, ZXing.Common, ZXing.Windows.Compatibility, ZXing.ImageSharp, y SixLabors.ImageSharp tienen esas importaciones eliminadas y reemplazadas por un solo using IronBarCode;.

Eliminación de la configuración de PossibleFormats

El bloque de asignación reader.Options.PossibleFormats se elimina en cada sitio de llamada. IronBarcode realiza detección automática de formatos y no acepta una lista de restricción de formatos. La bandera TryHarder es reemplazada por la propiedad ReadingSpeed en BarcodeReaderOptions, que controla el esfuerzo de detección sin reducir el alcance del formato.

Limpieza del paquete de encuadernación

La migración elimina ZXing.Net, ZXing.Net.Bindings.Windows.Compatibility, cualquier variante ZXing.Net.Bindings.ImageSharp (.V2 / .V3), y cualquier paquete PdfiumViewer que se haya añadido para soportar la lectura de PDF. Si libgdiplus fue añadido a un Dockerfile para soportar System.Drawing a través de la vinculación de Windows en Linux, esa línea también es eliminada. IronBarcode no requiere dependencias específicas de la plataforma en la imagen de Docker.

Funcionalidades adicionales de IronBarcode

Además de las funcionalidades descritas en las secciones comparativas anteriores, IronBarcode ofrece:

Compatibilidad con .NET y preparación para el futuro

IronBarcode apunta a .NET Standard 2.0 y superiores, ofreciendo compatibilidad con .NET Framework 4.6.2+, .NET Core 3.1, .NET 5, .NET 6, .NET 7, .NET 8, y .NET 9. La biblioteca recibe actualizaciones regulares alineadas con el ciclo de lanzamiento de .NET de Microsoft, asegurando que la compatibilidad con .NET 10 estará disponible en o cerca del lanzamiento. ZXing .NET también mantiene una amplia compatibilidad con .NET a través de sus destinos de paquetes NuGet , y ambas bibliotecas son adecuadas para proyectos .NET modernos desde esta perspectiva.

Conclusión

ZXing .NET e IronBarcode representan filosofías diferentes en el diseño de bibliotecas de códigos de barras. ZXing .NET es una biblioteca con estado, basada en instancias, que delega la responsabilidad de la gestión de subprocesos, la especificación del formato y la conversión a PDF completamente al usuario. IronBarcode es una biblioteca sin estado y con API estática que internaliza el manejo de hilos, detecta formatos automáticamente y gestiona la entrada de archivos PDF de forma nativa. La consecuencia práctica de esta diferencia es que la codificación ZX del código .NET en contextos concurrentes o de procesamiento de documentos tiende a acumular infraestructura (patrones de instancias por hilo, listas de formatos, canalizaciones de renderizado de PDF y ramas de enlace específicas de la plataforma), mientras que el código IronBarcode para los mismos escenarios no requiere ninguna de esas estructuras circundantes.

ZXing .NET es una opción realmente sólida para proyectos con requisitos de coste cero. Su licencia Apache 2.0la hace compatible con proyectos de código abierto y con productos comerciales que prefieren dependencias libres. En entornos controlados —formatos de código de barras conocidos, imágenes nítidas, procesamiento de un solo hilo o concurrente ligero— su rendimiento es fiable. Su activa comunidad en GitHub proporciona respuestas oportunas a los problemas, y la amplitud de su cobertura de formatos es comparable a la de las alternativas comerciales. Para las aplicaciones en las que se cumplen esas condiciones, la ventaja de costes de ZXing.Net es real y sus limitaciones técnicas son manejables.

IronBarcode aborda los escenarios en los que las limitaciones de diseño de ZXing.Net se convierten en costes operativos: API web concurrentes donde la asignación de instancias por solicitud es medible, flujos de documentos donde la entrada de PDF es la norma en lugar de la excepción, escaneo de formatos mixtos donde los fallos silenciosos conllevan riesgos para el negocio y despliegues multiplataforma donde dos paquetes de enlace significan dos rutas de código. Para esos contextos, la licencia comercial de la biblioteca proporciona un modelo de subprocesos que no impone la gestión de instancias, una detección de formato que no requiere mantenimiento y compatibilidad con PDF que no requiere una segunda biblioteca.

La decisión depende de los requisitos del proyecto. Un prototipo de formato único, un escáner de código abierto o una herramienta de bajo volumen donde el costo es la principal limitación: en estos casos, ZXing .NET es la opción adecuada. Una API web de producción que procesa documentos de fuentes externas en múltiples hilos: ahí es donde las premisas de diseño de IronBarcode se alinean con la realidad operativa. Para obtener una visión más amplia de cómo se comparan las bibliotecas en cuanto a tasas de detección y escenarios de escaneo del mundo real, la comparación de escáneres de códigos de barras ZXing .NET vs IronBarcode proporciona un análisis adicional.

Curtis Chau
Escritor Técnico

Curtis Chau tiene una licenciatura en Ciencias de la Computación (Carleton University) y se especializa en el desarrollo front-end con experiencia en Node.js, TypeScript, JavaScript y React. Apasionado por crear interfaces de usuario intuitivas y estéticamente agradables, disfruta trabajando con frameworks modernos y creando manuales bien estructurados y visualmente atractivos.

...
Leer más

Artículos Relacionados

Key in blue circle

Obtenga su clave de prueba gratuita de 30 días al instante.

Your trial license will be sent to your email address

Sin limitaciones. 100 % desbloqueado. Sin tarjeta de crédito.

bullet_checkedNo se requiere tarjeta de crédito ni creación de cuentaSin limitaciones. 100 % desbloqueado. Sin tarjeta de crédito.
  • Logo Aetna
  • Logo NASA
  • Logo GE
  • Logo Porsche
  • Logo USDA
  • Logo Qatar
Join Millions of Engineers who’ve tried IronPDF
Reserve su Demostración en Vivo gratuita
Booking Badge

Confiado por millones de ingenieros en todo el mundo

Logos de clientes de Iron Software
Obtén tu Consulta Sin Compromiso
Completa el formulario a continuación o envía un correo a sales@ironsoftware.com
Tus detalles siempre serán mantenidos confidenciales.
Confiado por millones de ingenieros en todo el mundo
Logos de clientes de Iron Software
Obtenga su Clave de Prueba de 30 días gratis al instante.
No se requiere tarjeta de crédito ni creación de cuenta