条形码发明人去世(二维码的技术类型)

条形码发明人去世，二维码的技术类型？

1、QRCode二维码（简称QR码）

QRCode二维码是1994年由日本DW公司发明，是目前主要流行的二维码，具有超高速识读、全方位识读、能够有效表示中国汉字、日本文字、各种符号字母数字等特点，QR来自英文QuickRespe的缩写，即快速反应的意思。QR Code二维码广泛应用于生活中的收付款，防伪溯源，工业自动化生产线管理、电子凭证等各种各样场景。

2、daatrix二维码（简称DM码）

DM码由美国国际资料公司于研发，是一种矩阵式二维码，它的尺寸比其他类型的二维码都小。适用于小零件的标识，商品防伪，以及直接印刷在实体上。

3、PDF417二维码

是美国讯宝科技公司于1990年研发，发明者是留美华人王寅君博士。意为“便携数据文件”，因为组成条码的每一符号字符都是由 4个条和4个空共17个模块构成，所以称为PDF417条码。被广泛应用于工业生产、卫生、商业、交通运输等领域

4、MaxiCode二维码

MaxiCode二维码是美国知名的UPS快递公司为有效改善作业效率、提高服务品质而研发的条码。也主要用于美国快递行业。

5、汉信码

汉信码是由我们国家自主研发的一种矩阵式二维条码，具有高强的汉字编码能力。目前汉信码被应用于各行各业，如图书物流、质量追溯系统、仓库管理、竞赛考试、食品安全、质监检查等等行业。

DM码和QR码的区别？

DataMatrix码和QR码都是二维码的成员，是不同的二维码种类。DataMatrix码和QR码虽说都是二维码的，但是二者在各方面还是有很大的区别，下面介绍一下DataMatrix码和QR码具体有哪些区别！

DataMatrix码和QR码的外观不同

DataMatrix码版本越高（可输入的数据越多），会把DataMatrix码外观分隔成多个模块显示，DataMatrix码还可以制作成长方形外观，QR码外观比较单一。下图是在条码打印软件中DataMatrix码和QR码的外观对比。

DataMatrix码和QR码定义不同

QR码是矩阵式二维码，DataMatrix码原名datacode，中文翻译过来就是数据矩阵码。

DataMatrix码和QR码的特点不同

DataMatrix码特点：密度高，尺寸小，储存信息量大，其最小尺寸是所有条码中最小的，可在仅仅25mm²的面积上编码30个数字，DataMatrix码采用复杂的纠错码技术，所以DataMatrix码抗污损能强。

QR码特点：QR码信息容量大，编码范围广（可以将照片、指纹、掌纹、签字、声音、文字等凡可数字化的信息进行编码），保密、防伪性能好，纠错能力强。

DataMatrix码和QR码读取速度有差异

QR来自英文Quick Response的缩写，即快速反应的意思，发明者希望QR码的内容可快速被解码，据统计，用CCD二维条码识读设备，每秒可识读30个含有100个字符的QR Code码符号；而DataMatrix码，每秒仅能识读2～3个符号。读取角度上QR码具有全方位（360°）识读特点，而DataMatrix码只能在一个方向上读取。

DataMatrix码和QR码应用范围有所区别

由于DataMatrix码最小尺寸是所有二维码中最小的，所以DataMatrix码常用于小零件的标识，商品防伪，以及直接印刷在实体上。QR码原本是为了在汽车制造厂便于追踪零件而设计，而今日QR码已经被广泛应用于各行各业，如广告，防伪，手机支付、B2B、物流等等。

综上所述就是DataMatrix码和QR码的区别，二者各有各的长短处，而且无论是DataMatrix码还是QR码都可以利用条码打印软件批量制作且成本低。

二维码是什么原理？

呵呵，日本人最最后悔死了的一件发明，当初仅仅是用在商品统计、存档等小范围扫描，并且还是一维码，万万没想到让中国人把二维码发扬光大，二维码永远不会使用完的，随时随地可以生成不同动态的二维条码 。

QR的意思？

QR是英文“QuickResponse”的缩写，即快速反应的意思。QR码是二维条码的一种，源自发明者希望QR码可让其内容快速被解码。QR码比普通条码可储存更多资料，亦无需像普通条码般在扫描时需直线对准扫描器。

为什么有人觉得写业务代码很low？

我觉得首先大家要理解什么是“业务代码”，业务代码是一个相对的概念。

1.对于一个一般的物联网应用型公司来说，业务代码就是根据客户需求基于一个MCU或者MPU的应用控制逻辑的实现。

2.对于一个做纯上层应用的公司来说，业务代码就是基于一个操作系统为客户量身定制对应的app,并实现对应的应用逻辑。

3.对于一个微型控制器设计厂商，业务代码就是底层架构裸机的具体实现和各个外设驱动的框架设计。

4.对于一个设计操作系统的开发人员来说，业务代码就是架构设计、内存管理、调度机制优化、优先级管理、进程间通信机制优化、线程管理和内核完善等等。

所谓”业务代码”都是相对的，没有参考系怎么谈。像操作系统，站在操作系统内核提供方的角度看，上层所有的应用框架，进程服务，都是业务代码，我是为他们服务的。技术只是工具，业务实现才是目的，站在不同供应商的角度，只要涉及代码的地方都可以称之为业务代码。所以站在这个维度，如果要说业务代码“LOW”,那就没有代码是不"LOW"的了。

不过，真正接触底层或者实现RTOS底层业务框架的工程师其实是很少的。大部分工程师基本上都是对于客户需求做一些非驱动底层非操作系统框架的应用型的开发，所以大多时候“业务代码“又单一的被指向了那些只是对客户的上层应用的需求做开发、调整或者迭代的代码。

而这部分代码究竟"LOW"还是不"LOW"呢，我的答案是：不"LOW"。但是现实却是很“LOW”,之所以会被想成LOW，是因为：

1.判断一个程序员的优秀程度已经不单单看你写了多少应用型的代码，设计了多少应用框架，而是你懂不懂底层驱动逻辑，懂不懂操作系统内核，懂不懂内核裁减等等。所以这种情况会经常出现在面试过程中，面试官会因为你不懂底层驱动、不懂内核而给你比较低的薪水。

2.懂得写业务代码的人，他的程序员基础并不一定就牢固。因为上层应用可能对业务比较看重，但是对于一些特定的语言的编程并没有那么严谨。能用就可以，所以会自然而然的认为这样的程序员“LOW”。而一个会写底层驱动的人，他考虑更多的是基础代码的安全、严谨性和容量问题等等，他们的语言基础相对来说要牢固很多。

3.技术负责人一般都是全能型的人。会写底层驱动或者更懂操作系统内核的人更容易成为技术的领头人。而那些只会“业务代码”的人，放在大部分公司,一般都不会有太多的上升空间。

根据以上分析过后呢，做“业务代码”的程序员基本上会被想的很“LOW”,但是结合我的亲身经历，不同的人对于这个事情却会有不同的看法。

比如对于领导来说，那就不一样了。你将“业务代码”的需求迭代了，完善了，提前任务完成了，客户很满意。那领导不会认为你是一个很“LOW”的程序员。你很高级，领导很欣赏，“后果”很舒服。但是对于一个面试官来说，你就会点上层应用的调用和设计。我为什么要给你这么多薪水？虽然会被想成很"LOW"，但是也是现实。

好了，这个问题就回答到这里，以上都是个人结合实际经历的一些体会，喜欢的加关注，我是一名深漂的嵌入式程序员，欢迎私信留言，感谢！