象其它许多新技术一样，关于智能卡有许许多多令人眼花缭乱的技术标准。对于下面这些标准形成初步的了解之后，你就会大体上掌握智能卡应用程序设计的基本技术要点。当然对于一些系统的特殊标准还须另外掌握。我把这一向、整套标准分成“横向的”和“纵向的”两个部分：横向的标准可以被所有的应用程序所用，而纵向的标准仅仅适用于特定的系统。 

　　横向的标准 

　　ISO7816－－描述到智能卡底层接口标准。这种标准定义智能卡阅读器和智能卡之间如何传递字节流。 

　　PC/SC－－定义运行Win3.1/Win95/NT的机器与智能卡之间通信的标准。 

　　OCF－－定义从Java应用环境和智能卡之间的通信标准，该标准完全是Java接口。（很快，OCF 将允许开发者向OCF输出，并执行转换，这样开发者再无必要使用PC/SC了。） 

　　JavaCard－－描述JavaCard和它所支持的标准。

　　纵向的标准 

　　Mondex－－以智能卡形式实现的数据现金。Mondex不允许存在于卡片之外的现金。 

　　VisaCash－－这种借贷卡可以用于跟踪服务器上的卡。 

　　Proton－－另外一种形式的电子货币卡 

　　MPCOS-EMV－－这是一种通用的智能卡，它允许你实现自己的货币或是令牌。

我自己常常感觉到疑惑不解：对于这样一块小小的塑料卡片，为什么会有如此之多的文档描述其标准，而且开发者又要掌握大量的知识才能去开发它？ 

　　因为进行智能卡的开发要求高度的专业知识，所以市场上需要支持Beans的产品，这种产品应该用横向的标准去实现纵向标准的。这意味着你可以使用各式各样的横向标准组合开发出Beans产品来，就象OpenCard一样，为了实现特定的一个应用程序而采用其它几家商用标准或是其它的应用程序。 

　　Java小应用或是Java应用程序与智能卡之间的通信

　　你知道了如何将所有硬件连接在一起。现在我们需要如何使用一些API，这些API可以从应用程序向智能卡阅读器发出命令。（阅读器然后与智能卡打交道，作为一个应用程序到智能卡之间的信息传递媒介。）智能卡阅读器移动其与智能卡接触的金属尖端传递数据。智能卡对数据做出处理之后反还给阅读器，而阅读器再将之传会应用程序。下面的问题是，在这些数据从应用程序流向智能卡之时，它们究竟处于何处？ 

　　正如前所述，应用程序与阅读器通信，而阅读器将使用上面介绍的标准再与智能卡通信。基本上，随着智能卡技术的发展，ISO推出了一套智能卡标准。该标准定义了智能卡的机械和电器特性以及与智能卡通信的标准。与ISO该标准相关的文档列在参考资料当中。不幸的是，ISO没有能够提供与阅读器相互通信的标准。因此，为了向智能卡发出一条命令，首先你要找出智能卡支持的命令集合，将该命令用ISO命令包封装，然后将这个包再以适合于阅读器的格式封装。下面的例程正是完成所有这些琐事。 

　　Application Procotols Data Units(APDUs) 

　　与智能卡交换信息的基本单元就是APDU包。从应用程序层传出的命令消息，加上从智能卡返回到应用程序的回应消息均称为ApplicationProcotolsDataUnits(APDU)。与智能卡和阅读器的通信以APDU形式实现。一个APDU包可以看作包含完整指令或是回应的数据包。为了提供这样的功能，在ISO7816规范家族里有一部分为APDU定义了一个良好的结构。 

　　APDU包含如下域： 

　　命令APDU格式 

CLA INS P1 P2 Lc Data Le  

　　回应APDU格式 

Data SW1 SW2  

　　下面是一些支持APDU传输的类及其功能描述： 

　　Command－－封装命令APDU 

　　Response－－封装回应APDU 

　　ISOCardReader－－规定一个接口。每一种设备必须实现该接口 

　　ISOCommand－－构成一个ISOCommand并从ISOCardReader接口执行该命令

与智能卡通信 

　　Sun开发了JavaElectronicCommerceFramework(JECF)，这是对核心Java平台的扩展，它允许开发者轻松快速的开发商用电子应用程序。JECF提供几种与智能卡通信的类。 

　　我们这里讨论的智能卡分别有一条读取数据和写入数据的命令。它是由GemPlus提供的名为GFM卡。你也可以使用其它类型的智能卡，只要它们支持ISO7816标准并且你了解它们的APDU命令格式。当然还要做一点程序工作。GFM卡的内存是以64个比特或是8个字节为单位的。你必须用模8的算法读写数据。换句话说，你不能向GFM卡做一次长度为1k连续的写入。我们这里提供的Java代码完成这项功能。一些新的智能卡支持更大单位的读写单位。因此，为了写入字符串“0123456789”，你必须发出两条适当编址的命令。（是的，智能卡就是这样难于编程。）当存储型卡和处理器型卡相互融合时，这种限制也许会消失。 

　　为了读取上面那条字符串，你应该发出“read”命令。这两种命令按照APDU的术语被格式化的写在了下面。在我们的例子中利用了Java读写智能卡。下面表中的值示出如何组成一个APDU。在GCM编程指南中定义了APDU的结构。 

Location of data Upper Lower

256 0x00 0x00 

1023 0x00 0x00

3093 0x00 0x00 

　　“upper”和“lower”是地址的高位和低位字节。举几个例子可能会有助于明晰概念。这张 表的upper和lower值提供了存储数据的确定地址。我们讨论过的向GPM896智能卡通信的两 种方法是： 

ISOCommand(0,0xD0,0,upper,lower,8);//Write 8 bytes to the address 

ISOCommand(0,0xB0,0,upper,lower,8);//Read 8 bytes from the address  

　　浏览器与智能卡之间的通信 

　　三个本地接口的存在表明对主要的开发者集团缺乏了解，没有能够充分考虑如何向处 于Java开发环境的开发者们提供简单易于记忆的API。如果所有的销售商均支持JNI，至少 接口可保持一致，你不必化大量的时间去把接口绑定。当然你必须书写少量的本地代码，但 拥有统一的接口还是有价值的。我尝试了所有三种API，*终发现JNI要比其它的更为一致，并且也*为简单、易于实现。联合HotJava一块使用是*佳的，这样你可以对与串口通信的 类签名，然后安全的使用它们，比起另外两种浏览器来讲麻烦要少的多。Sun*近还宣布帮 助浏览器公司实现新版JDK/JVM的建议。 

　　前面的讨论围绕如何与一个不支持JDK的硬件设备通信。在下面的几篇文章里我们将不再使用“本地接口”，而是使用一个工业标准与智能卡通信。我所选择的这项标准就是带有PC/SC桥的OpenCard标准。我将用OpenCard而不是PC/SC书写应用程序，为什么呢？ 

　　作为开发者，你拥有多种选择。通常来讲这是一件好事，但这也可能导致成本升高和功 能的不一致性，尤其是当你选择的API并不被多种平台所支持时。例如，你决定用PC/SC标准 书写支持Win32系列平台的智能卡应用程序。如果你的应用程序是一个顾客使用的应用并 且将用在WebTV之上，你的选择就是完全错误的。显示器上将会闪动一条信息：“等待WebTV 的Pentium版本。”智能卡是用在Win32桌面和CE单元以外的市场之上的。那么你应该如何呢 ？使用OpenCard标准，抛弃缺乏一致JNI绑定的Internet Explorer。事实上，我认为将所有API 抽象至单一平台是一个极为明智的选择。

原创作者：北京易讯卡科技有限公司