哪个 APDU 命令获得 7 个字节的卡 ID？
我使用带有 ISO14443 层的 T=CL (ISO7816) 协议。在检测卡上，我只能看到卡 ID 的 4 个字节。
我发现这应该是获取卡ID的APDU命令。
例如：0xFF, 0xCA, 0x00, 0x00, 0x00
但此命令的结果是：6E 00，在 APDU 答案的规范中表明 "Class not supported"
然后我发现它的APDU命令可能为：0x00, 0xCA, 0x00, 0x00, 0x00
此命令返回6A 88
其中6A XX - “错误的参数 P1-P2” 和 88 - “未找到参考数据”
你怎么看？
谢谢！
附：所有命令为：CLA, INS, P1, P2, LenData, Data
其他我的命令正常工作（例如sellect aplet并使用它），仅在获取卡ID时出现问题
【问题讨论】：
标签： smartcard apdu mifare contactless-smartcard
前面给出的答案是错误的。这是因为我们在这里讨论的不是 ISO 7816 命令，而是 PC/SC API 的内部命令。
APDU“0xFF 0xCA 0x00 0x00 0x00”实际上是正确的，我有卡，我得到一个 7 字节的答案。请注意，这仅适用于非接触式 (RFID) 卡，因为此 UID 是无线电协议的一部分。请进一步注意，某些芯片会在每次上电后返回一个新的随机 UID。例如，我的护照芯片和德国国民身份证就是如此，以及防止追踪持卡人的对策。理论上，此类随机 UID 应以 0x08 开头，但并非总是如此。
由于 UID 是协议的“内部”值，所讨论的 APDU 不会发送到卡，而只是（PC/SC 接口的）内部命令，用于从读卡器驱动程序获取 UID。 CLA 0xFF 通常不正常使用，因为它仅用于为“协议参数选择”（PPS）保留。 PC/SC 滥用此 CLA 执行内部命令。
此处的命令是 PC/SC 内部“获取数据”命令，在 PC/SC 规范的第 3 部分第 3.2.2.1.3 节中指定。这里 P1 和 P2 具有特殊的预定义含义，因此尝试不同的值是没有意义的。该标准仅定义 P1=0,P2=0 用于获取 UID，P1=1,P2=0 用于“来自没有 CRC 的 ISO 14443 A 卡的 ATS 的所有历史字节”。不支持其他值。
有趣的是，标准中没有定义答案 0x6A 0x88。 0x6a 0x81 表示“不支持功能”，即没有 UID 的卡（标准提到 7816-10 联系卡）。其他两个定义的答案（0x62 0x82 和 0x6C 0xXX）定义了请求的答案长度和实际数据量之间的不匹配，并且不会在此处发生，因为我们只是通过在请求的最后一个字节中指定 0 来请求任何长度的数据.
那么为什么它对我不知道的提交者不起作用。对我来说它有效，一些卡返回 4 个字节，其他返回 7 个字节。
请参阅 PC/SC 标准，特别是第 3 部分，此处：http://www.pcscworkgroup.com/specifications/specdownload.php
【讨论】：
0xCA 是 GET DATA 命令。您必须在 P1-P2 中提供 TLV 标签。
ISO 7816 第 6 部分“用于交换的行业间数据元素”列出了这些标签，但没有一个明确对应于“卡 ID”。我建议您尝试 P2 的所有值，其中 P1 等于 0x00、0x5F 或 0x7F，以找出您的卡支持哪些数据元素。
【讨论】：
我认为您的第二个命令是正确的，但该卡尚未使用应用程序 ID 进行编程。
对于 6A88，BasicCard 手册说：“如果 BasicCard 中没有配置应用程序 ID，内置命令 GET APPLICATION ID 将返回此错误代码”。
【讨论】：
这是一个经常被讨论的问题。
0xFF, 0xCA, 0x00, 0x00, 0x00 是获取卡 uid 的正确 pcsc 命令。
如果您收到 6E00 响应，则说明您的驱动程序存在错误。更新驱动程序或尝试其他阅读器。
【讨论】：
我试过了：
byte data[] = new byte[]{};
CommandApdu((byte)0xA0, (byte)0xC0, (byte)0x00, (byte)0x00, data)
我得到 SW1=(byte)0x9F SW2=(byte)0xXX 9FXX = "命令执行成功；有‘xx’字节数据可用，可以
使用 GET RESPONSE 请求。"
除了 9F00 和 9F04 这意味着
9F00=PIN 被阻止和解除阻止尝试计数器为 3
9F04=PIN 未成功验证，PIN 被阻止且解锁尝试计数器为 3
【讨论】：