无论协议如何，Le 是否可以作为案例 4 命令传递给 PCSC SCardTransmit 的数据的一部分？
Can Le be part of the data passed to PCSC SCardTransmit for a Case 4 command regardless of protocol?
ISO/IEC 7816-3:2006 (12.1.2) 定义发送数据的智能卡命令的字节串，预计会产生一些超出状态字的内容：
A command APDU of case 4 consists of a header, a LC field, a data field and a LE field.
ISO/IEC 7816-4:2020 (5.2) 类似。我限制为
的短例 (4S)
- LC是01H…FFH中的一个字节直接编码整数N C（数据字段中的字节数，因此打折4字节header）
- LE是01H…FFH中的一个字节直接编码整数N E（当没有错误发生时卡响应的预期字节数，折扣状态字），或 00H 意思是 最大（或等价于NE=256）。
在这种情况下4S，LE是否可以成为传递给PCSC的数据的一部分SCardTransmit而不考虑协议？
换句话说，当把这样的命令传给PCSCSCardTransmit时，是否可以不考虑协议，将cbSendLength设置为NC+6？
我问是因为我有一个可重现的问题，在命令中包含 LE（例如 00 A4 09 00 02 20 03 42 和 cbSendLength = 8 在卡片将实际上 return 一个状态字 6A 82 并且没有数据）导致 SCardTransmit 失败。 LE 字节的值无关紧要。这是来自不同制造商和应用程序的 T=0 卡，几个 reader 不同型号但都具有相同的 manufacturer-recommended Windows driver（2016 年的 GemPcCCID 4.1.4.0- 08-08 签署于 2018-07-26，there)。使用 Microsoft 的默认 CCID WUDF driver，或者如果我将 cbSendLength 设置为少一个（从而删除 LE），问题就会消失。到目前为止，我没有发现其他 reader/driver 配置触发 that 问题，所以我倾向于说这是一个 driver 问题（或者至少是driver 和它应该使用的 PCSC 服务的组合）。
我想要一些说明将 LE 字节包含到 SCardTransmit 是否合法的规范，我更喜欢 Windows-specific ].
我知道如果应用程序知道使用协议 T=0，就很容易从初始 SCardTransmit 中省略 LE 字节，并且我看到当卡发送 61xx 状态字时 LE 可以如何处理。但是有些非接触式智能卡reader假装T=0，其实是用ISO/IEC14443-4协议，这时LE字节就有用了在某些情况下，因此我不想使用该选项。
添加：spec of ScardTransmit 有：
For T=0, in the special case where no data is sent to the card and no data expected in return, this length (of the data passed to ScardTransmit) must reflect that the bP3 member is not being sent; the length should be sizeof(CmdBytes) - sizeof(BYTE)(that is 4, the length of the C-APDU).
因此，在T=0下，1、2S、3S情况下，传递给ScardTransmit的是C-APDU，而1情况下，与C-TPDU不同。我问是否有解决命令的参考，特别是在 T=0 下的 4S 情况下，从 C-APDU 中剥离 LE（使其成为 C-TPDU) 在传递给 ScardTransmit 之前，类似于上面的处方 not 在 T=0 ( ScardTransmit、driver 或 reader 将执行）。
根据ISO/IEC 7816-3:2006(E)，T=0 协议的命令由 CLA-INS-P1-P2-P3-Data 组成，即数据后面没有任何字段。
条款12.2.5 Case 4S与T=0的command-response pair transmission有关。它说：
命令APDU通过切断Le字段映射到命令TPDU。
因此，在 4S 的情况下，命令末尾不允许有 Le 字节。
如 所述，在 T=0 协议下，将 Case 4 命令 APDU 传递给 SCardTransmit 并完成 Le 是不安全的。该问题还询问记录在何处。
这种限制目前在 Microsoft's spec of SCardTansmit, nor in the pscsclite spec. However, SCardTransmit has historically been developed as an implementation (with different parameter passing but similar functionality) of IFD_Transmit_to_ICC specified by PC/SC in Part 3, paragraph 4.3.2.1 中都没有说明（注意：可能加载缓慢）并且说明：
Provisions for SCARD_PROTOCOL_T0 communication
The CommandData needs to be formatted as an APDU as described in the ISO/IEC 7816-4. The following cases are supported:
- Case 1: Command with no incoming or outgoing data byte:
CLA INS P1 P2
- Case 2: Command with outgoing data bytes:
CLA INS P1 P2 Le
- Case 3: Command with incoming data bytes:
CLA INS P1 P2 Lc [Data bytes]
Specific remarks:
- Only the short format of
Lc and Le is supported, i.e. one byte long.
- An incoming order with no data byte «
CLA INS P1 P2 » should be sent to the card as TPDU through a case 1 APDU.
- A case 4 APDU cannot be used. It is the responsibility of the application or the service provider to generate a « get response » if they need it.
因此，在 T=0 协议下，传递 SCardTransmit 除 Case 1、Case 2S 或 Case 3S 命令 APDU 之外的任何其他内容是轻率的。
如果我们传递 Case 4S 命令 APDU ( CLA INS P1 P2 Lc [Lc Data bytes] Le,在 [0x01…0xff] 中使用 Lc ），它适用于许多驱动程序和 readers。根据我的经验，在 Windows 下使用 Microsoft 的 Usbccid WUDF 驱动程序和许多其他供应商的驱动程序，以及使用 pcsclite 和它的配套 libccid，完整的 C-APDU 被传递给 reader，过滤掉Le在C-TPDU卡了，一切都很好。但是也有例外，包括 GemCCID 4.1.4 Windows 驱动程序，它不执行传输并且 returns 出错。
ISO/IEC 7816-3:2006 (12.1.2) 定义发送数据的智能卡命令的字节串，预计会产生一些超出状态字的内容：
A command APDU of case 4 consists of a header, a LC field, a data field and a LE field.
ISO/IEC 7816-4:2020 (5.2) 类似。我限制为
的短例 (4S)- LC是01H…FFH中的一个字节直接编码整数N C（数据字段中的字节数，因此打折4字节header）
- LE是01H…FFH中的一个字节直接编码整数N E（当没有错误发生时卡响应的预期字节数，折扣状态字），或 00H 意思是 最大（或等价于NE=256）。
在这种情况下4S，LE是否可以成为传递给PCSC的数据的一部分SCardTransmit而不考虑协议？
换句话说，当把这样的命令传给PCSCSCardTransmit时，是否可以不考虑协议，将cbSendLength设置为NC+6？
我问是因为我有一个可重现的问题，在命令中包含 LE（例如 00 A4 09 00 02 20 03 42 和 cbSendLength = 8 在卡片将实际上 return 一个状态字 6A 82 并且没有数据）导致 SCardTransmit 失败。 LE 字节的值无关紧要。这是来自不同制造商和应用程序的 T=0 卡，几个 reader 不同型号但都具有相同的 manufacturer-recommended Windows driver（2016 年的 GemPcCCID 4.1.4.0- 08-08 签署于 2018-07-26，there)。使用 Microsoft 的默认 CCID WUDF driver，或者如果我将 cbSendLength 设置为少一个（从而删除 LE），问题就会消失。到目前为止，我没有发现其他 reader/driver 配置触发 that 问题，所以我倾向于说这是一个 driver 问题（或者至少是driver 和它应该使用的 PCSC 服务的组合）。
我想要一些说明将 LE 字节包含到 SCardTransmit 是否合法的规范，我更喜欢 Windows-specific ].
我知道如果应用程序知道使用协议 T=0，就很容易从初始 SCardTransmit 中省略 LE 字节，并且我看到当卡发送 61xx 状态字时 LE 可以如何处理。但是有些非接触式智能卡reader假装T=0，其实是用ISO/IEC14443-4协议，这时LE字节就有用了在某些情况下，因此我不想使用该选项。
添加：spec of ScardTransmit 有：
For T=0, in the special case where no data is sent to the card and no data expected in return, this length (of the data passed to ScardTransmit) must reflect that the
bP3member is not being sent; the length should besizeof(CmdBytes) - sizeof(BYTE)(that is4, the length of the C-APDU).
因此，在T=0下，1、2S、3S情况下，传递给ScardTransmit的是C-APDU，而1情况下，与C-TPDU不同。我问是否有解决命令的参考，特别是在 T=0 下的 4S 情况下，从 C-APDU 中剥离 LE（使其成为 C-TPDU) 在传递给 ScardTransmit 之前，类似于上面的处方 not 在 T=0 ( ScardTransmit、driver 或 reader 将执行）。
根据ISO/IEC 7816-3:2006(E)，T=0 协议的命令由 CLA-INS-P1-P2-P3-Data 组成，即数据后面没有任何字段。
条款12.2.5 Case 4S与T=0的command-response pair transmission有关。它说： 命令APDU通过切断Le字段映射到命令TPDU。
因此，在 4S 的情况下，命令末尾不允许有 Le 字节。
如 SCardTransmit 并完成 Le 是不安全的。该问题还询问记录在何处。
这种限制目前在 Microsoft's spec of SCardTansmit, nor in the pscsclite spec. However, SCardTransmit has historically been developed as an implementation (with different parameter passing but similar functionality) of IFD_Transmit_to_ICC specified by PC/SC in Part 3, paragraph 4.3.2.1 中都没有说明（注意：可能加载缓慢）并且说明：
Provisions for SCARD_PROTOCOL_T0 communication The
CommandDataneeds to be formatted as an APDU as described in the ISO/IEC 7816-4. The following cases are supported:
- Case 1: Command with no incoming or outgoing data byte:
CLAINSP1P2- Case 2: Command with outgoing data bytes:
CLAINSP1P2Le- Case 3: Command with incoming data bytes:
CLAINSP1P2Lc[Data bytes]Specific remarks:
- Only the short format of
LcandLeis supported, i.e. one byte long.- An incoming order with no data byte «
CLAINSP1P2» should be sent to the card as TPDU through a case 1 APDU.- A case 4 APDU cannot be used. It is the responsibility of the application or the service provider to generate a « get response » if they need it.
因此，在 T=0 协议下，传递 SCardTransmit 除 Case 1、Case 2S 或 Case 3S 命令 APDU 之外的任何其他内容是轻率的。
如果我们传递 Case 4S 命令 APDU ( CLA INS P1 P2 Lc [Lc Data bytes] Le,在 [0x01…0xff] 中使用 Lc ），它适用于许多驱动程序和 readers。根据我的经验，在 Windows 下使用 Microsoft 的 Usbccid WUDF 驱动程序和许多其他供应商的驱动程序，以及使用 pcsclite 和它的配套 libccid，完整的 C-APDU 被传递给 reader，过滤掉Le在C-TPDU卡了，一切都很好。但是也有例外，包括 GemCCID 4.1.4 Windows 驱动程序，它不执行传输并且 returns 出错。