智能卡 Reader APDU 级别的 T0 T1 通信
Smart Card Reader T0 T1 communication on APDU level
我很难理解我必须使用什么协议来与卡 T0 或 T1 通信？所以，如果我错了，请纠正我，但 reader 实际上会自行决定使用哪种协议与卡进行通信（如果卡同时支持这两种协议）。
所以我现在的逻辑是：
// if ATR(T1) -> set_params(T1 structure) -> T1 APDU communication
// if ATR(T0) -> set_params(T0 structure) -> T0 APDU communication
但事实证明逻辑是错误的，它意外地对大多数 reader 有效。我刚刚发现 reader 即使卡片 ATR returns T1.
也需要 T0 通信
Q:确定使用什么协议的逻辑必须是什么？如果它背后有一个规范，你能告诉我吗？
已编辑：我忘了说我的代码在 OS 之前处于预引导环境 (UEFI)。所以我没有（使用）任何 API。我的代码处于字节流 APDU 级别，并使用 UEFI UsbIo 通信直接与硬件对话。
感谢大家！
祝一切顺利，
亚历克斯
好的，我一遍又一遍地重新阅读规范 (7816-3)，可能有 5 次或更多次。这些是我的发现：
根据规范，没有 “自动” 和 “默认” 协议之类的东西。
8.2.3 Interface bytes TA TB TC TD
The “first offered transmission protocol” is defined as follows.
If TD1 is present, then it encodes the first offered protocol T.
If TD1 is absent, then the only offer is T=0.
好的……
6.3.1 Selection of transmission parameters and protocol
... until completion of a successful PPS exchange (see 9.3), after what the interface device shall start the negotiated transmission protocol using the negotiated values of the transmission parameters.
在这种情况下，下一个更有趣：
Otherwise, the interface device shall have started the “first offered transmission protocol” (see TD1 in 8.2.3). The interface device shall do so when the card offers only one transmission protocol and only the default values of the transmission parameters. Such a card need not support PPS exchange.
A卡不完全正确，因为它支持PPS兑换！它根本不适用于 Cherry reader.
好了，下一个关键点在6.3.1：
NOTE 3 An interface device facing a card in negotiable mode and supporting neither PPS exchange nor the “first offered transmission protocol” can perform either a warm reset or a deactivation.
因此对于 Cherry reader 它 不遵循标准！ 它 shell 支持 在第一个提供的协议中进行通信，即 T1.
我在 SmartCard Handbook, 4th Edition 8.2 协议参数选择 (PPS) 章节中发现了一个非常有趣的东西：
The PPS process described above is not suitable for changing protocols with a terminal that has its own specific protocol but cannot execute a PPS.
Figure 8.11 A possible sequence for switching between two transmission protocols supported by a smart card without using a PPS. With the sequence outlined here, the terminal does not have to perform an explicit PPS, but can nevertheless switch between the two protocols by initiating a reset...
...This solution is not ideal from a technical perspective, since a device should always behave the same after each reset, but it is certainly a pragmatic solution for a heterogeneous terminal world.
它不适用于我的卡，因为卡不会通过执行热重置来切换协议。但这可能是对 reader.
奇怪行为的回答
一般来说，ATR 会告诉您该卡支持什么（以及不支持什么）。 ISO 7816-3 规范是寻找正确行为（即编程）的正确位置。
ATR 由八位字节 TS|T0|TA1|TB1|TC1|TD1|...|historical bytes|TCK 组成。不过，并非所有提到的值都必须是 ATR 的一部分。您必须解析所有 TDi (i=1..n) 的 ATR 检查。请检查 PC/SC-lite 来源，那里提供了 ATR 解析器。
TDi字节的最低四位告诉你，支持哪些协议（最低四位编码从0到15，0是T=0，1是T=1）。协议 0..15 应在 ATR 中按升序排序。
特例：如果没有TD1，那么T=0是唯一支持的选项。如果任何 TDi 字节状态 T=1 支持，则使用它。否则：T=0
我很难理解我必须使用什么协议来与卡 T0 或 T1 通信？所以，如果我错了，请纠正我，但 reader 实际上会自行决定使用哪种协议与卡进行通信（如果卡同时支持这两种协议）。
所以我现在的逻辑是：
// if ATR(T1) -> set_params(T1 structure) -> T1 APDU communication
// if ATR(T0) -> set_params(T0 structure) -> T0 APDU communication
但事实证明逻辑是错误的，它意外地对大多数 reader 有效。我刚刚发现 reader 即使卡片 ATR returns T1.
也需要 T0 通信Q:确定使用什么协议的逻辑必须是什么？如果它背后有一个规范，你能告诉我吗？
已编辑：我忘了说我的代码在 OS 之前处于预引导环境 (UEFI)。所以我没有（使用）任何 API。我的代码处于字节流 APDU 级别，并使用 UEFI UsbIo 通信直接与硬件对话。
感谢大家！
祝一切顺利，
亚历克斯
好的，我一遍又一遍地重新阅读规范 (7816-3)，可能有 5 次或更多次。这些是我的发现：
根据规范，没有 “自动” 和 “默认” 协议之类的东西。
8.2.3 Interface bytes TA TB TC TD
The “first offered transmission protocol” is defined as follows. If TD1 is present, then it encodes the first offered protocol T. If TD1 is absent, then the only offer is T=0.
好的……
6.3.1 Selection of transmission parameters and protocol
... until completion of a successful PPS exchange (see 9.3), after what the interface device shall start the negotiated transmission protocol using the negotiated values of the transmission parameters.
在这种情况下，下一个更有趣：
Otherwise, the interface device shall have started the “first offered transmission protocol” (see TD1 in 8.2.3). The interface device shall do so when the card offers only one transmission protocol and only the default values of the transmission parameters. Such a card need not support PPS exchange.
A卡不完全正确，因为它支持PPS兑换！它根本不适用于 Cherry reader.
好了，下一个关键点在6.3.1：
NOTE 3 An interface device facing a card in negotiable mode and supporting neither PPS exchange nor the “first offered transmission protocol” can perform either a warm reset or a deactivation.
因此对于 Cherry reader 它 不遵循标准！ 它 shell 支持 在第一个提供的协议中进行通信，即 T1.
我在 SmartCard Handbook, 4th Edition 8.2 协议参数选择 (PPS) 章节中发现了一个非常有趣的东西：
The PPS process described above is not suitable for changing protocols with a terminal that has its own specific protocol but cannot execute a PPS.
Figure 8.11 A possible sequence for switching between two transmission protocols supported by a smart card without using a PPS. With the sequence outlined here, the terminal does not have to perform an explicit PPS, but can nevertheless switch between the two protocols by initiating a reset...
...This solution is not ideal from a technical perspective, since a device should always behave the same after each reset, but it is certainly a pragmatic solution for a heterogeneous terminal world.
它不适用于我的卡，因为卡不会通过执行热重置来切换协议。但这可能是对 reader.
奇怪行为的回答一般来说，ATR 会告诉您该卡支持什么（以及不支持什么）。 ISO 7816-3 规范是寻找正确行为（即编程）的正确位置。
ATR 由八位字节 TS|T0|TA1|TB1|TC1|TD1|...|historical bytes|TCK 组成。不过，并非所有提到的值都必须是 ATR 的一部分。您必须解析所有 TDi (i=1..n) 的 ATR 检查。请检查 PC/SC-lite 来源，那里提供了 ATR 解析器。
TDi字节的最低四位告诉你，支持哪些协议（最低四位编码从0到15，0是T=0，1是T=1）。协议 0..15 应在 ATR 中按升序排序。
特例：如果没有TD1，那么T=0是唯一支持的选项。如果任何 TDi 字节状态 T=1 支持，则使用它。否则：T=0