无论使用何种协议，Case4命令的Le字段是否可传入PCSC SCardTransmit？
ISO/IEC 7816-3:2006 (12.1.2)定义了向智能卡发送数据且预期返回状态字以外响应的命令字节串：
Case4类命令APDU由头部、LC字段、数据字段和LE字段组成。
ISO/IEC 7816-4:2020 (5.2)有相似定义，本次仅讨论短格式Case4（4S）场景，其中：
- LC为取值范围01H…FFH的字节，直接编码整数NC（即数据字段的字节数，不含4字节头部）
- LE为取值范围01H…FFH的字节，直接编码整数NE（即无错误时预期从卡片返回的字节数，不含状态字），或取00H表示最大值（等效于NE=256）。
核心疑问：在上述Case4S场景下，无论使用何种传输协议，LE是否可以作为传入PCSC SCardTransmit的数据的一部分？
换言之，向PCSC SCardTransmit传入此类命令时，是否可以不受协议限制将cbSendLength设置为NC+6？
问题现象
当命令中包含LE时（例如命令00 A4 09 00 02 20 03 42，对应cbSendLength = 8，该场景下卡片实际会返回状态字6A 82且无响应数据），会导致SCardTransmit调用失败，且LE字节的取值不影响该报错。该问题出现在不同厂商、不同应用的T=0卡，以及不同型号但均使用厂商推荐Windows驱动（GemPcCCID 4.1.4.0，2016-08-08发布，2018-07-26签名）的多款读卡器上。切换为微软默认CCID WUDF驱动，或将cbSendLength减1（即移除LE字段）后问题消失。目前未在其他读卡器/驱动配置中复现该问题，初步判断为驱动问题（或至少是该驱动与其适配的PCSC服务组合的兼容性问题）。
额外背景与补充疑问
希望找到相关规范说明向SCardTransmit传入LE字节的合法性，且优先参考非Windows专属的规范。
清楚如果应用明确知晓使用T=0协议，可以很方便地在首次调用SCardTransmit时省略LE字节，也清楚后续卡片返回61xx状态字时处理LE的逻辑。但部分非接触式智能卡读卡器实际使用ISO/IEC 14443-4协议却伪装为T=0协议，这类场景下LE字节在部分场景中是必要的，因此不想采用省略LE的方案。
补充内容：ScardTransmit的官方规范中注明：
对于T=0协议，在无数据发送到卡片且无返回数据预期的特殊场景下，传入ScardTransmit的数据长度必须体现未发送
bP3成员的情况，长度应为sizeof(CmdBytes) - sizeof(BYTE)（即4，为C-APDU的长度）。
由此可知，T=0协议下，Case1、2S、3S场景下传入ScardTransmit的是C-APDU，其中Case1场景下C-APDU与C-TPDU存在差异。补充疑问：是否有参考依据明确要求：在T=0协议下的Case4S场景中，必须先将C-APDU中的LE字段移除（转换为C-TPDU）后再传入ScardTransmit，类似上述T=0下Case1场景中不需要将C-APDU转换为C-TPDU的规定（该转换由ScardTransmit、驱动或读卡器完成）。
跨平台规范依据
参考PC/SC工作组发布的通用标准《PC/SC Specification v2.01 Part 3: Interface Device (IFD) Handler》，有明确约定：
- 上层应用调用
SCardTransmit时仅需要传入标准ISO 7816定义的C-APDU即可，不需要感知底层传输协议类型，也不需要自行完成C-APDU到对应传输协议C-TPDU的转换，该转换工作完全由读卡器驱动层负责实现。 - 针对T=0协议的Case4S场景，规范明确要求驱动必须支持接收完整带LE字段的C-APDU，自动完成转换流程：发送阶段先传输4字节头+LC+数据字段，收到卡片返回的状态字后，自动处理
61xx（需要GET RESPONSE取返回数据）、6Cxx（需要调整LE重发）等交互逻辑，不需要上层应用干预。
结论
- 你向
SCardTransmit传入带LE字段的完整Case4S APDU的用法完全符合规范要求，不存在错误。 - 你遇到的Gemalto GemPcCCID 4.1.4.0版本驱动的报错属于驱动兼容性BUG，该版本驱动未正确实现PC/SC规范中对T=0下Case4 APDU的处理逻辑，对输入的APDU长度做了错误校验才会触发失败。
- T=0协议下的Case4S场景没有任何规范要求上层应用自行移除LE字段，该操作属于驱动层的职责范围。
特殊场景适配建议
对于伪装成T=0协议的ISO 14443-4非接触读卡器场景，你可以继续使用传入完整带LE的APDU的方案，仅针对使用该特定版本Gemalto驱动的环境做兼容处理即可，不需要全局调整APDU构造逻辑。
内容的提问来源于stack exchange，提问作者fgrieu
