在工作中遇到了这个一个问题，我们的APP中有扫描条形码的功能，但是最近由用户反应扫描条形码查询不到信息，到数据库中查了发现用户上传的条形码是以0开头的13位条形码。

随后根据用户的描述，在某东上找到了该商品的条形码（上图），发现该条形码只有12位而使用我们的APP扫描得到的条形码却是0300087234016，不难看出其实前面多出了一个0。

这好办啊！删掉0就好了嘛！然而之前对条形码并不是很了解，扫描条码也只是直接调用了Apple提供的AVFoundation框架，万一真的有0开头的条形码而却粗暴地将第一位的0删掉了那岂不是又将会酿成大祸？抱着严谨的态度，我查找了不少关于AVFoundation以及条形码的资料。

从某度百科的“条形码”词条中对条形码的类别有了初步的了解，在常见的条形码中，UPC-A码长度是12位的，EAN13码长度是13位的，然后我在AVFoundation的文档中发现了这一段注释。

/*!
@constant AVMetadataObjectTypeEAN13Code
@abstract An identifier for an instance of AVMetadataMachineReadableCodeObject having a type AVMetadataObjectTypeEAN13Code.
@discussion
AVMetadataMachineReadableCodeObject objects generated from EAN-13 (**including UPC-A**) codes return this constant as their type.
*/
AVF_EXPORT NSString *const AVMetadataObjectTypeEAN13Code NS_AVAILABLE(NA, 7_0) __TVOS_PROHIBITED;

注意黑体字including UPC-A这个括号中的解释啊啊啊啊啊啊啊，苹果居然将UPC-A条码和EAN13条码放到了一起不做区分！这不是坑我嘛！万一EAN13码存在0开头的那我该怎么办？（当时的心声）

继续搜索资料发现自己逗比了，关于UPC-A与EAN13的资料
CSDN：http://blog.csdn.net/abcpanpeng/article/details/8130392

Note：实际上，一个UPC-A符号就是第一个数制位被设置为0的EAN-13符号。例如，“075678164125”是一个UPC-A码，如果使用EAN-13对它进行编码，将是“0075678164125”。可以看出来，我们只是在前面加了一个前导的“0”。在下图中，上面的那个是UPC-A符号，下面的那个是EAN-13符号，注意看它们之间的不同。

外文网站：http://internationalbarcodes.com/difference-between-ean-13-and-upc-a-barcodes/

UPC-A Barcodes are effectively a subset of EAN-13 Barcodes. If the first digit on the EAN-13 number is a ‘0’, then the bars will be of both the EAN-13 and the UPC-A (without the leading ‘0’) will be identical.

简单翻译一下：UPC-A条码实际上是EAN-13条码的子集。如果一个EAN-13条码的第一位数字是0，那么这个条码既是EAN-13码也同样是是UPC-A码（去掉开头的0）。

StackOverFlow：http://stackoverflow.com/questions/22767584/ios7-barcode-scanner-api-adds-a-zero-to-upca-barcode-format

<

浏览了各类文章之后确定了一件事：以0开头的EAN13码实际上就是UPC-A码在前面补了一个0，在AVFoundation扫描得到的结果里只需要判断条码的类别是否AVMetadataObjectTypeEAN13Code并且是否以0开头，如果是的话就把第一位的0直接删掉就好啦~

简单扩展

UPC-A为早期使用的条形码（出现于1973年），EAN13是后来为了能够更广泛地使用条形码而发明的，兼容UPC-A。EAN13是UPC-A的超集（即EAN13包含UPC-A）。