Barcode 체크섬을 검증하고 C#에서 형식 인식 읽기 사용 방법

This article was translated from English: Does it need improvement?
Translated
View the article in English

바코드 체크섬은 치환 오류를 감지하는 데 도움이 됩니다. 예를 들어, EAN-13 라벨에서 숫자 하나만 잘못 입력되어도 소포가 잘못된 창고로 배송될 수 있습니다. 형식 인식 읽기는 디코더를 예상되는 심볼로 제한함으로써 추가적인 유효성 검사 계층을 제공합니다. 이 접근 방식은 배경 소음으로 인한 오탐을 줄이고 불필요한 형식 감지기를 건너뛰어 스캔 시간을 단축합니다.

IronBarcode 디코딩 중에 체크섬 검증을 자동으로 수행합니다. 각 심볼 체계의 검사 숫자 알고리즘은 기본적으로 실행되며, 검사에 실패한 바코드는 결과가 반환되기 전에 폐기됩니다. BarcodeReaderOptions.ExpectBarcodeTypes 속성은 읽기를 특정 형식으로 제한하는 반면, RemoveFalsePositive는 모호한 읽기에 대한 2차 스캔을 추가합니다.

이 가이드에서는 바코드 체크섬을 검증하고, 읽기를 예상 형식으로 제한하고, BarcodeReaderOptions를 사용하여 두 기술을 계층형 품질 게이트로 결합하는 방법을 설명합니다.

빠른 시작: 바코드 검증을 체크섬과 형식 제약을 사용하여 수행

자동 체크섬 검증을 통해 읽기 작업을 예상되는 심볼로 제한하려면 BarcodeReaderOptionsExpectBarcodeTypesRemoveFalsePositive와 함께 구성하십시오.

:path=/static-assets/barcode/content-code-examples/how-to/checksum-and-format-validation/quickstart.cs
using IronBarCode;

// Format-constrained read with false-positive removal.
// Limit the decoder to EAN-13 and Code128; checksums are
// validated automatically and failures are silently discarded.
var options = new BarcodeReaderOptions
{
    ExpectBarcodeTypes  = BarcodeEncoding.EAN13 | BarcodeEncoding.Code128,
    RemoveFalsePositive = true,
    Speed               = ReadingSpeed.Balanced
};

BarcodeResults results = BarcodeReader.Read("label.png", options);
$vbLabelText   $csharpLabel

바코드 체크섬을 검증하는 방법은 무엇인가요?

IronBarcode 각 심볼 규격에 따라 디코딩 중에 체크섬을 검증합니다. 예를 들어, EAN-13 바코드를 읽을 때 모드10 검사 숫자는 처음 12자리 숫자를 사용하여 계산한 다음 13번째 자리 숫자와 비교합니다. 숫자가 일치하지 않으면 바코드는 아무런 경고 없이 거부되고 BarcodeResults 컬렉션에 나타나지 않습니다. 이 접근 방식은 UPC-A, UPC-E, EAN-8, 코드128, ITF 등을 포함하여 필수 검사 숫자가 있는 모든 형식에 적용됩니다.

이 내재된 모델은 명시적 토글을 노출하는 라이브러리와 다릅니다. 아래 표는 두 가지 접근 방식을 비교합니다:

체크섬 유효성 검사 모델 비교: IronBarcode vs. Aspose.BarCode
측면IronBarcodeAspose.BarCode
검증 트리거자동 실행; 모든 디코딩 과정에서 실행됩니다.명시적 설정: 체크섬Validation.On 켜기/ Off / Default
개발자 작업 필요해당 사항 없음; 유효하지 않은 바코드는 결과에서 제외됩니다.읽기 전에 BarcodeSettings.체크섬Validation 설정하세요.
체크섬 비활성화노출되지 않음; 필수 형식의 경우 체크섬이 항상 적용됩니다.예, 체크섬Validation.Off 검증을 건너뛰도록 설정합니다.
선택적 체크섬 형식 (코드39)ConfidenceRemoveFalsePositive 사용하여 품질이 낮은 리드를 필터링합니다.Enable체크섬.예 사용하여 명시적으로 활성화합니다.
실패 동작바코드가 결과에서 조용히 생략됨바코드에는 수동 검사를 위한 별도의 체크섬 값이 표시될 수 있습니다.

코드39와 같이 체크섬이 선택적인 심볼의 경우, 라이브러리는 체크섬 토글 대신 신뢰도 점수와 RemoveFalsePositive를 사용합니다.

입력

코드128 창고 랙 라벨(성공 경로)과 바코드가 없는 빈 이미지(실패 경로).

코드128 barcode encoding RACK-A1-LOT-7382 used as the warehouse rack scan input

창고랙.png (성공 경로)

Blank white image with no barcode to trigger the empty result path

blank-no-barcode.png (실패 경로 - 바코드 없음)

:path=/static-assets/barcode/content-code-examples/how-to/checksum-and-format-validation/checksum-confidence.cs
using IronBarCode;

// Constrain reads to 1D formats and enable secondary verification.
// ConfidenceThreshold rejects decodes where the ML detector falls below 85%,
// acting as a quality gate for optional-checksum symbologies like Code39.
var options = new BarcodeReaderOptions
{
    ExpectBarcodeTypes  = BarcodeEncoding.AllOneDimensional,
    RemoveFalsePositive = true,
    ConfidenceThreshold = 0.85,
    Speed               = ReadingSpeed.Detailed
};

BarcodeResults results = BarcodeReader.Read("warehouse-rack.png", options);

foreach (BarcodeResult result in results)
{
    // Each result has passed checksum validation (mandatory formats)
    // and the 85% confidence threshold, so no additional filtering is needed.
    Console.WriteLine($"[{result.BarcodeType}] {result.Value}  page={result.PageNumber}");
}

if (results.Count == 0)
{
    Console.Error.WriteLine("No valid barcodes found. Possible causes:");
    Console.Error.WriteLine("  - Check digit mismatch (barcode silently rejected)");
    Console.Error.WriteLine("  - Confidence below 85% threshold");
    Console.Error.WriteLine("  - Format not in ExpectBarcodeTypes");
}
$vbLabelText   $csharpLabel

산출

성공 경로

콘솔 출력에는 코드128 RACK-A1-LOT-7382가 신뢰도 임계값 이상으로 디코딩된 것으로 표시됩니다.

창고 랙 바코드가 0페이지에서 RACK-A1-LOT-7382로 반환되었습니다. 85% 신뢰도 임계값을 충족하고 체크섬 유효성 검사를 통과했으므로 BarcodeResults에 표시됩니다.

실패 경로

콘솔 출력에

ConfidenceThreshold 값을 기본값인 0.7보다 높게 설정하면 코드39와 같은 선택적 체크섬 심볼에 대한 제한이 더욱 강화됩니다.

체크섬 유효성 검사가 완료되었으므로 다음 단계는 파이프라인에서 요구하는 바코드 형식만 판독할 수 있도록 제한하는 것입니다.


형식 인식 바코드 읽기 사용 방법은 무엇인가요?

BarcodeEncoding 열거형은 비트 OR 연산자를 사용하여 여러 형식을 결합할 수 있는 플래그 유형입니다. ExpectBarcodeTypes 설정을 사용하면 리더가 해당 형식으로만 읽을 수 있도록 제한하고 다른 형식은 감지하지 않습니다.

일반적인 BarcodeEncoding 값
범주설명체크섬
BarcodeEncoding.All메타지원되는 모든 형식(기본 동작)개별 형식
BarcodeEncoding.AllOneDimensional메타적층형을 포함한 모든 선형 (1D) 형식개별 형식
BarcodeEncoding.AllTwoDimensional메타모든 매트릭스/그리드 (2D) 형식개별 형식
BarcodeEncoding.코드1281D고밀도 영숫자(물류, 배송)필수 (가중 모드103)
BarcodeEncoding.EAN131D소매 제품 식별 번호(13자리)필수 (모드10)
BarcodeEncoding.QRCode2D대용량 매트릭스(URL, 구조화된 데이터)리드-솔로몬 ECC
BarcodeEncoding.코드391D영숫자 (방위, 자동차)선택적 (모드43)
BarcodeEncoding.UPCA1D북미 소매 판매액 (12자리 숫자)필수 (모드10)
BarcodeEncoding.DataMatrix2D컴팩트 매트릭스(전자, 제약)리드-솔로몬 ECC
BarcodeEncoding.PDF4172D쌓인 (신분증, 교통카드)리드-솔로몬 ECC

속도 외에도, 형식 세트를 제한하는 것은 유효성 검사 관문 역할을 합니다. 목록에 없는 심볼의 바코드는 이미지에 물리적으로 존재하더라도 결과에서 제외됩니다.

입력

코드128 배송 라벨(성공 경로)과 코드128 전용 제약 조건과 일치하지 않는 QR 코드(실패 경로).

코드128 barcode encoding SHIP-2024-00438 used as the shipping label input

shipping-label.png (성공 경로 — 코드 128이 제약 조건과 일치함)

QR code used as the format-mismatch failure path for the 코드128-only constrained read

QR 형식 불일치.png (실패 경로 - 코드128 전용 필터에 의해 QR 코드가 거부됨)

:path=/static-assets/barcode/content-code-examples/how-to/checksum-and-format-validation/format-constrained.cs
using IronBarCode;

// Constrained read: only Code128 barcodes are returned.
// Faster because the reader skips all other format detectors.
var constrainedOptions = new BarcodeReaderOptions
{
    ExpectBarcodeTypes     = BarcodeEncoding.Code128,
    Speed                  = ReadingSpeed.Faster,
    ExpectMultipleBarcodes = false
};

// Broad read: all supported formats are scanned.
// Useful for verification or when the image format is unknown.
var broadOptions = new BarcodeReaderOptions
{
    ExpectBarcodeTypes     = BarcodeEncoding.All,
    Speed                  = ReadingSpeed.Detailed,
    ExpectMultipleBarcodes = true
};

string imagePath = "shipping-label.png";

BarcodeResults constrained = BarcodeReader.Read(imagePath, constrainedOptions);
Console.WriteLine($"Constrained: {constrained.Count} Code128 barcode(s) found");

BarcodeResults broad = BarcodeReader.Read(imagePath, broadOptions);
Console.WriteLine($"Broad: {broad.Count} barcode(s) found across all formats");

foreach (BarcodeResult result in broad)
{
    Console.WriteLine($"  [{result.BarcodeType}] {result.Value}");
}
$vbLabelText   $csharpLabel

산출

성공 경로

콘솔 출력에는 제한된 읽기에서 코드128 바코드 1개를 찾았고 이를 확인하는 광범위한 읽기 결과가 표시됩니다.

배송 라벨의 값은 SHIP-2024-00438입니다. 제한된 읽기는 필터가 예상하는 코드128을 즉시 감지하며, 광범위한 읽기는 모든 형식에서 동일한 결과를 확인시켜 줍니다.

실패 경로

QR 코드 이미지에 대해 제한된 읽기 작업이 0개의 결과를 반환함을 보여주는 콘솔 출력

제한된 읽기에서 결과가 비어 있는 것은 오류가 아니라 유효성 검사 신호입니다. 차이점을 기록하여 검토하도록 하십시오.

바코드 유형이 혼합된 파이프라인(예: EAN-13 제품 코드와 코드128 추적 번호가 모두 포함된 포장 명세서)의 경우 예상되는 형식을 결합하십시오.

:path=/static-assets/barcode/content-code-examples/how-to/checksum-and-format-validation/multi-format-combine.cs
using IronBarCode;

// Combine multiple format flags with | to scan for more than one symbology
// in a single pass. Each BarcodeResult.BarcodeType identifies which format
// was decoded, enabling downstream routing logic per symbology.
var options = new BarcodeReaderOptions
{
    ExpectBarcodeTypes     = BarcodeEncoding.EAN13 | BarcodeEncoding.Code128,
    ExpectMultipleBarcodes = true
};
$vbLabelText   $csharpLabel

반환된 각 BarcodeResult.BarcodeType는 디코딩된 형식을 식별하여 하위 라우팅을 가능하게 합니다.

어떤 심볼로지가 체크섬 검증을 지원합니까?

모든 바코드 형식이 체크섬을 동일한 방식으로 사용하지는 않습니다. 다음 표는 일반적인 심볼과 해당 오류 감지 특성을 연결한 것으로, 각 형식에 대해 ConfidenceThresholdRemoveFalsePositive를 얼마나 적극적으로 설정해야 하는지 알려줍니다.

심볼로지별 체크섬 특성
기호체계체크섬 유형필수인가요?추천
EAN-13 / EAN-8모드10기본 설정으로 충분합니다. 체크섬은 항상 적용됩니다.
UPC-A / UPC-E모드10기본 설정으로 충분합니다. 쓰기 시 검사 숫자가 자동으로 수정됩니다.
코드128가중 모드103기본 설정으로 충분하며, 사양에 따라 필수 사항입니다.
코드39모드43선택 사항신뢰 임계값을 0.8 이상으로 올리고 RemoveFalsePositive를 활성화하세요
코다바르모드16선택 사항코드39와 동일하게 신뢰도를 품질 검증 기준으로 사용합니다.
ITF모드10선택 사항순차 형식에 대해 RemoveFalsePositive 활성화
QR코드 / 데이터 매트릭스리드-솔로몬 ECC언제나구조적 오류 수정; 추가 설정 불필요
PDF417리드-솔로몬 ECC언제나QR/DataMatrix와 마찬가지로 오류 수정 기능이 내장되어 있습니다.

QR, DataMatrix, PDF417과 같은 2D 심볼의 경우 오류 수정 기능이 인코딩 구조에 통합되어 있습니다. 이러한 형식은 간단한 검사 숫자에 의존하지 않고도 부분적인 손상으로부터 복구할 수 있습니다. ConfidenceThreshold는 ML 감지 단계에서도 여전히 적용되는 반면, 디코딩 단계는 심볼에 내장된 중복성을 활용합니다.

이제 두 가지 기법을 모두 이해했으니, 이들을 결합하여 실제 운영 환경에서 바로 사용할 수 있는 검증 패턴을 만들어 보겠습니다.


체크섬을 형식 제약과 결합하는 방법은?

프로덕션 준비 패턴은 ExpectBarcodeTypes, RemoveFalsePositive, ConfidenceThresholdSpeed를 단일 BarcodeReaderOptions 객체에 설정합니다. 이들은 함께 계층형 게이트를 형성합니다. 형식 제약 조건은 검색 공간을 좁히고, 체크섬 유효성 검사는 데이터 무결성을 보장하며, 신뢰도 임계값 설정은 불완전한 디코딩을 필터링하고, 오탐 제거는 2차 검증 단계를 추가합니다.

입력

성공 경로로 사용된 것은 pos-scans/ 디렉터리의 POS 스캔 바코드 3개입니다. 이 중 2개는 EAN-13이고 1개는 UPC-A입니다. 코드128 창고 랙 라벨은 오류 경로로 사용됩니다. EAN-13/UPC-A 제약 조건으로 인해 해당 라벨이 거부되고 REJECT 줄이 기록됩니다.

EAN-13 barcode encoding 5901234123471 used as POS scan input 1

pos-scan-1.png (성공)

EAN-13 barcode encoding 4006381333931 used as POS scan input 2

pos-scan-2.png (성공)

UPC-A barcode encoding 012345678905 used as POS scan input 3

pos-scan-3.png (성공)

코드128 barcode encoding RACK-A1-LOT-7382 used as the combined-validation failure path input

warehouse-rack.png (실패 — 코드 128 거부됨)

:path=/static-assets/barcode/content-code-examples/how-to/checksum-and-format-validation/combined-validation.cs
using IronBarCode;

// Layered validation for retail POS: EAN-13, UPC-A, and UPC-E only.
// Each property adds a distinct filter to the read pipeline.
var options = new BarcodeReaderOptions
{
    // Layer 1: format constraint, accept only retail symbologies
    ExpectBarcodeTypes = BarcodeEncoding.EAN13 | BarcodeEncoding.UPCA | BarcodeEncoding.UPCE,

    // Layer 2: confidence threshold, reject decodes below 80%
    ConfidenceThreshold = 0.8,

    // Layer 3: false-positive removal, runs a secondary verification pass
    RemoveFalsePositive = true,

    Speed                  = ReadingSpeed.Balanced,
    ExpectMultipleBarcodes = false,

    // Require 3 agreeing scan lines to reduce phantom reads from noisy images
    MinScanLines = 3
};

string[] scanFiles = Directory.GetFiles("pos-scans/", "*.png");

foreach (string file in scanFiles)
{
    BarcodeResults results = BarcodeReader.Read(file, options);

    if (results.Count == 0)
    {
        // No barcode passed all validation layers
        Console.Error.WriteLine($"REJECT {Path.GetFileName(file)}: "
            + "no valid EAN-13/UPC barcode (checksum, confidence, or format mismatch)");
        continue;
    }

    BarcodeResult primary = results.First();

    // Post-read assertion: verify the decoded format matches expectations.
    // ExpectBarcodeTypes already constrains the reader; this check documents
    // intent and surfaces unexpected results during future changes.
    if (primary.BarcodeType != BarcodeEncoding.EAN13
        && primary.BarcodeType != BarcodeEncoding.UPCA
        && primary.BarcodeType != BarcodeEncoding.UPCE)
    {
        Console.Error.WriteLine($"UNEXPECTED FORMAT {Path.GetFileName(file)}: "
            + $"got {primary.BarcodeType}, expected EAN-13/UPC");
        continue;
    }

    Console.WriteLine($"OK {Path.GetFileName(file)}: [{primary.BarcodeType}] {primary.Value}");
}
$vbLabelText   $csharpLabel

산출

성공 경로

콘솔 출력에는 3개의 POS 스캔 바코드가 모두 OK 상태와 디코딩된 값으로 승인되었음을 보여줍니다.

POS 스캔 이미지 세 장 모두 정상적으로 전송되었습니다. 리더는 5901234123471, 4006381333931, 012345678905 값을 반환했습니다. 각각은 EAN13과 일치했습니다. | UPCA | UPCE 필터는 유효한 모드10 체크섬을 가지고 있었고 신뢰도는 0.8 이상이었습니다.

실패 경로

콘솔 출력에는 창고 랙의 코드128 바코드가 EAN-13/UPC-A 필터에 의해 거부되었음을 보여줍니다.

MinScanLines 값을 3으로 설정하면 1D 바코드가 유효하려면 필요한 최소 일치 스캔 라인 수가 증가합니다. 기본값은 2입니다. 이 값을 높이면 노이즈가 있는 스캔 라인으로 인한 잘못된 판독 위험이 줄어들지만, 얇거나 부분적으로 손상된 바코드를 놓칠 수 있습니다. 깨끗하게 인쇄된 라벨이 있는 소매 POS 환경에서는 3이라는 값이 처리량에 영향을 주지 않으면서 유효성 검사를 강화하는 보수적인 선택입니다.

읽기 후 BarcodeType 어설션은 심층 방어입니다. ExpectBarcodeTypes는 이미 필터링 기능을 제공하지만, 명시적인 검사를 통해 의도를 문서화하고 런타임 비용 없이 구성 변경을 감지할 수 있습니다. 속도 최적화를 위해 ReadingSpeed.Faster는 깔끔하게 기계로 인쇄된 라벨에 적합합니다. DetailedExtremeDetail는 스캔 시간이 더 오래 걸리는 대신 손상되었거나 조명이 불량한 바코드를 복구합니다.


내 다음 단계는 무엇인가요?

이 글에서는 IronBarcode의 암묵적 체크섬 유효성 검사 모델, 형식 제약이 있는 읽기를 위한 BarcodeEncoding 플래그 열거형, 그리고 ExpectBarcodeTypes, ConfidenceThreshold, RemoveFalsePositive, MinScanLines를 계층화된 품질 게이트로 사용하는 결합 유효성 검사 패턴에 대해 다루었습니다.

추가 읽기를 위해 이 리소스를 탐색하세요:

라이브 환경에서 모든 기능을 테스트할 수 있는 무료 체험판 라이선스를 얻으세요, 또는 파이프라인이 생산 준비가 되었을 때 라이선스 옵션을 보세요.

자주 묻는 질문

바코드 체크섬 검증이란 무엇인가요?

바코드 체크섬 검증은 바코드 데이터의 정확성을 보장하기 위해 계산된 체크섬을 바코드 내에 인코딩된 값과 비교하는 과정입니다. 이는 스캐닝 중 오류를 감지하는 데 도움이 됩니다.

IronBarcode는 체크섬 검증을 어떻게 처리하나요?

IronBarcode는 바코드 데이터의 체크섬을 계산하고 인코딩된 체크섬과 비교하여 스캐닝 중 데이터 무결성을 보장하며 암시적으로 체크섬 검증을 다룹니다.

BarcodeEncoding 필터란 무엇인가요?

IronBarcode의 BarcodeEncoding 필터는 스캐닝 중 읽거나 무시할 바코드 형식을 지정하게 하여 특정 바코드 유형에 집중함으로써 더 정확하고 효율적인 바코드 처리가 가능하도록 합니다.

IronBarcode는 결합 검증을 수행할 수 있나요?

네, IronBarcode는 스캐닝 도중 체크섬과 바코드 포맷을 모두 검토하여 올바르고 적절히 형식화된 바코드만 처리되도록 함으로써 결합된 검증을 수행할 수 있습니다.

C#에서 IronBarcode를 사용하여 바코드 읽기를 포맷으로 제한할 수 있나요?

네, IronBarcode는 포함하거나 제외할 형식을 지정하여 적용할 수 있으며, 이는 애플리케이션이 관련 있는 바코드 유형만 처리하게 합니다.

바코드 처리에서 포맷 인식 읽기가 중요한 이유는 무엇인가요?

포맷 인식 읽기가 중요합니다 왜냐하면 이를 통해 애플리케이션이 특정한 유형의 바코드만 처리하게 되므로, 속도와 정확도를 향상시키고 관련이 없거나 지원하지 않는 바코드 형식을 무시할 수 있습니다.

IronBarcode에서 포맷 인식 읽기를 어떻게 구현하나요?

IronBarcode에서 포맷 인식 읽기를 구현하려면 BarcodeEncoding 필터를 사용하여 읽고자 하는 바코드 형식을 지정합니다. 이는 라이브러리의 API를 통해서 가능하며, 바코드 스캔 요구 사항에 대해 정확한 제어가 가능합니다.

바코드 검증을 위해 IronBarcode를 사용하는 이점은 무엇인가요?

IronBarcode는 강력한 체크섬 검증, 포맷 인식 읽기, 넓은 범위의 바코드 표준 지원 등을 통해 바코드 처리에서 높은 정확성과 유연성을 제공합니다.

다리우스 세란트
풀스택 소프트웨어 엔지니어 (웹 운영)

다리우스 세런트는 마이애미 대학교에서 컴퓨터 과학 학사 학위를 받았으며, Iron Software에서 풀 스택 웹 운영 마케팅 엔지니어로 근무하고 있습니다. 어린 시절부터 코딩에 매료되었던 그는 컴퓨팅이 신비로우면서도 접근하기 쉬운 분야라고 생각했고, 창의력과 문제 해결 능력을 발휘하기에 완벽한 매체라고 여겼습니다.

Iron Software에서 다리우스는 새로운 것을 만들고 복잡한 개념을 단순화하여 더 쉽게 이해할 수 있도록 하는 것을 즐깁니다. 그는 사내 개발자로서 학생들을 가르치는 데에도 자원하여 차세대 인재들과 전문 지식을 공유하고 있습니다.

다리우스에게 있어 그의 일은 가치 있고 실질적인 영향을 미치기 때문에 보람 있는 일입니다.

시작할 준비 되셨나요?
Nuget 다운로드 2,121,847 | 버전: 2026.3 방금 출시되었습니다
Still Scrolling Icon

아직도 스크롤하고 계신가요?

빠른 증거를 원하시나요? PM > Install-Package BarCode
샘플을 실행하세요 실이 바코드로 변하는 모습을 지켜보세요.