象其它許多新技術一樣，關于智能卡有許許多多令人眼花繚亂的技術標準。對于下面這些標準形成初步的了解之后，你就會大體上掌握智能卡應用程序設計的基本技術要點。當然對于一些系統的特殊標準還須另外掌握。我把這一向、整套標準分成“橫向的”和“縱向的”兩個部分：橫向的標準可以被所有的應用程序所用，而縱向的標準僅僅適用于特定的系統。 

　　橫向的標準 

　　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應用程序與智能卡之間的通信

　　你知道了如何將所有硬件連接在一起�，F在我們需要如何使用一些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 抽象至單一平臺是一個極為明智的選擇。

原創作者：北京易訊卡科技有限公司