我希望从不同供应商，不同用途，不同APDU的一堆智能卡中读取一些基本信息。 例如：国家识别智能卡，EMV（支付），手机SIM，javacard等......
我写了一个Java应用程序。 让我称SC系列A B C D E，并用相同的名称命名5个子程序，每个子程序都有正确的APDU，以读取一个特定SC系列的基本信息。
不幸的是，我发布例程的顺序会使成功结果产生偏差。
示例：使用子程序A B C D E，我可以读取A B C D类型的SC，而不是E.
如果我将执行顺序更改为E A B C D，我可以读取E但现在我用C类型的SC失败。
我理解：有些SC丢弃外国APDU ......其他SC＆＃34;挂起＆＃34;。
是否有基本命令来清除智能卡（和读卡器）的状态？
因此子程序的执行顺序不会改变输出？
复位B复位C复位D复位等......
是ATR吗？对每种SC都是强制性的吗？
答案 0 :(得分：1)
您描述的行为听起来很奇怪，因为智能卡读卡器不应该在不同的智能卡之间保持状态。
但是，我不知道重启智能卡读卡器的任何通用命令。例如HID OMNIKEY读者，您可以使用专有APDU FF 70 07 6B 08 A2 06 A1 04 A9 02 83 00 00重新启动（请参阅here [7.6.3]，虽然本指南说它适用于OMNIKEY 5022读者，但它适用于更多OMNIKEY读者）。因此，对于您的读者，您将不得不研究互联网上类似的专有APDU。
请记住，重新启动阅读器也很可能会导致USB阅读器重新枚举。
答案 1 :(得分：1)
您可以使用Card.disconnect()方法重置卡片（谨防this）。
但是（恕我直言）最好的方法是使用卡ATR（由Card.getATR()给出）来猜测正确的卡片系列（如果可能的话）。这种方式也快得多。我使用这种方法来处理几种不同的非接触式卡产品的演示，并且它运行良好。
一些额外的（随机）笔记：
研究所有家庭的文件 - 绝对必须有这种行为的原因。尝试跳过一些子程序和/或它们的APDU命令来固定它。
此外，一些APDU可能会在意外发送时导致问题（例如，锁定的密码或锁定的身份验证尝试）。你应该知道自己在做什么。
大多数产品系列都有一些可靠的检测方法 - 如果您有，请参阅文档。
如果任何先前调用的子例程使用SELECT来更改所选应用程序/文件并成功，则它将保持选中状态。考虑在每个子例程的开头使用显式SELECT（例如，选择预期的AID或主文件）。
DESFire卡在接收非本机命令APDU时会离开本机模式并进入包装模式（这可能不是您使用javax.smartcardio时通常的ISO包装命令）。