一直对这个数据格式没有好感，因为它引导人们把名称简化为无意义的编号，增加记忆和理解的成本。
周星驰的《唐伯虎点秋香》中，唐伯虎进入华府做家丁，被编号为9527，一个家丁没有资格被呼作姓名，就算是唐伯虎。
曾几何时，高速公路的路牌是各种的名字：机场高速，京珠高速。。。。后来被取缔为s21,g20，让人十分无语。
最近，我听得最多的就是49域上送的不对，32域校验不对之类的。当时我的心真的有点捉狂，使得我一度很恶趣味的猜测，这玩意除了给初学者增加学习的成本，形成一种就业壁垒外，还能有啥好处？毕竟这是ibm年代的产物，大型机的技术封闭使得技术人员非常稀罕。
用最简单的话语介绍一下iso8583格式的协议：
iso是一个国际规范组织，这个8583规范是定义关于银行卡的数据传输格式，我们日常使用的atm，pos在进行数据传输的时候，就使用iso8583协议。
从技术层面看，iso8583格式报文（下称8583包）如下组成：
mti（4b）＋位图（1-3B)＋数据
既然这个格式是银行卡的数据传输格式，我们来看看从atm取钱的流程
1.插卡，输入密码
2.点击取钱，输入金额
3.吐钱，退卡
这里每个步骤，其实都由atm机器和银行系统进行了多次的数据传输。同时，传输的数据有以下的要求：
1.要以二进制的形式通过广域网传输
2.数据要安全
3.数据的高效率
由于第1点，我们需要使用一个约定的格式来实现银行卡的数据与二进制数据的转换，这个过程叫序列化和反序列化。
而目前国际上，包括国内，都适用了iso8583协议作为传输的通用格式。
8583安全吗？
我曾经以为使用8583是为了安全，然而并不是这样，我们可以随意的下载到这个8583规范，拿到数据包即可根据规范文档对其中的数据进行查看。当然，银行卡数据的安全是由其他手段保证，这里不展开。
iso8583包的数据处理效率高？
这个问题我思考了一段时间了，但如果8583包的处理效率高，为何现在没有在其他领域推广？
没有看到哪个序列化是参考了8583的思想所以很快的啊？
决定序列化处理的效率，一般是由下面两个重要因素决定：
1.转换后二进制数据的大小，越小越好
2.转换的速度，越快越好
一次数据的转换，一般需要如下的元素：
1.转换的schema：包含了每个数据的含义，长度和类型，有了schema才可以解开数据包。而schema应该是双方约定好的，在各自的本地保存，不需要在传输的数据包中带上，以减少传输数据的大小。
2.数据位的对照：代表这次携带了多少数据。假设schema定义了128个字段，但是一次传输不一定会带上128个字段，因此需要指定这次携带了多少个字段，以及这些字段如何和schema对应起来。
3.数据有哪些：就是数据本身，可以是任何的数据
iso8583和业界常用序列化的对比
1.schema是否在数据包中带入：
8583、fastjson、protobuf和java原生序列化，都不在数据中带入schema，此项打平
2.8583包采用位图（bitmap）的形式来实现数据位的对照，一个字节可以表示64个字段是否存在。一般用2-3个字节就可以表示数据位的对照。
fastjson属于json格式，使用［］｛｝：进行数据位的匹配，再由字段名进行数据位的对照，例如name这个字段，必须占用4个字符。
xml序列化，使用<>进行数据位的匹配，再由字段名进行数据位的对照，和json格式差不多，但是对照的字段名一般长度是json的两倍（因为<name></name>，name一般出现2次)。
其他序列化也需要用字段名来实现对照。
因此这里8583以2-3个字节实现所有字段与schema的对照，在大小方面有强大的优势。
3.数据存在可以压缩的可能，压缩虽然可以减少数据的大小，但是会增加转换过程的时间。此处没有强制要求，打平。
可以承认，8583使用的位图对照策略是一个优秀的设计，但是它没有被大量使用，莫非因为它有局限性？答案呼之欲出！
是的，就是因为局限性。
银行卡数据基本都是一层的结构，1-128个字段，字段里面很少再有嵌套。
而真实世界里面，很多数据结构就是多层嵌套的，一个列表中某个元素是哈希表，哈希表中某个元素又可能是列表，这样的情况，用一个简单的位图，是无法实现数据的对照的。
结论
在种种历史原因，或规范的约束下，银行卡用了iso8583作为传输的数据格式。
而从技术来看，由于银行卡数据只有一层结构，使其可以使用位图来实现数据的对照，从而减少数据的传输量。
但偏偏正是位图的引入，使得银行届普遍喜爱所用xx域，yy域来表示一个字段的含义。
9527没有资格让人们记住他的名字，特工也喜欢用007代替自己的真名。
作为一个oo（面向对象）的支持者，真的希望41域作为流水号能重见天日，然而这是一个习惯问题，而非技术问题，本人深感无力。
