中國工商銀行銀企互聯(lián)系統(tǒng)企業(yè)開發(fā)手冊精講

1、 企業(yè)開發(fā)手冊 1. 文檔屬性文檔屬性內容文檔名稱中國工商銀行銀企互聯(lián)系統(tǒng)企業(yè)開發(fā)手冊文檔版本號A0文檔狀態(tài)正式稿文檔編寫完成日期2011-11-21作 者高小偉（北京開發(fā)三部），丁孚旌（北京開發(fā)三部）2. 文檔變更歷史清單文檔版本號變更日期修改人備注A02011-11-21高小偉給文檔加了首頁，版本號，作者等信息。3. 本次修改變更說明序號變更內容簡述.5.目錄第 1 章概述4第 2 章總體方案介紹42.1總體網絡結構圖42.2企業(yè)端安全服務器簡介42.3安全控制介紹5第 3 章重點說明6第 4 章銀企互聯(lián)NC方式接入客戶84.1企業(yè)端系統(tǒng)環(huán)境要求8軟件環(huán)境8網絡環(huán)境8企業(yè)開發(fā)

2、過程描述8第 5 章銀企互聯(lián)非NC方式接入客戶125.1企業(yè)端系統(tǒng)環(huán)境要求12軟件環(huán)境12網絡環(huán)境13企業(yè)開發(fā)過程描述13第 6 章關于通訊證書和銀行證書的說明19第 7 章磁盤證書拆分197.1證書拆分方法197.2證書拆分后流程19第 1 章 概述銀企互聯(lián)面向大的集團客戶，提供與企業(yè)ERP系統(tǒng)直連的平臺，銀企互聯(lián)面向大的集團客戶，提供與企業(yè)ERP系統(tǒng)直連的平臺，為工行的現(xiàn)金管理服務提供多渠道和客戶化支持。企業(yè)ERP系統(tǒng)通過HTTPS協(xié)議與工行系統(tǒng)進行連接并向銀企互聯(lián)前置發(fā)送數據，數據的接口格式使用標準的xml數據格式，但雙方通訊的過程中則需要遵守下文描述的規(guī)定。銀企互聯(lián)前置接到企業(yè)數據后進

3、行一系列的檢查后完成交易，并將處理結果以企業(yè)便于處理的形式返回給企業(yè)。在安全保證方面，通訊層的安全保證是HTTPS協(xié)議。企業(yè)如需使用銀企互聯(lián)系統(tǒng)，要辦理有關注冊手續(xù)，并審領證書。企業(yè)進行結算類交易時，如果涉及到授權過程，企業(yè)需要在企業(yè)網銀系統(tǒng)中完成相關授權動作。銀企互聯(lián)系統(tǒng)將企業(yè)提交的支付指令或者授權成功后的指令當作最終轉賬指令，根據提交指令的證書ID檢查收付方帳號等合法性，以保證所提交指令在權限允許范圍內進行操作。第 2 章 總體方案介紹2.1 總體網絡結構圖上圖企業(yè)ERP系統(tǒng)1采用的是非NC方式接入的客戶；企業(yè)ERP系統(tǒng)2采用的是NC方式接入的客戶；2.2 企業(yè)端安全服務器簡介此服務器只對

4、使用NC方式接入的客戶有效。企業(yè)端安全服務器被稱為NetSafe Client。它有兩個可以配置的端口分別用于加密和簽名驗簽服務，如下圖所示（假設為加密端口，為簽名驗簽端口）。1（加密）NetSafeClient2（簽名驗簽）1. http交易請求包https交易請求包1.簽名驗簽請求包2.簽名驗簽結果2. 交易結果具體使用時，企業(yè)應用向工行提交交易請求時，可以依照http協(xié)議向NetSafe Client的端口發(fā)送請求。接到請求后，NetSafe Client使用企業(yè)證書將http請求包轉換成https請求包發(fā)往工行端服務器；如果需要對某些交易數據進行簽名，則企業(yè)應用需要與簽名端口建立Soc

5、ket 連接并將待簽名數據發(fā)往端口，然后接收端口的簽名結果，之后再將包含簽名信息的交易請求發(fā)往端口而完成整個交易請求過程。對簽名還是驗簽名請求的區(qū)分則是通過http包頭來進行。Content-Type: INFOSEC_SIGN/1.0和Content-Type: INFOSEC_VERIFY_SIGN/1.0分別用于標識簽名請求和驗簽名請求，而Content-Type: INFOSEC_SIGN_RESULT/1.0和Content-Type: INFOSEC_VERIFY_SIGN_RESULT/1.0分別用于標識簽名和驗簽名的返回結果。為方便起見，可以將NetSafe Client的兩個

6、服務端口邏輯地稱為兩臺服務器，NetSafe Client的加密服務器和簽名服務器。2.3 安全控制介紹對于NC方式接入的客戶ü 企業(yè)向工行提交的交易數據，必須通過企業(yè)方的NetSafe Client進行與工行服務器的連接，接口確定需要簽名的數據也必須由NetSafe Client的簽名服務器簽名后組成規(guī)定的數據包格式后，通過NetSafe Client提交工行，這樣可以保證企業(yè)數據以及相關信息不被惡意篡改。ü 數據全部由NetSafe Client負責轉發(fā)，使NetSafe Client成為架設在企業(yè)現(xiàn)場的工行接入服務器。而企業(yè)與工行之間安全的連接，由NetSafe Cl

7、ient和工行安全代理服務器NetSafe保證；ü 工行接收到企業(yè)提交過來的部分關鍵交易數據后，需要解密并驗證企業(yè)的數字簽名，以防止第三方假冒企業(yè)的行為。對于非NC方式接入的客戶ü 企業(yè)向工行提交交易數據時的安全控制企業(yè)ERP與銀企互聯(lián)系統(tǒng)之間使用HTTPS協(xié)議通訊。企業(yè)可以選擇是否對交易數據進行對稱加密，目前系統(tǒng)支持的算法有DES與3DES。進行對稱加密可以防止第三方截獲交易的信息。而加密中需要用到的密鑰由企業(yè)與工行共同約定。（加密功能暫不支持）企業(yè)需要對其發(fā)送的指令數據進行數字簽名，簽名中使用的證書可以是企業(yè)證書也可以是工行證書，其中簽名使用的算法是SHA1withRS

8、A。進行數字簽名可以防止第三方假冒企業(yè)的行為。ü 工行向企業(yè)發(fā)送結果信息時的安全控制企業(yè)ERP與銀企互聯(lián)系統(tǒng)之間使用HTTPS協(xié)議通訊。企業(yè)可選擇是否對返回數據進行對稱加密，方法與上文相同。工行對部分關鍵交易返回信息進行數字簽名。第 3 章 重點說明Ø xml格式要支持業(yè)界公認的標準格式，例如：<Tag />等同于<Tag></Tag>；上送數據格式盡量簡單，避免使用CDData等文本格式。Ø 所有的交易請求包中“包序列ID”2002年12月23日發(fā)送的一個交易請求包的包序列ID）。在一個企業(yè)代碼下當日包序列ID必須唯一。工行處

9、理完畢之后將該字段原值返回，即所有的交易返回包中“包序列ID”字段（PackageID）。Ø 轉帳交易請求包中“簽名時間”字段（SignTime），格式為yyyyMMddhhmm2002年12月23日9點27分10秒568毫秒）。簽名時間應為北京時間。簽名時間如果與交易請求到達工行服務器時的北京標準時間誤差過大（暫定為15分鐘），交易將無法進行。此措施將可以有效地防止黑客采用重放攻擊進行干擾帳務活動的行為。同一筆交易如果因為網絡不正常等因素需要重新提交時，要修改轉賬交易請求包的“簽名時間字段”并重新簽名。Ø 所有請求包和返回包中備用字段的使用主要是出于對今后擴展的考慮，如果

10、以后需要增加企業(yè)上送的項目或者返回給企業(yè)的信息，不必再改變交易包格式。目前對企業(yè)請求包來說這些備用字段的值可以送空；企業(yè)對銀行返回包中的備用字段也不必作處理。請求包中的備用字段標簽為“ReqReserved*”，返回包中的備用字段標簽為“RepReserved*”（其中*為1、2、3或4，詳見接口說明文檔）。Ø 查詢歷史明細返回數據包中交易時間（<Trans_time></Trans_time>）數值如為空，則說明該筆指令是銀行的計息交易明細。Ø 支付查詢指令接口，方便企業(yè)對可疑、有疑問（如網絡中斷，交易長時間沒有返回等）或處理完畢的轉帳指令進行查詢

11、。企業(yè)提交要查詢的結算請求的包序列ID，工行返回該筆轉帳指令的基本信息和狀態(tài)。Ø 本接口說明中所有涉及金額的字段都是以分為單位（不帶小數點）。Ø 如企業(yè)系統(tǒng)需要代理匯兌功能則企業(yè)應用需同步開發(fā)網點信息下載交易，以便為代理匯兌交易中收方為它行情況時提供工行網點名稱。否則，無需開發(fā)網點信息下載交易。Ø 在網點信息下載功能中，由于下載數據過大且數據不會經常更新，所以此交易控制了企業(yè)每日下載次數。目前暫定次數為每日2次。Ø 個人聯(lián)名卡簽權指令只支持幣種是人民幣的賬號/卡號。Ø 企業(yè)端傳輸數據時，指定xml編碼方式為GBK。Ø 銀企互聯(lián)提交包中

12、包含“<SignTime>簽名時間（yyyyMMddhhmmssSSS）</SignTime>”此標簽的，說明該交易需要進行簽名處理。Ø 企業(yè)端的程序需要對銀行返回的數據有可擴展性，以便適應今后業(yè)務的不斷發(fā)展。Ø 銀企互聯(lián)系統(tǒng)支持兩種接入方式，客戶可以任何選擇一種。第一種：使用第三方NC軟件方式接入銀企互聯(lián)系統(tǒng)；第二種：使用非NC方式企業(yè)直接接入銀企互聯(lián)系統(tǒng)；Ø 一些接口中，返回包分文件級返回包和指令級返回包兩種。文件級返回包是作為客戶請求的響應信息同步返回的。而指令級返回包是銀行主動發(fā)起的異步返回信息，表示指令處理的結果，指令級返回包首先

13、會返回整批指令的處理結果，然后對于其中指令狀態(tài)非最終狀態(tài)（成功和失?。┑闹噶?，銀行會實時更新每一條指令的狀態(tài)，然后再每條分別以指令級返回包的格式返回給客戶。Ø 建議客戶使用HTTP/1.1協(xié)議。HTTP/1.0及其以下協(xié)議版本可能無法正常發(fā)送指令到銀行端。下面將區(qū)分兩類客戶分別對接入方式等相關信息進行說明。第 4 章 銀企互聯(lián)NC方式接入客戶4.1 企業(yè)端系統(tǒng)環(huán)境要求4.1.1 軟件環(huán)境對企業(yè)的ERP系統(tǒng)無要求；工行企業(yè)端證書服務器軟件NetSafe Client需安裝在一臺PC機上。4.1.2 網絡環(huán)境企業(yè)財務系統(tǒng)通過局域網與工商銀行提供的NetSafe Client連接；企業(yè)端的

14、NetSafe Client可以通過專線或INTERNET與中國工商銀行銀企互聯(lián)系統(tǒng)互聯(lián)。4.1.3 企業(yè)開發(fā)過程描述 企業(yè)提交交易請求數據過程企業(yè)提交的交易分為兩大類：查詢類和結算類（需要進行簽名處理）。1、 查詢類：（1） 企業(yè)按照工行提供的xml包格式進行打包，在局域網內通過http協(xié)議以POST方式將交易包發(fā)送到NetSafe Client的安全http協(xié)議服務器。http請求格式：action=”http:/客戶端NetSafe Client的地址和加密端口號/servlet/ICBCCMPAPIReqServlet?userID=證書ID&PackageID=

15、包序列ID &SendTime=請求時間”http請求包頭信息：Content-Type應為application/x-www-form-urlencoded請求數據格式（post方式）：Version=版本號（目前支持和兩個版本。不同版本號對應的接口格式不同，請參考具體交易的接口文檔) &TransCode=交易代碼（區(qū)分交易類型，每個交易固定)&BankCode=客戶的歸屬單位&GroupCIS=客戶的歸屬編碼&ID=客戶的證書ID（無證書客戶可空)&PackageID=客戶的指令包序列號（由客戶ERP系統(tǒng)產生，不

16、可重復)&Cert=客戶的證書公鑰信息（進行BASE64編碼；NC客戶送空) &reqData=客戶的xml請求數據其中：包序列ID、證書ID應根據實際情況進行更改，請求時間為企業(yè)發(fā)出該交易請求包的當前系統(tǒng)時間。post方式最后不允許有回車等其他亂字符，TransCode交易名稱應與xml包內標簽<TransCode></TransCode>中的值一致，action中的證書ID、PackageID與請求數據格式中的證書ID、PackageID、xml包中的證書ID、PackageID的值三者相一致。（2） NetSafe Client將xml包加密后按照

17、https協(xié)議，通過互聯(lián)網/專線發(fā)送到銀行端的NetSafe Server。（本步由NetSafe Client完成，企業(yè)無需處理）；（3） NetSafe Server將交易請求送銀企互聯(lián)系統(tǒng)進行處理。企業(yè)NetSafe ClientNetSafe Server（1）（2）工行（3）2、 結算類：（1） 企業(yè)按照工行提供的xml包格式進行打包，在局域網內與NetSafe Client的簽名端口建立Socket連接，通過此連接向簽名端口發(fā)送http數據包。http包頭中需包含“Content-Length”和“Content-Type”兩個屬性。其中“Content-Length:”后面是需要

18、簽名的二進制數據包的長度，“Content-Type:”后面是需要簽名的標記，為INFOSEC_SIGN/1.0。（注意大小寫）http請求格式：action=”http:/客戶端NetSafe Client的地址和簽名端口號”請求數據格式：結算類請求提交的xml包NetSafe Client對xml包進行簽名后，通過http協(xié)議將簽名結果返回給企業(yè)系統(tǒng)。如簽名成功<sign>標簽與</sign>標簽之間的部分為簽名結果。NetSafe Client返回的簽名包如下：<html><head><title>簽名結果</title&

19、gt;<result>0</result></head><body><sign>MIIIXAYJKovcNAQcCo. 0BlLdSgw=</sign></body></html>（2） 企業(yè)按照工行提供的xml包格式進行打包，在局域網內通過http協(xié)議以POST方式將交易包發(fā)送到NetSafe Client的安全http協(xié)議服務器。http請求格式：action=”http:/客戶端NetSafe Client的地址和加密端口號/servlet/ICBCCMPAPIReqServlet?userI

20、D=證書ID&PackageID=包序列ID &SendTime=請求時間” 請求數據格式（post方式）：Version=版本號（區(qū)分版本時間，暫定.1) &TransCode=交易代碼（區(qū)分交易類型，每個交易固定)&BankCode=客戶的歸屬單位&GroupCIS=客戶的歸屬編碼&ID=客戶的證書ID（無證書客戶可空)&PackageID=客戶的指令包序列號（由客戶ERP系統(tǒng)產生，不可重復)&Cert=客戶的證書公鑰信息（進行BASE64編碼；NC客戶送空) &reqData=客戶的xml請求數據其中：包序列ID、證

21、書ID應根據實際情況進行更改，請求時間為企業(yè)發(fā)出該交易請求包的當前系統(tǒng)時間。post方式最后不允許有回車等其他亂字符，TransCode交易名稱應與xml包內標簽<TransCode></TransCode>中的值一致，action中的證書ID、PackageID與請求數據格式中的證書ID、PackageID、xml包中的證書ID、PackageID的值三者相一致。（3） NetSafe Client將企業(yè)送來的簽名包加密后按照https協(xié)議，通過互聯(lián)網/專線發(fā)送到工行端的NetSafe Server，再發(fā)往工行網銀進行處理。（本步由NetSafe Client完成，企

22、業(yè)無需處理）。企業(yè)NetSafe ClientNetSafe Server（1）（2）（3）（4） 企業(yè)接收交易響應數據過程企業(yè)接收到數據包的格式：reqData=交易返回包 或 errorCode=錯誤代碼步驟：判斷返回數據中是否是errorCode：（1）如果是：根據錯誤代碼做相應處理，結束。錯誤代碼的含義參見接口說明文檔中的附錄。（2）如果否：企業(yè)接收到數據包的格式：reqData=交易結果包；企業(yè)根據先進行BASE64解碼，簽名返回包按照格式拆分出明文和密文，驗簽正確后對明文按工行提供的xml包格式進行解包。對于單筆提交類指令（即存在文件級返回包的指令），返回的xml包格

23、式按照指令級返回包格式來處理，多筆則按照文件級返回包格式來處理。 企業(yè)接收銀行主動返回過程http請求格式：action=”http:/客戶ERP服務器的地址和端口號” 請求數據格式（post方式）：Version=版本號（.1，不同版本號對應的接口格式不同，請參考具體交易的接口文檔) &TransCode=交易代碼（區(qū)分交易類型，每個交易固定)&BankCode=客戶的歸屬單位&GroupCIS=客戶的歸屬編碼&ID=客戶的證書ID（無證書客戶可空)&PackageID=客戶的指令包序列號（由客戶ERP系統(tǒng)產生，不可重復)&Cer

24、t=客戶的證書公鑰信息（進行BASE64編碼；NC客戶送空) &reqData=客戶的xml請求數據reqData數據格式：如果需要簽名，格式為：數字字符串：長度10位，代表明文數據長度，不足10位左補0；明文：xml明文，長度可變，需要上面的數據指明，雙字節(jié)字符（漢字）算作1位長度；分隔符：ICBCCMP；密文：明文經過簽名后的數據并做BASE64編碼；如果不需要簽名，則直接送xml明文；以上數據經過拼接后，再進行BASE64編碼（僅reqData項）得到最終的reqData數據。按照以上格式將請求數據發(fā)送到企業(yè)；此格式返回的數據是不經過NC的，是銀行直接發(fā)給企業(yè)的ERP系統(tǒng)；如有使

25、用，企業(yè)需要在內管注冊或者修改集團信息時填入企業(yè)用于接收銀行反饋的地址，標準格式是http:/ip:port；編解碼方式查看. 報文版本號說明當存量接口無法滿足客戶需求且無備用字段可擴充時，進行接口版本號的升級。升級后的接口保持TransCode不變，Version提升，使用新接口的客戶，請求報文應與相應版本的報文格式保持一致。同時，要求使用新版本的客戶系統(tǒng)按照自動擴展解析方式調用開發(fā)。即：企業(yè)客戶根據銀企互聯(lián)接口數據返回包定義的 “是否可選”標記來判斷解析原則，如果標志為“否”的，需要客戶系統(tǒng)校驗標簽節(jié)點，如果為“是”的，客戶系統(tǒng)可根據自身需求決定是否拓展。第 5 章 銀企互

26、聯(lián)非NC方式接入客戶5.1 企業(yè)端系統(tǒng)環(huán)境要求5.1.1 軟件環(huán)境對企業(yè)的ERP系統(tǒng)無要求；5.1.2 網絡環(huán)境企業(yè)財務系統(tǒng)可以通過專線與中國工商銀行銀企互聯(lián)系統(tǒng)互聯(lián)。5.1.3 企業(yè)開發(fā)過程描述 企業(yè)提交交易請求數據過程（1） 企業(yè)按照工行提供的xml包格式進行打包，在局域網內通過http協(xié)議以POST方式將交易包發(fā)送到銀行前置機。http請求格式：action=http:/銀行通訊前置的地址和加密端口號? 請求數據見下面“請求數據格式（post方式）”http包頭信息：Content-Type應為application/x-www-form-urlencoded請求數據格式（

27、post方式）：Version=版本號（目前支持和兩個版本。不同版本號對應的接口格式不同，請參考具體交易的接口文檔) &TransCode=交易代碼（區(qū)分交易類型，每個交易固定)&BankCode=客戶的歸屬單位&GroupCIS=客戶的歸屬編碼&ID=客戶的證書ID（無證書客戶可空)&PackageID=客戶的指令包序列號（由客戶ERP系統(tǒng)產生，不可重復)&Cert=客戶的證書公鑰信息（進行BASE64編碼；NC客戶送空) &reqData=客戶的xml請求數據其中：包序列ID、證書ID應根據實際情況進行更改

28、，請求時間為企業(yè)發(fā)出該交易請求包的當前系統(tǒng)時間。post方式最后不允許有回車等其他亂字符，TransCode交易名稱應與xml包內標簽<TransCode></TransCode>中的值一致，action中的證書ID、PackageID與請求數據格式中的證書ID、PackageID、xml包中的證書ID、PackageID的值三者相一致。reqData數據格式： 如果需要簽名：數字字符串：長度10位，代表明文數據長度，不足10位左補0；明文：xml明文，長度可變，需要上面的數據指明，雙字節(jié)字符（漢字）算作1位長度；分隔符：ICBCCMP；密文：明文經過簽名后的數據并做B

29、ASE64編碼；如果不需要簽名，則直接送xml明文；以上數據經過拼接后，再進行BASE64編碼得到最終的reqData數據。以上每項請求參數的值（全部參數項）均應做一次URLEncode編碼，然后按照以上格式將請求數據發(fā)送到工行； 企業(yè)接收交易響應數據過程企業(yè)接收到數據包的格式：reqData=交易返回包 或 errorCode=錯誤代碼reqData=交易返回包結構：如果交易返回包進行了簽名，則結構為：數字字符串：長度10位，代表明文數據長度，不足10位左補0；明文：長度可變，需要上面的數據指明，雙字節(jié)字符（漢字）算作1位長度；分隔符：ICBCCMP；密文：明文經過簽名后的數據

30、；如果交易返回包沒有簽名，則結構為：明文；不論是否簽名，交易返回包均進行了BASE64編碼；步驟：判斷返回數據中是否是“errorCode=”打頭：（1）如果是：根據錯誤代碼做相應處理，結束。錯誤代碼的含義參見接口說明文檔中的附錄。（2）如果否：企業(yè)接收到數據包的格式：reqData=交易結果包企業(yè)根據先進行BASE64解碼，簽名返回包按照格式拆分出明文和密文，驗簽正確后對明文按工行提供的xml包格式進行解包。對于單筆提交類指令（即存在文件級返回包的指令），返回的xml包格式按照指令級返回包格式來處理，多筆則按照文件級返回包格式來處理。 企業(yè)接收銀行主動返回過程http請求格式：

31、action=”http:/客戶ERP服務器的地址和端口號” 請求數據格式（post方式）：Version=版本號（.1，不同版本號對應的接口格式不同，請參考具體交易的接口文檔) &TransCode=交易代碼（區(qū)分交易類型，每個交易固定)&BankCode=客戶的歸屬單位&GroupCIS=客戶的歸屬編碼&ID=客戶的證書ID（無證書客戶可空)&PackageID=客戶的指令包序列號（由客戶ERP系統(tǒng)產生，不可重復)&Cert=客戶的證書公鑰信息（進行BASE64編碼；NC客戶送空) &reqData=客戶的xml請求數據reqData

32、數據格式：如果需要簽名，格式為：數字字符串：長度10位，代表明文數據長度，不足10位左補0；明文：xml明文，長度可變，需要上面的數據指明，雙字節(jié)字符（漢字）算作1位長度；分隔符：ICBCCMP；密文：明文經過簽名后的數據并做BASE64編碼；如果不需要簽名，則直接送xml明文；以上數據經過拼接后，再進行BASE64編碼（僅reqData項）得到最終的reqData數據。按照以上格式將請求數據發(fā)送到企業(yè)；此格式返回的數據是銀行直接發(fā)給企業(yè)的ERP系統(tǒng)；如有使用，企業(yè)需要在內管注冊或者修改集團信息時填入企業(yè)用于接收銀行反饋的地址，標準格式是http:/ip:port；編解碼方式查看.5企業(yè)簽名驗

33、簽過程在銀企互聯(lián)中，對于指令體的簽名與驗簽工作由純java版工行簽名驗簽接口完成的。本文檔對在專業(yè)版銀企互聯(lián)中使用的接口作出描述。同時提供了一套純java版的從企業(yè)發(fā)送指令到工行系統(tǒng)和從工行系統(tǒng)接收處理結果的例子程序。從企業(yè)發(fā)送指令到工行系統(tǒng)的例子中包括了兩方面的內容：用企業(yè)的數據層私鑰對數據進行簽名，然后用工行的通訊層公鑰進行通訊認證；從工行系統(tǒng)接收處理結果的例子中包括了兩方面的內容：用企業(yè)的通訊層私鑰要求通訊認證，然后用工行的數據層公鑰進行數據的驗簽。使用這種接入方式的客戶只能使用磁盤證書；該磁盤證書需要拆分，拆分為一對數據層證書，用于簽名驗簽；一對通訊層證書，用于建立與銀行的https連

34、接。拆分方法見第7章企業(yè)簽名驗簽方法總體介紹接口包含icbc.jar、InfosecCrypto_Java1_02_JDK14.jar、tools.jar四個文件，使用時需要把這四個文件放置到java的classpath目錄中。該接口建議的JDK 版本為。（不要使用JDK1.5版本或者比1.4更低版本）接口使用的詳細說明Sign（對原始數據進行數字簽名的函數）public static byte sign(byte src, int len, byte privateKey, char keyPass)Description 用rsa算法對一段消息簽名 Param

35、eters: privateKey - 為口令保護的私鑰 src - 為待簽名消息 len - 為待簽名消息的長度keyPass - 為私鑰保護口令 Returns: 如果成功返回簽名結果,如果失敗返回null Throws: NoSuchProviderException - NoSuchAlgorithmException - InvalidKeyException - SignatureException - verifySign（對數字簽名進行驗簽的函數）public static int verifySign(byte src, int len, byte cer

36、t, byte sign)Description 用rsa算法對一段簽名進行驗證 Parameters: cert - 為證書 src - 為被簽名的消息 len - 為被簽名消息的長度sign - 為簽名的結果 Returns: 如果成功返回0,如果其它則失敗 Throws: SignatureException - NoSuchAlgorithmException - InvalidKeyException -附件說明1 ceshizhang.cer ，ceshizhang.key是一套客戶證書的公鑰與私鑰，保護口令是12345678。2 Test.java是一個演示各個接口使用

37、方式的測試程序。3 APIforZHEJIANG文件夾指導企業(yè)開發(fā)的例子程序；使用說明例子的使用說明。4 附件如下 https服務器建立開發(fā)支持請參考上面附件中APIforZHEJIANGAPIforZHEJIANGicbcapiserver.java開發(fā)。使用說明文檔介紹了開發(fā)方法。 Base64編解碼方法參考建議使用sun提供的BASE64編解碼方法實現(xiàn)。/* * base64解碼 * param s:需要解碼的數據 * return 解碼后的數據 */public static String getstrFromBASE64(String s) if (s = null)return null;sun.misc.BASE64Decoder decoder = new sun.misc.BASE64Decoder();try byte b = decoder.decodeBuffer(s);return new String