【正文】 x文件，該文件的后綴 名為“ *． udx”。 ContentLocation，主要對附件的存放位置進行描述。 ContentDisposition， 主要對文件在消息當中所扮演的角色進行描述。 ContentTransferEncoding，主要描述文件傳輸中的編碼方式。在上述消息類信息 的交換過程當中，多媒體文件通過 Base64編碼方式存放在 XML的《 c∞ ten》元素中，同時在 Content元 素中利用其他的 XML數(shù)據(jù)信息對多媒體文件進行描述，這些描述信息包括： ContentType，主要描述附件的類型，可以用 MIME類型進行描述。 Base64采用了一種很簡單的編碼轉(zhuǎn)換：對于待編碼數(shù)據(jù)，以 3個字節(jié) 為單位，依次取 6位數(shù)據(jù)并在前面補 上 2個 0形成新的 8位編碼，由于 3 84 6，這樣 3個字節(jié)的輸入會變 成 4個字節(jié)的輸出，長度上增加了 1／ 3。 Base64是一種很常見的編碼規(guī) 范，其作用是將二進制序列轉(zhuǎn)換為人類可讀的 ASCH字符序列，常用在需通過文本協(xié)議 (比如 m。對于文件傳輸過程中的文件的封裝不在本部分考慮范圍之內(nèi)。其形式如下： YD廠 r 1 760． 22020 6． 4多媒體文件的封裝 移動終端中保存的多媒體文件包括：消息類數(shù)據(jù)當中的多媒體文件附件，以及移動終端 所存儲的多 媒體文件。每個 Emaillnfo元素 18 YD廠 r 1760． 22020 中包含一個 Email數(shù)據(jù)的序號以及一個以 XML形式進行封裝的 Email數(shù)據(jù)，移動終端可以根據(jù) Emai擻據(jù) 所對應(yīng)的序號，選擇整個文件中的一部分數(shù)據(jù)進行交換。在電子郵件數(shù)據(jù)進行 XML 的封裝過程中，需要遵守如下的 DTD： 在上述 _DTD中，主要是對 Email數(shù)據(jù)如何在數(shù)據(jù)交換文件格式中體現(xiàn)進行規(guī)定。其形式如下： 17 6． 3． 6電子郵件 移動終端應(yīng)支持電子郵件的數(shù)據(jù)交換能力，具體的電子郵件數(shù)據(jù)字段的含義應(yīng)符合 YD． ,T 1760． I一 2020《數(shù)字移動終端外圍接口數(shù)據(jù)交換第 l部分：數(shù)據(jù)格式技術(shù)要求》，本部分僅按照 W3C的 規(guī)則對 yD． rr 1760． 12020《數(shù)字移動終端外圍接口數(shù)據(jù)交換第 1部分：數(shù)據(jù)格式技術(shù)要求》所要求的電 子郵件字段進行 XML形式的封裝定義。每個 MMSInfo元素 16 包含一個 MMS數(shù)據(jù)的序號以及一個以 XML形式進行封裝的 Email數(shù)據(jù)，移動終端可以根據(jù) MMS數(shù)據(jù)所 對應(yīng)的序號，選擇整個文件當中的一部分數(shù)據(jù)進行交換。在多媒體消息數(shù)據(jù) 在上述 DTD中，主要 是對 MMS數(shù)據(jù)如何在數(shù)據(jù)交換文件格式中體現(xiàn)進行規(guī)定。本部分僅按照 W3C的 規(guī)則對 YD／ T 1760． 12020《數(shù)字移動終端外圍接口數(shù)據(jù)交換第 1部分：數(shù)據(jù)格式技術(shù)要求》所要求的 MMS字段進行 XML形式的封裝定義。 移動終端可以根據(jù)上述的 DTD的描述生成和解析 udx文件，移動終端也可以支持 Schema的方式進行 udx文件的生成和解析。所有的 SMS數(shù)據(jù)都是 XML中 SMS元素的子元素，每個 SMS元素可以包含 O個或者多個 SMSInfo元素。在短消息數(shù)據(jù)進行 XML的封裝過 程中，需要遵守如下的 DTD： 14 YD廠 r 1 7I∞． 2砌 8 在上述 DTD中。本部分僅按照 W3C的規(guī)則對 YD／ T 1760． 1— 2020《數(shù)字移動終端外圍接口數(shù)據(jù)交換第 1部分：數(shù)據(jù)格式技術(shù)要求》所要求的 SMS字段進行 Ⅺ訂 L形式的封裝定義。其形式如下。 每個 vCalendarInfo元素中包含一個 vCalendar數(shù)據(jù)的序號以及一個以 XML形式進行封裝的 vCa]endm數(shù) 據(jù)，移動終端可以根據(jù) vCalendar數(shù)據(jù)所對應(yīng)的序號，選擇整個文件當中的一部分數(shù)據(jù)進行交換。在日程表數(shù)據(jù)進行Ⅺ血的封裝過程 在上述 DTD中，主要是對 vCalendar數(shù)據(jù)如何在數(shù)據(jù)交換文件格式中體現(xiàn)進行規(guī)定。本部 分僅按照 W3C的規(guī)則對 YD／ T 1760． 1— 2020《數(shù)字移動終端外圍接口數(shù)據(jù)交換第 l部分：數(shù)據(jù)格式技術(shù)要 求》所要求的 vCalendar字段進行 XML形式的封裝定義。ing“ minOecul39?！?unbounded”扛 xs： clement nⅢ e=“ EMAIU’ type=” xs： s砸 ng” mmoccLlrs= 0 maxOccurs=unboundcd”， xs： elgment n齜 ne=“ EMAILHOME” type=“ xs： string” minOecurs=” 0。iamem“ BDAY” type=39。其形式如下： 12 xs： clemt naⅡ l” URLHOME”咿” xs： string“ minOccurs= 0 mⅨ Occurs=” unbounded”， xs： element naIne=” URLWORK” type=“ xs： string” minOcctas=0” maxOccurs=” unbounded“ b xs： elcmentllllme=” ORGNAME” type=“ xs： string“ mJnOccur9= 0 maxOccurSm” unbounded“， xs； clementname=” ORGUNIT“帥 e；“ xs： string” minOccm39。每個 vCardInfo元素 中包含一個 vCard數(shù)據(jù)的序號以及一個以 XML形式進行封裝的 vCard數(shù)據(jù)，移動終端可以根據(jù) vCard數(shù)據(jù) 所對應(yīng)的序號，選擇整個文件當中的一部分數(shù)據(jù)進行交換。 9 10 在上述 DTD中，主要是對 vCard數(shù)據(jù)如何在數(shù)據(jù)交換文件格式中體現(xiàn)進行規(guī)定。 移動終端在對電話簿進行數(shù)據(jù)交換的過程當中，應(yīng)支持將移動終端的電話簿數(shù)據(jù)按照 XML形式進 行封裝，所生成的 udx文件用于對所需交換的電話簿數(shù)據(jù)進行交換。其形式如 下： 7 8 6． 3． 2電話簿 移動終端所支持的電話簿數(shù)據(jù)格式應(yīng)符合 vCard v2． 1規(guī)范的要求，具體的 vCard數(shù)據(jù)字段的含義應(yīng)符 合 YD／ T 1760． t2020《數(shù)字移動終端外圍接口數(shù)據(jù)交換第 l部分：數(shù)據(jù)格式技術(shù)要求》。DATA) 吧 LEMENT MidSRecord(PCDATA) !ELEMENT MMSLarlgth(PCDATA) !EL既也 NTEmailVersion(PcDATA》 (!EU王 hfENT EmailRecord(PCDATAl !ELEMENTEmaill2n鮮 h(PCDATAl 在上述 DTI)中： ELEMENT DataExchangeInfo標識整個數(shù)據(jù)交換文件的頭信息 { Userlnfo標識生成數(shù)據(jù)交換文件的用戶信息； UserAgent標識生成數(shù)據(jù)交換文件的客戶端信息； Devicelnfo標識生成數(shù)據(jù)交換文件的設(shè)備信息： Date標識生成數(shù)據(jù)交換文件的日期信息； Language標識生成數(shù)據(jù)交換文件的語言信 息； Recordlnfo標識數(shù)據(jù)文件中所包含的數(shù)據(jù)內(nèi)容的總體信息； RecordOfvCard標識所交換的 vCard數(shù)據(jù)的條數(shù)： RecordOfvCalendar標識所交換的vCalendar數(shù)據(jù)的條數(shù)； RecordOfSMS標識所交換的 sMS數(shù)據(jù)的條數(shù)； RecordOfMMS標識所交換的 MMS數(shù)據(jù)的條數(shù)； RecordOfEmail標識所交換的 Email數(shù)據(jù)的條數(shù)。dLength(PCDATA) (疆： Lamp。DATA) lELEMENTUserAgent(PCDATA) (!ELEMENT Uscrlnfo(PCDATA》 !ELEMENT Encoding(PCDATA) !ELEMENT FilcSize(PCDATA) 【 ELEMENT Date rPCDATA) !ELEMENT Language(PC39。終端在完成數(shù)據(jù)交換之后，應(yīng)根據(jù)頭信息對交換 結(jié)果進行檢查。 在 udx文件進行解析前， DXA應(yīng)根據(jù)頭信息對數(shù)據(jù)的完整性和可靠性進行檢查。 上述信息主要用于區(qū)分不同的數(shù)據(jù)來源， udx文件需要通過 udx的文件信息來完成對整個 udx文件的 完整性檢 查信息，其需要的信息包括： 1．文件的編碼方式，主要用于規(guī)定 udx文件當中的編碼數(shù)據(jù)，默認采用 uff8方式； 2．文件的大小信息，主要用于對整個 udx文件數(shù)據(jù)進行長度校驗； 3．日期信息，主要用于對生成 udx文件時間進行參考； 4．語言信息，主要用于描述 udx文件當中所采用的語言類型，默認為中文。 其中： 終端信息包括如下的內(nèi)容： 1．終端廠商，主要用來區(qū)分不同終端的制造廠商，默認為 VendorUDX； 2．終端型號，主要用來區(qū)分參與數(shù)據(jù)交換 的不同的終端型號，默認為 DeviceUDx； 3． udx版本信息，主要用來區(qū)分當前的 udx版本和未來對 udx版本的擴展和升級，默認為 1． 0； 4．終端軟件版本信息，主要用來區(qū)分數(shù)據(jù)交換過程當中的軟件的版本信息，默認為 AgentUDX。 6．