證券和銀行之間轉帳系統的設計

來源:互聯網
上載者:User
設計

    為了方便股民在他的股票資金帳戶和銀行帳戶之間方便的進行資金的劃撥,需要設計一個應用程式層協議來實現這個功能。一般都是基於TCP/IP協議設計高層的應用協議,並通過特定的應用程式實現這個功能。現在的實現都是基於客戶/伺服器模式來實現這個功能,證券公司做為用戶端,而銀行做為伺服器端。這樣,證券公司很大程度上只能選擇一家銀行來實現帳戶的劃撥,這樣對於在其他銀行開戶的使用者就相對不是很方便。
  我們設計了一個通過WWW伺服器之間的通訊實現轉帳的協議體繫結構,能夠保證一個證券公司同時可以和多個銀行進行互動,而同時,一個銀行也可以同時和多個證券公司進行互動。
我們協議的設計是基於XML的標記模型(元素/屬性)而建立的。我們的目的之一是建立一個和實現無關的通訊協議。每一個訊息由一個有效XML文檔組成,在通訊的兩端(銀行和證券)通過發送和接收文檔來進行互動。
  實際上我們的協議是建立在HTTP基礎上,是通過HTTP來進行傳輸的。我們採用的是HTTP的POST/Response機制。我們協議的本身沒有考慮安全問題,因為W3C組織正在制定一些非常可靠的安全機制,我們的通訊安全完全可以通過這些機制來實現。同時加密也可以在傳輸層實現,比如通過SSL,PGP或者是S/MIME。通訊雙方可以通過在通訊層使用認證的方法進行認證。


  協議設計的總體說明
  使用者的資金能夠在證券公司和銀行之間進行劃撥的前提是使用者必須在銀行和證券公司都擁有自己的帳號,比如在證券公司使用者需要有股票資金帳戶,在銀行需要有活期帳戶(只有活期存款可以隨時進行劃撥)。我們設計的協議不考慮這些帳號的開戶,即我們認為這些帳號是已經建立起來了。
  我們設計的協議允許使用者既可以在銀行,也可以在證券公司辦理轉帳功能。只要這兩個機構已經連網並且使用者在這兩個機構都擁有自己的帳號。實際上,比如在銀行端,銀行會儲存和該使用者活期存款帳號相關的所有資訊,如果使用者需要在銀行端辦理轉帳功能,只要使用者能夠提供銀行活期存款帳號的號碼和正確的密碼,同時又能夠提供證券公司的資金帳號和密碼,系統首先會在本地尋找該活期存款帳號是否存在,密碼是否相符,如果是的話,會判斷該活期存款帳號是否已經和使用者提供的證券公司的資金帳號相關聯,如果已經相關聯的話,就返回一個錯誤資訊,表示使用者已經辦理過該業務。如果還沒有相關聯的話,銀行通訊伺服器就會和證券公司的相關的通訊伺服器相聯絡,如果證券公司返回資訊認為使用者提供的資金帳號和密碼都是正確的話,這樣就在銀行和證券公司的相關的資料庫中分別加上標誌,來表明某個特定的資金帳號已經和某個特定的活期存款帳號相關聯。這樣,轉帳功能就建立起來了。同時,會隨機產生一個授權碼,該授權碼是使用者進行轉帳時所需要鍵入的密碼,用來表示使用者有許可權執行這個操作。事實上,在證券公司端辦理轉帳功能的基本流程也和這個相類似。
  當使用者已經辦理了轉帳功能以後,事實上,使用者可以自己通過瀏覽器(需要支援XML格式)自行進行資金帳戶的劃撥。在劃撥的時候需要注意的是,只有帳戶中的餘額大於要劃撥的款項的時候才能進行劃撥。在滿足這個條件的情況下,使用者既可以把活期存款中的部分款項劃撥到資金帳戶中,也可以把資金帳戶中的款項劃撥到活期存款中。大大方便了使用者資金的調度和操作。
  我們設計的協議主要是針對證券公司的轉帳伺服器和銀行的轉帳伺服器之間的通訊而言的,一個證券公司的轉帳伺服器可以和多個銀行的轉帳伺服器進行通訊,而一個銀行的轉帳伺服器也可以同時和多個證券公司的轉帳伺服器進行通訊。事實上,可以認為這些通訊伺服器都是WWW伺服器。


  協議設計細節描述
  下面我們具體描述協議的設計和相關的實現的細節:
  協議包總體格式
  首先我們來看整個通訊協議的總的體繫結構:
  < !ELEMENT 資訊負載 (資訊頭,(請求資訊|響應資訊))>
  < !ATTLIST 資訊負載
    版本號碼 CDATA #REQUIRED
    時間標籤 CDATA #REQUIRED
   >
  一條訊息主要有三個元素組成:資訊負載,資訊頭和請求資訊或者是響應資訊。資訊負載是對這個資料包屬性的描述,資訊頭用來表示資訊的寄件者和接收者,請求資訊或者是響應資訊是訊息的主體內容。


  資訊負載包括兩個屬性:
   版本號碼:用來表示通訊所使用的版本,必須保證通訊雙方使用相同的版本號碼。這裡我們設定為1.0
   時間標籤:用來表示該資料包發出的時間。實際時間標籤的格式我們設定為:YYYY:MM:DDTHH:MI:SS,其中T是日期和時間的一個分隔標誌符。比如:2000:03:01T10:22:33就是一個有效時間標籤。


  下面是關於資訊頭的定義:
   <!ELEMENT 資訊頭(資訊寄件者,資訊接收者)>
     資訊頭主要有兩部分組成,資訊的寄件者和資訊的接收者。用來表示訊息的發出方和訊息的接收方。訊息發送發出方和接收方擁有相同的屬性。它們的定義格式如下:
   < !ELEMENT 資訊寄件者 EMPTY>
   < !ATTLIST 資訊寄件者
     名稱 CDATA #REQUIRED
     寄件者ID CDATA #REQUIRED
     角色 (銀行|證券)#REQUIRED
   >
   < !ELEMENT 資訊接收者 EMPTY>
   < !ATTLIST 資訊接收者
     名稱 CDATA #REQUIRED
     接收者ID CDATA #REQUIRED
     角色 (銀行|證券)#REQUIRED
   >
  它們都擁有三個屬性:其中名稱是指訊息發送方或者是接收方的名稱,比如:工商銀行上海市分行就是一個有效發送方或者是接收方的名稱。接收者ID是用來唯一的標識一個發送方或者是接收方,在實現的時候有兩種機制。一種是簡單的用URL作為對發送方或者是接收方的唯一標識。另外,可以對每一個發送方或者是接收方建立一個UUID,保證唯一的標識一個發送方或者接收方。角色是指訊息發送或接收者的身份,是銀行還是證券公司。


  請求資訊協議格式
  下面我們來介紹資訊的主體部分,首先我們介紹請求資訊,以下是請求資訊的定義:
  <!ELEMENT 請求資訊 %交易形式>
  <!ATTLIST 請求資訊
   請求資訊ID CDATA #REQUIRED
  >
  < !ENTITY %交易形式 "轉帳開戶+|轉帳|交易查詢+|交易管理|>"
  請求資訊主要有轉帳開戶,轉帳,交易查詢和交易管理這四大塊,這是和轉帳業務相關的主要功能。請求資訊只包括一個屬性,就是請求資訊的ID號,請求資訊ID號在伺服器A到伺服器B的所有的資料包中必須是唯一的,即每一個資料包必須要有一個唯一的ID號。在一個資料包裡面可以同時遞交幾個轉帳開戶申請,這就給實現帶來了一定的靈活性。伺服器可以迅速處理每一個使用者的申請,也可以根據具體情況批量的進行處理。同時,伺服器也可以同時遞交多個交易查詢。


  轉帳開戶交易格式
  我們首先來看轉帳開戶交易:
   <!ELEMENT 轉帳開戶 資料群組>
   <!ATTLIST 轉帳開戶
     開戶訊息ID CDATA #REQUIRED
     交易代碼 CDATA #REQUIRED
     交易提出 (股民|儲戶|銀行系統|證券系統) #REQUIRED
   >
  轉帳開戶元素有三個屬性:開戶訊息ID保證在所有一次遞交的所有的開戶申請業務中,每一個都有一個唯一的ID號。即必須保證該ID在一個包範圍內的唯一性。交易代碼是為了使機器能夠更加方便的處理該業務。交易提出指明該業務是由誰觸發的,是股民、儲戶、銀行端的伺服器系統還是證券端的伺服器系統。
  轉帳業務包含了一個資料群組,關於資料群組的內容在下面還有詳細的描述。這裡,簡單說明一下,資料群組主要是用來表示在伺服器之間進行和交易相關的業務資料的傳遞,比如資金帳號、交易金額等資料。


  轉帳交易格式
  接下來我們來看轉帳交易:
  <!ELEMENT 轉帳 (資金帳戶轉出活期帳戶轉入+|
    活期帳戶轉出資金帳戶轉入+|
    交易結果查詢+)>
  <!ELEMENT 資金帳戶轉出活期帳戶轉入 資料群組>
  <!ATTLIST 資金帳戶轉出活期帳戶轉入
    資金帳戶轉出活期帳戶轉入訊息ID CDATA #REQUIRED
    交易代碼 CDATA #REQUIRED
    交易提出 (股民|儲戶) #REQUIRED
   >


  <!ELEMENT 活期帳戶轉出資金帳戶轉入 資料群組>
  <!ATTLIST 活期帳戶轉出資金帳戶轉入
    活期帳戶轉出資金帳戶轉入訊息ID CDATA #REQUIRED
    交易代碼 CDATA #REQUIRED
    交易提出 (股民|儲戶) #REQUIRED
  >


  <!ELEMENT 交易結果查詢 (相關訊息狀態+)>
  <!ATTLIST 交易結果查詢
    交易結果查詢訊息ID CDATA #REQUIRED
    交易代碼 CDATA #REQUIRED
    交易提出 (銀行系統|證券系統) #REQUIRED
  >
  <!ELEMENT 相關訊息狀態 資料群組>
  <!ATTLIST 相關訊息狀態
    請求訊息的ID CDATA #REQUIRED
    要查詢的訊息的ID CDATA #REQUIRED
  >


  轉帳交易是業務的核心,它實際上是處理在銀行和證券之間的使用者的資金的劃撥,主要有兩種模式,資金帳戶轉出活期帳戶轉入和活期帳戶轉出資金帳戶轉入。


  我們來分析資金帳戶轉出活期帳戶轉入這種情況,當股民或者是儲戶提出轉帳請求時,考慮一般性,我們設定是股民提出轉帳請求,證券公司端的伺服器將分析股民要求轉帳的金額是否小於資金帳戶的餘額,如果成立的話,減少該資金帳戶的餘額,然後該資料包就發送到銀行的伺服器,銀行的伺服器如果能正確處理該條訊息的話,就增加相關的活期存款的餘額,並把操作成功的結果返回給證券方的伺服器。


  但是有可能證券伺服器在發出了這個交易命令後收不到應答資訊(可能是包丟失的原因)。正是因為這個原因,所以需要一個交易結果的查詢。交易結果的查詢可以同時查詢多條已經發出但沒有及時應答的那些訊息。在相關訊息狀態元素中的那個屬性:要查詢的訊息的ID就是沒有得到響應的訊息的ID號。請求訊息的ID這個屬性工作表示和該請求相關的請求包的ID號。這兩個屬性的組合唯一的決定了一條訊息。比如證券伺服器方發出了三條資金帳戶轉出活期帳戶轉入訊息,但很久沒有響應,就可以發出交易結果查詢這個指令來向銀行端伺服器查該三條訊息的執行情況。


  交易查詢格式
  在分析了轉帳交易以後,我們來分析交易查詢的實現。交易查詢的協議格式的定義如下:
  <!ELEMENT 交易查詢 (當日交易明細查詢+|
    曆史交易明細查詢+|
    活期帳戶餘額查詢+|
    資金帳戶餘額查詢+)
  >
  <!ELEMENT 當日交易明細查詢 資料群組>
  <!ATTLIST 當日交易明細查詢
    當日交易明細查詢ID CDATA #REQUIRED
    交易代碼 CDATA #REQUIRED
    交易提出 股民|儲戶) #REQUIRED
  >
  <!ELEMENT 曆史交易明細查詢 資料群組>
  <!ATTLIST 曆史交易明細查詢
    曆史交易明細查詢ID CDATA #REQUIRED
    交易代碼 CDATA #REQUIRED
    交易提出 股民|儲戶) #REQUIRED
  >
  <!ELEMENT 活期帳戶餘額查詢 資料群組>
  <!ATTLIST 活期帳戶餘額查詢
    活期帳戶餘額查詢ID CDATA #REQUIRED
    交易代碼 CDATA #REQUIRED
    交易提出 CDATA #FIXED "股民"
  >
  <!ELEMENT 資金帳戶餘額查詢 資料群組>
  <!ATTLIST 資金帳戶餘額查詢
    資金帳戶餘額查詢ID CDATA #REQUIRED
    交易代碼 CDATA #REQUIRED
    交易提出 CDATA #FIXED "儲戶"
  >


  交易查詢主要是由股民或者是儲戶發起的。主要有四種形式:查詢當日交易明細,曆史交易明細查詢,活期帳戶餘額查詢和資金帳戶餘額查詢。其中如果使用者是在證券那一端查詢的話,如果查詢當日交易明細,證券伺服器就會和銀行伺服器通訊,銀行伺服器返回當日交易明細中的所有成功交易明細。如果使用者是在銀行那一端的話,就剛好相反。這樣做的目的是保證使用者看到的肯定是已經成功的交易。同時,如果使用者在證券端查資金帳戶餘額和在銀行端查詢活期存款餘額和本協議沒有關係,因為都可以直接在本機伺服器上找到。這裡值得注意的是在一個資料包裡面(實際上是一個XML文檔)可以同時發送多個使用者的請求。
  交易管理格式
  下面看交易管理的協議格式:
  <!ELEMENT 交易管理 (銀行日終對帳|證券日終對帳|
    封閉轉帳交易功能|開放轉帳交易功能|
    修改授權碼)
  >
  <!ELEMENT 銀行日終對帳 資料群組>
  <!ATTLIST 銀行日終對帳
    銀行日終對帳ID CDATA #REQUIRED
    交易代碼 CDATA #REQUIRED
    交易提出 CDATA #FIXED "銀行系統"
    明細檔案 CDATA #REQUIRED
  >
  <!ELEMENT 證券日終對帳 資料群組>
  <!ATTLIST 證券日終對帳
    證券日終對帳ID CDATA #REQUIRED
    交易代碼 CDATA #REQUIRED
    交易提出 CDATA #FIXED "證券系統"
    明細檔案 CDATA #REQUIRED
  >
  <!ELEMENT 封閉轉帳交易功能 資料群組>
  <!ATTLIST 封閉轉帳交易功能
    封閉轉帳交易功能ID CDATA #REQUIRED
    交易代碼 CDATA #REQUIRED
    交易提出 (股民|儲戶|銀行系統|證券系統) #REQUIRED
  >
  <!ELEMENT 開放轉帳交易功能 資料群組>
  <!ATTLIST 開放轉帳交易功能
    開放轉帳交易功能ID CDATA #REQUIRED
    交易代碼 CDATA #REQUIRED
    交易提出 (股民|儲戶|銀行系統|證券系統) #REQUIRED
  >
  <!ELEMENT 修改授權碼 資料群組>
  <!ATTLIST 修改授權碼
    修改授權碼ID CDATA #REQUIRED
    交易代碼 CDATA #REQUIRED
    交易提出 (股民|儲戶) #REQUIRED
  >


  因為在包傳送過程中,有一些交易沒有得到確認,所以必須在一天的業務結束後,銀行和證券雙方進行相互對帳。這是通過銀行日終對帳和證券日終對帳兩個訊息來完成的。在日終對帳元素中包含一個屬性為明細檔案,實際上它是當日所有轉出和轉入的交易的明細所在的檔案的名稱。在具體實現的時候,系統可以根據這個屬性通過FTP來得到該檔案,以便銀行和證券雙方得到一個詳細的交易明細互相進行對帳。使用者、銀行和證券三方都可以根據自己的特殊的情況要求暫時封閉轉帳交易功能,也可以要求開放轉帳交易功能。使用者可以在系統工作時段要求更改授權碼。
  響應資訊協議格式
  證券方和銀行方都可以向對方的伺服器發出請求,然後接收請求的伺服器在處理了該請求以後,向發出請求的伺服器返迴響應訊息。
  協議對請求的響應的協議格式定義:
  <!ELEMENT 響應資訊(響應應答+)>
  <!ATTLIST 響應資訊
    響應資訊ID CDATA #REQUIRED
  >
  <!ELEMENT 響應應答 資料群組*>
  <!ATTLIST 響應應答
    應答代碼 CDATA #REQUIRED
    應答代碼描述 CDATA #REQUIRED
    請求訊息的ID CDATA #IMPLIED
    相關訊息的ID CDATA #IMPLIED
  >
  每一個響應訊息包都有一個響應訊息ID用來唯一的標識該響應資料包。一個響應訊息中可以包含多個響應應答。因為在一個請求包中可能包含多個請求,比如在一個要求轉帳開戶的資料包中可能要求同時對幾個使用者進行轉帳功能的建立。所以需要同時對這幾個請求訊息進行回覆。其中在響應應答元素中的應答代碼,我們採用三位的數字字元。比如200表示訊息成功處理。301表示活期帳號不存在等等。請求訊息的ID就是那個請求資料包的唯一的標識號,而相關訊息的ID就是指該資料包中的某一個特定的請求內容,比如請求對一筆資金帳戶轉出活期帳戶轉入的查詢。其中資料群組是指對該該請求相關的需要返回的資料項目的一個集合。
  資料群組描述
  下面我們定義了資料群組和資料項目的格式:
  <!-- 資料群組描述 -->
  <! ELEMENT 資料群組 (資料項目)+ >


  <!-- 資料項目描述 -->
  < ! ELEMENT 資料項目 EMPTY>
  < ! ATTLIST 資料項目
    資料元名稱 CDATA #REQUIRED
    類型 CDATA #REQUIRED
    長度 CDATA #REQUIRED
    是否固定長度 (是|否) #REQUIRED
    資料元內容 CDATA #REQUIRED
  >
  資料群組由資料項目組成,根據交易的特定,不同的交易請求包含不同的資料群組,而對不同的交易的響應也包括不同的資料群組。每一個資料項目都定義了該資料項目的名稱,類型,長度,是否固定長度和資料項目的實際的內容。
  一個實際的互動例子
  下面我們看一個股民開戶的實際的一個互動過程的例子:
  請求的資料包為:
  <?xml version="1.0"?>
  <!DOCTYPE 資金劃撥
    SYSTEM "http://www.somestandard.org/銀行證券資訊交換協議.dtd"
  >
  <資訊負載
    版本號碼="1.0"
    時間標籤="2000-01-01T02:02:23"
   >
  <資訊頭>
  <資訊寄件者
    名稱="Stock Corporation"
    寄件者ID="4af37b30-2c35-11d2-be4a-204c4f4f5020"
    角色="證券"
  />
  <資訊接收者
    名稱="Bank Corporation"
    接收者ID="3af37b50-2635-1172-b24a-26604f478021"
    角色="銀行"
  />
  </資訊頭>
  <請求資訊
    請求資訊ID="3434234334">
  <股民開戶
    開戶訊息ID="2342342334"
    交易代碼="1540"
    交易提出="證券系統"
  >
  <資料群組>
  <資料項目
    資料元名稱="資金帳號"
    類型="數字字元"
    長度="19"
    是否固定長度="否"
    資料元內容="000000000018"
  </>
  <資料項目
    資料元名稱="資金帳號密碼"
    類型="二進位字元"
    長度="8"
    是否固定長度="是"
    資料元內容="********"
  </>
  <資料項目
    資料元名稱="證券公司代碼"
    類型="數字字元"
    長度="6"
    是否固定長度="是"
    資料元內容="123111"
  </>
  <資料項目
    資料元名稱="活期帳號代碼"
    類型="二進位字元"
    長度="25"
    是否固定長度="否"
    資料元內容="2300232045018"
  </>
  <資料項目
    資料元名稱="活期帳號密碼"
    類型="數字字元"
    長度="8"
    是否固定長度="是"
    資料元內容="********"
  </>
  <資料項目
    資料元名稱="銀行代碼"
    類型="數字字元"
    長度="6"
    是否固定長度="是"
    資料元內容="444222"
  </>
  <資料項目
    資料元名稱="交易日期時間"
    類型="數字記號字元"
    長度="19"
    是否固定長度="否"
    資料元內容="2000-01-01T02:02:23"
  </>
  </資料群組>
  </股民開戶>
  </請求資訊>
  </資訊負載>
  實際上該文檔從證券伺服器被發送到銀行伺服器上,如果銀行伺服器成功的處理了該請求,它返回的文檔應該是如下的形式:
  <?xml version="1.0"?>
  <!DOCTYPE 資金劃撥
    SYSTEM "http://www.somestandard.org/銀行證券資訊交換協議.dtd"
  >
  <資訊負載
    版本號碼="1.0"
    時間標籤="2000-01-01T02:03:45"
  >
  <資訊頭>
  <資訊寄件者
    名稱="Bank Corporation"
    寄件者ID="3af37b50-2635-1172-b24a-26604f478021"
    角色="銀行"
  />
  <資訊接收者
    名稱="Stock Corporation"
    接收者ID="4af37b30-2c35-11d2-be4a-204c4f4f5020"
    角色="證券"
  />
  </資訊頭>
  <響應資訊
    響應資訊ID="4587874878"
  >
  <響應應答
    應答代碼="200"
    應答代碼描述 ="成功交易"
    請求訊息的ID="3434234334"
    相關訊息的ID="2342342334"
  >
  <資料群組>
  <資料項目
    資料元名稱="授權碼"
    類型="數字字元"
    長度="10"
    是否固定長度="是"
    資料元內容="0012300454"
  </>
  <資料項目
    資料元名稱="交易日期時間"
    類型="數字記號字元"
    長度="19"
    是否固定長度="否"
    資料元內容="2000-01-01T02:03:45"
  </>
  </資料群組>
  </響應應答>
  </響應資訊>
  </資訊負載>


  主要資料項目的內容
  <資料項目>
   <資料元名稱>資金帳號<資料元名稱>
   <類型>數字字元</類型>
   <長度>19</長度>
   <是否固定長度>否<是否固定長度>
  </資料項目>
  <資料項目>
   <資料元名稱>活期帳號<資料元名稱>
   <類型>數字字元</類型>
   <長度>25</長度>
   <是否固定長度>否<是否固定長度>
  </資料項目>
  <資料項目>
   <資料元名稱>授權碼<資料元名稱>
   <類型>數字字元</類型>
   <長度>10</長度>
   <是否固定長度>是<是否固定長度>
  </資料項目>
  <資料項目>
   <資料元名稱>交易金額<資料元名稱>
   <類型>數字字元</類型>
   <長度>12</長度>
   <是否固定長度>是<是否固定長度>
  </資料項目>
  <資料項目>
   <資料元名稱>銀行流水號<資料元名稱>
   <類型>數字字元</類型>
   <長度>12</長度>
   <是否固定長度>是<是否固定長度>
  </資料項目>
  <資料項目>
    <資料元名稱>證券公司流水號<資料元名稱>
    <類型>數字字元</類型>
    <長度>12</長度>
    <是否固定長度>是<是否固定長度>
  </資料項目>
  <資料項目>
    <資料元名稱>銀行代碼<資料元名稱>
    <類型>數字字元</類型>
    <長度>6</長度>
    <是否固定長度>是<是否固定長度>
  </資料項目>
  <資料項目>
   <資料元名稱>銀行名稱<資料元名稱>
   <類型>數字字母符號字元</類型>
   <長度>50</長度>
   <是否固定長度>否<是否固定長度>
  </資料項目>
  <資料項目>
    <資料元名稱>證券公司代碼<資料元名稱>
    <類型>數字字元</類型>
    <長度>6</長度>
    <是否固定長度>是<是否固定長度>
  </資料項目>
  <資料項目>
    <資料元名稱>證券公司名稱<資料元名稱>
    <類型>字母數字字元</類型>
    <長度>50</長度>
    <是否固定長度>否<是否固定長度>
  </資料項目>
  <資料項目>
    <資料元名稱>資金帳號密碼<資料元名稱>
    <類型>二進位字元</類型>
    <長度>8</長度>
    <是否固定長度>是<是否固定長度>
  </資料項目>
  <資料項目>
    <資料元名稱>活期帳號密碼<資料元名稱>
    <類型>二進位字元</類型>
    <長度>8</長度>
    <是否固定長度>是<是否固定長度>
  </資料項目>
  <資料項目>
    <資料元名稱>活期帳號餘額<資料元名稱>
    <類型>數字字元</類型>
    <長度>12</長度>
    <是否固定長度>是<是否固定長度>
  </資料項目>
  <資料項目>
    <資料元名稱>資金帳號餘額<資料元名稱>
    <類型>數字字元</類型>
    <長度>12</長度>
    <是否固定長度>是<是否固定長度>
  </資料項目>
  <資料項目>
    <資料元名稱>交易日期時間<資料元名稱>
    <類型>數字記號字元</類型>
    <長度>19</長度>
    <是否固定長度>是<是否固定長度>
  </資料項目>
  <資料項目>
    <資料元名稱>使用者姓名<資料元名稱>
    <類型>數字字母字元</類型>
    <長度>12</長度>
    <是否固定長度>是<是否固定長度>
  </資料項目>
  <資料項目>
    <資料元名稱>使用者身份證<資料元名稱>
    <類型>數字</類型>
    <長度>18</長度>
    <是否固定長度>否<是否固定長度>
  </資料項目>
  <資料項目>
    <資料元名稱>使用者地址<資料元名稱>
    <類型>數字字母符號字元</類型>
    <長度>80</長度>
    <是否固定長度>否<是否固定長度>
  </資料項目>
  <資料項目>
    <資料元名稱>使用者電話<資料元名稱>
    <類型>數字記號字元</類型>
    <長度>14</長度>
    <是否固定長度>否<是否固定長度>
  </資料項目>
  <資料項目>
    <資料元名稱>城市編號<資料元名稱>
    <類型>數字字元</類型>
    <長度>5</長度>
    <是否固定長度>否<是否固定長度>
  </資料項目>



相關文章

Alibaba Cloud 10 Year Anniversary

With You, We are Shaping a Digital World, 2009-2019

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。