Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
바코드 생성기가 원본 값과 다르게 스캔되는 오류를 겪은 사례와 해결책을 공유합니다. 바코드가 기술적으로 유효하더라도, 스캐너가 특정 문자를 시작 코드로 오해하여 데이터 해석에 오류가 발생할 수 있습니다. 이를 방지하기 위해 체크섬 검증 및 Raw 모드 선택 기능을 추가했습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기지난달에 제가 운영하는 QR/바코드 생성기로 재미있는 오류를 겪었습니다. 한 사용자가 창고 선반의 빈(bin)을 위한 Code 128 라벨로 'BIN-7742-A'를 만들어 달라고 요청했습니다. 깨끗한 ASCII 문자열이었고, 사양 범위 내에 있었으며, 특이한 것은 전혀 없었습니다. 제가 생성하고, 그들이 인쇄하여 선반에 붙였습니다. 2주 후 창고 관리자가 스캐너가 '삑' 소리를 내며 _아몬드_를 불러온다고 불평했습니다.
알고 보니 저는 바코드의 원본 값으로 BIN-7742-A를 생성했지만, 스캐너는 선두의 'B'를 Code Set B에서 Code 128 시작 문자로 해석하여 모든 후속 데이터를 이동시켰습니다. 숫자 '7742'는 다른 코드 세트 컨텍스트에 놓였고, 끝의 '-A'는 그들의 재고 시스템에서 제품 코드로 디코딩되었습니다. 이 라벨은 기술적으로 유효한 Code 128이었지만, 잘못된 문자열을 인코딩했을 뿐입니다.
수정 방법은 지루하고 올바른 방식이었습니다. 저는 생성기에 체크섬 문자(mod 103)를 추가하여 라벨이 자체 검증되도록 했고, 이제 호출자가 명시적으로 Raw 모드를 선택하지 않는 한 페이로드(payload)가 제어 코드처럼 오해될 수 있는 문자로 시작하는 바코드는 발행하기를 거부합니다. 또한 API 응답에서 인코딩된 값과 디코딩된 값을 모두 표시하여 사람이 (또는 에이전트가) 인쇄 전에 불일치를 발견할 수 있도록 했습니다.
교훈: 스캔되는 바코드와 의도한 대로 스캔되는 바코코드는 다릅니다. 형식 사양(format spec)은 스캐너가 보는 것을 정의할 뿐, 사용자가 의도한 것을 정의하지 않습니다. 저는 체크섬 검증과 Raw 모드 선택 기능을 추가한 수정된 생성기를 여기서 패키징했습니다: [https://x402.freeq.one/tools/qr_generator.html]
혹시 다른 사람들도 심볼로지(symbology)의 엣지 케이스를 만난 적이 있는지 궁금합니다. EAN-13 체크 숫자는 같은 종류의 문제입니다. 다만 더 시끄러울 뿐입니다.