仔细阅读ISO/IEC 7816-3：2006，第12.2.5节指定当阅读器发送带有LC＆gt; 0的命令APDU时发生的情况（字节流）。初始命令TPDU没有LE字段，如果卡成功响应，则该应用程序应发送0xc0获取响应命令，直到收到LE字节为止。
问题：如果智能卡期望返回数据，那么该卡响应初始t = 0命令（在任何获取响应命令之前）返回0x9000实际上是否有效，正如7816-3所指定的吗？应用程序在0x9000响应后发出get响应命令是否有效？相比之下，从读取dotransmit在javax.smartcardio和opensc中的sc_transmit中，看来这些应用仅在sw = 0x61xx响应后尝试得到响应，从来没有在sw = 0x9000响应后。
在ISO 7816中应提前知道每个命令的ISO" case"。换句话说，命令有：
- 无命令数据＆amp;没有响应数据
- 没有命令数据，但是响应数据
- 命令数据，但没有响应数据
- 命令数据和响应数据
通常，如果状态单词指示错误发生，即使ISO案例指出响应数据是可以预期的。
，命令也不会发送响应数据。现在在表14中说明了SW1 SW2 9000：
过程正常完成。在案例1、2和3中，没有进一步的行动。在案例4中，在接收命令数据字节后，该卡应准备接收至少一个获得响应命令，以最多传输NE响应数据字节。
。
so 仅对于ISO案例4，您发送命令数据并期望响应数据，应在9000之后发送GET RESPONSE。但是，如果您使用的是ISO案例2并且收到9000，则应不是发送GET RESPONSE。
在我看来，只要您为ISO案例4 CommandAPDU之一指定一个NE值（即一个包含命令数据的一个），javax.smartcardio 应该接收9000 SW1/SW2时发出GET RESPONSE APDU。这意味着文档不完整或实施不正确。
当我读取7816-3时，情况4S.2如果确切的c（n）字节可用，卡可以用90 00响应90 00。但是，由于C（N）在将APDU转换为Case 4命令的情况下切断了C（N），因此该卡的唯一选择是返回61xx。
。对于案例2命令9000似乎是一个合理的答案[即使在7816-3中未单独列出此情况。