本文记录 USB CCID 标准中几个"复杂"的命令，复杂在于在这些命令身上花的时间较之简单的命令多许多或者是理解的时间比较晚，可能就是刚才。
主要有以下几条：
ccid_T0APDU();
ccid_Secure();
ccid_Escape();
ccid_Abort();
ccid_Mechanical();
ccid_SetDataRateAndClockFrequency();
ccid_T0APDU(): 我们知道，当读卡器是APDU level时，并且卡片使用T=0协议进行通信，那么构造TPDU的任务就落在了读卡器身上。根据ISO7816规定，该角色需要将APDU构造成一组命令，其中包括GET_RESPONSE()和ENVELOPE()命令，同时，由于每张卡片的CLA字段可以不同，这时，读卡器就需要一个规则来确定发送这2条命令时，选择的CLA是什么了。主机可以用ccid_T0APDU()来设置该值，以后读卡器就知道该怎么做了。
ccid_Secure(): 该命令用于 PIN_VERIFY 和 PIN_MODIFY 时，也就是校验PIN和修改PIN，该命令复杂在于命令后面的参数，需要根据卡片特性来填充并且构造合适的APDU命令，比较麻烦。
ccid_Escape(): 该命令用于传输厂家定义的特殊命令，可以理解为扩展命令，比如有的卡片PIN_VERIFY和PIN_MODIFY就是通过这个命令来做的，是因为M$ ccid驱动不支持 ccid_Secure()命令吧，我不确定？！
ccid_Abort(): 该命令是最难理解的一个，首先要明确 abort 什么东西？根据CCID，能够被 abort 的命令有以下几个：
PowerOn()、XfrBlock()、Escape()、Secure()、Mechanical() 和 Abort()本身。 从这些命令似乎很难看出 abort 到底有什么用处（个人原来一直认为没用，现在有所转变了），不过，根据标准和实际场景分析得出，这条诡异的命令主要有以下2个功能：
1）帮助 CCID 读卡器同步状态：
如何同步呢？这个太细节了，其实就是因为读卡器因为某些原因已经堵死了或者将要堵死，主机发送一对 abort 命令来救活读卡器；
2）帮助 HOST 端同步状态：
根据个人的理解，在主机端，靠状态机驱动时，增加这个 abort 状态和处理，能够达到同步状态，把状态机跑顺的作用。
我们可以假设一些使用该命令的场景：
1）读卡器执行一条需要等待对方应答或用户输入才能结束的命令，但应答或输入迟迟不到，这就堵死了？是的，标准没为它加超时机制（不绝对），所以它就只能死等，后续再来的命令当然也就无能为力了，不过我们可以用 abort 拯救它 -- 读卡器。
2）主机某个应用程序启动，准备操作读卡器读卡片，可能此时卡片状态或读卡器状态比较混沌，也许是上一个使用读卡器的应用没有安全退出，烂摊子留下来了，但我们不能被这种小事给弄死吧，我们可以发送2对 abort 命令来把之前的命令取消掉（如果有的话），至于为什么是2对，分析分析就知道了。不过后来发现，PowerOff 命令好像也可以做到，晕！
3）还是主机应用，可能需要读取很多数据，读到几片数据时，发现不爽了，不想读了（可能是超时了），自己来个 abort， 标记下，以后到的数据我都不当成是正常的数据，为什么还有数据到呢? 不是给 abort 了吗？ 因为我还不知道如何 abort 卡片正在进行的操作，如果卡片有数据传回来，我们没有办法打断，只能都收回来，结果就要看接收者如何利用这些数据，如果被 abort 了的话，可认为是无效数据而简单丢弃。
To be continued ...