SO JCRE规范提到，如果另一个小程序有新的选择apdu，则调用当前选择的小程序“ deselect”方法。从文件系统中选择文件呢？选择文件会导致调用当前选定的applet的deselect方法吗？
答案 0 :(得分：5)
否，如果文件属于该小程序，则选择文件不会取消选择该小程序。 但是，如果选择其他小程序，则意味着取消选择当前小程序。
答案 1 :(得分：2)
否，选择文件不会取消选择小程序。当前活动的上下文保持活动状态。系统的Java Card运行时会捕获任何按名称APDU进行的SELECT并进行处理。这意味着只有XX A4 04 YY后跟AID的APDU才可以选择applet，因此可以取消选择（我在此答案中忽略了通道）。
这有一些-可能是意料之外的问题：
尽管Java卡使用APDU，但它与文件系统卡有很大不同。最初，Java Card附带了文件系统API，可以更轻松地模拟完整的ISO 7816-4文件系统卡。然而，那已经很久了；基本上，Java Card现在只使用“按名称选择”来选择Applet。
如果卡上还有其他文件系统功能，那么它们要么是扩展运行时的一部分-那里有文件系统卡/ Java Card混合驱动器-要么文件系统功能仅仅是在applet中实现。可以将一个小程序安装为默认选定的小程序，该小程序在开机或重置卡后会被选中。此小程序还可以实现文件系统，但是在运行时处理（成功的）“按名称选择”命令（成功）之后，仍将取消选择该小程序。
从某种意义上来说，相对特别的applet是Card Manager，它也实现了一个安全域。这就是我要说的最后一点：要了解所有这些工作原理，最好阅读可免费获得的Card规范中的Global Platform的正确部分，而不仅仅是Java Card规范。请注意，仅GP（用于？）定义了短长度的APDU，这意味着使用扩展长度的按名称APDU进行的选择很可能会失败。
请注意，按名称APDU的SELECT总是在运行库处理完之后传递给当前活动的小程序（如果有）。这允许小程序为未注册的AID处理按名称进行的SELECT。在P2未设置为0C的情况下，它还允许该applet返回文件控制信息（在这种情况下，applet 不应不返回任何信息）。
由于工作环境的变化，我无法加入Global Platform组来更改Java Card applet选择的工作方式。实现依赖于文件系统的协议极其困难，该文件系统在MF中包含许多文件。显然，需要一种更具针对性的方法，以允许使用不同的方法（例如按路径选择）为小程序选择/取消选择留出更多空间。
不幸的是，诸如ePassport之类的协议确实使用了一些令人讨厌的ISO 7816-4指定的功能，包括广泛使用MF。不过，在ePassport协议中，这和Java Card问题一样是一个错误。 ISO 7816-4为协议/文件系统实现留下了许多细节这一事实无济于事。这可能只是最糟糕的定义标准。它的不确定性和模棱两可只有其受欢迎程度相匹配。
答案 2 :(得分：1)
我将根据我的经验进行回答，我愿意进行讨论，因为这是我总是很奇怪的问题。选择小程序和DF的命令非常相似，尽管选择DF可以实现您在应用程序中喜欢的INS；）
00 A4 04 00 LC AID/DFID
假设卡上有两个应用程序：
0102030405060A的AID ABABABABABAB 0102030405060B的AID 0102030405060A APDU跟踪将是这样的：
> 00 A4 04 00 07 0102030405060A
< 90 00 --> AppA selected
> 00 A4 04 00 06 ABABABABABAB
< 90 00 --> DF within AppA selected
> 00 A4 04 00 07 0102030405060B
> 90 00 --> AppB selected
> 00 A4 04 00 07 0102030405060A
< 90 00 --> AppA selected
至少在一段时间前，我做了一些测试，结果就是这样。选择命令A4首先由卡管理器处理，然后如果没有与ID相匹配的应用程序，它将被重定向到当前选择的应用程序。
如果有时间让我知道，我会尝试重复该测试。
P.S .：我通常使用Optelio卡，但我不知道这种行为是否与卡有关。