【正文】 0表示不支持． 1表示支持 MoveSupported 是否支持將文件和目錄移動到其他目錄。缺損為一 1。缺損為一 1。 PropNme為屬性 名稱， PropValue為屬性值，參加下表定義。 文件系統(tǒng) 無 擴展定義見 B． 8． 1 C． 8． 1 文件系統(tǒng)能力信息 為取得移動終端文件系統(tǒng)能力信息，計算機可以在 OBEXFBS連接建立后，發(fā)送 GET： Pd令到移動終 端，并給出 TYI)E header， TYPE headerl玟值為 AScⅡ字符串“ xobex／ fbs／ eapability”。rx寸應電話簿 DB的 InformkaJ． 10n Logs 來了解?？梢酝ㄟ^各協(xié)議的相關指令來獲取，列 表如下 業(yè)務 指令及說明 遵循規(guī)范 通過“ +ClaMS” A討旨令，可以了解移動終端在同步方面對短消息的支持情況。例如，想將 1jpg從當前目錄移動至 1]／ UserData／ Image。表示的操作含義是將當前目錄 下的 1jpg移動至 iJ／ UserData／ Image目錄下，并更名為 MyDaughter． jpg。 4．如果 OldName和 NewName所表示的文件或目錄不在同一個目錄下，則表示其實際要求的是“移 動”操作，即將老文件或目錄“移動”到新的目錄，且名稱也可能修改。 2．第一個 NAMEheader表示老文件名或目錄名 (簡稱為“ OldName” )，第二個 NAMEheader表示 新文件名或目錄名 (簡稱為“ NewName” )。 4． SIM／ UIM卡中存儲日程表的情況本附錄暫不做要求。 2．移動終端應支持 InformationLogs的 X． IRMC— FIELDS，用于描述日程表的字段定義，即描述日 程表記錄中支持哪 些字段，每個字段的最大長度限制。 c)3個文本字段位置，對于每個位置，用戶可以任意在“電子郵件、地址、備注”中選擇類型。 x． mMCFIELDS擴展定義如下： 1． x．口陸垂 c． FIELDs中每一行代表～個“字段”位置的概念，～行就代表一個電話簿記錄中的一個 字段存儲位置。對于每個字段的最大長度，本附錄約定其含義為字 符數(shù)。除標示不同外，訪問 S喇口 M卡電話簿與訪 問移動終端存儲器電話簿完全相同。前者對應于移動終端用 LUll)來標示電話簿記錄， 并支持 Changelog的情況，后者對應于移動終端采用 Index來標記電話簿記錄且不支持 Changelog的情況。 YD廠 r 1 760． 22020 2．操作 EMS長短信時，需要基于拆分后的短信來交互。 3．如果計算機端能夠檢測物理連接斷開事件 (如數(shù)據(jù)線拔掉、藍牙／紅外連接中斷 )，應立即退出 OBEX模式，返回 AT模式；否則計算機端應使用超時機制，當一段時間內(nèi)沒有收到移動終端的 OBEX響 應時 (建議為 90s)，退出 oBEx模式，返回 AT模式。對于手機端的異常退出， 計算機端軟件也應盡快退出 OBEX模式。： PCS，含有 lrDA： TinyTP： LsapSel屬性”的 hTrP通道．或 m咖口 C． 2模式切換 對于每一條傳輸通道，移動終端軟件可工作于 A碳式和 OBEX模式 (不應同時工作于此兩種模式 )。 3．數(shù)據(jù)同步業(yè)務可以與移動終端 modem共用 modem傳輸通道。 C． 1傳輸通道 移動終端與計算機的數(shù)據(jù)同步，可以基于數(shù)據(jù)線、藍牙、紅外通信 方式中的一種或多種承載。 B． 5標識要求 udx標志可以選擇以模塑、噴涂、粘貼、印刷的方法直接標識在產(chǎn)品上，也可以選擇在產(chǎn)品說明書 中或包裝上予以注明。 B． 4規(guī)格 B． 4． 1圖形規(guī)格 圖 B． 圖 B． 4橢圓高度與寬度之比為 3： 5，其中字母字體為 Arial圖 B． 3字母主體高度與橢圓高度之 比為 2： 5；圖 B． 4字母主體高度與橢圓高度之比為 1： 3。 B． 2圖例 圖 B． 1和圖 B． 2為 udx標志圖樣和 udx． C標志圖樣示例。 A． 2 DXAC應用場景 終端類型： B型終端； 數(shù)據(jù)交換代理類型： DXA． C； 外圍接口類型：數(shù)據(jù)線、藍牙、紅外等接口； 場景描述： B型終端使用數(shù)據(jù)線、藍牙、紅外等接口進行數(shù)據(jù)交換。 DXA． C應符合本部分 5． 1． 1節(jié)關于 DXA的基本要求。 生成 udx文件時，應根據(jù)需要生成移動終端支持的數(shù)據(jù)類型和字段，保證符合 udx文件格式并包含完 整的數(shù)據(jù)內(nèi)容。接收到 s。 filename，主要對附件的文件名進行描述。 charset主要描述文件的字符集。 rP和 SMTP)傳輸二進制數(shù)據(jù)的情況下。本部分主要考慮將消息類數(shù)據(jù)作為附件的多媒體文件的封裝，對于有 DRM保護的多媒體內(nèi) 容可以不進行數(shù)據(jù)交換。所有的 Email數(shù)據(jù)都 是 XML中 Email元素的子元素，每個 Email元素可以包含 0個或者多個 Emaillnfo元素。 移動終端可以根據(jù)上述 DTD的描述生成和解析 udx文件，移動終端也可以支持 Schema方式進行 udx 文件的生成和解析。 移動終端在對多媒體消息進行數(shù)據(jù)交換的過程中，應支持將移動終端的多媒體消息數(shù)據(jù)按照 XML 的形式進行封裝，所生成的 XML文件用于對所需交換的多媒體消息數(shù)據(jù)進行交換。每個 SMSlnfo元素當中包 含一個 SMS數(shù)據(jù)的序號以及一個以 XML形式進行封裝的 SMS數(shù)據(jù)，移動終端可以根據(jù) SMS數(shù)據(jù)所對應 的序號，選擇整個文件當中的一部分數(shù)據(jù)進行交換。 移動終端在對短消息進行數(shù)據(jù)交換的過程中，應支持將移動終端的短消息數(shù)據(jù)按照 XML的形式進 行封裝，所生成的 XML文件用于對所需交換的短消息數(shù)據(jù)進行交換。 移動終端可以根據(jù)上述 DTD的描述生成和 解析 udx文件，移動終端也可以支持 Schema的方式進行 udx文件的生成和解析。 移動終端在對日程表進行數(shù)據(jù)交換的過程中，應支持將移動終端的日程表數(shù)據(jù)按照Ⅺ札的形式進 行封裝，所生成的 udx文件用于對所需交換的日程表數(shù)據(jù)進行交換。 maxOceurs=” unbounded’協(xié) xs： elementBKIIIe： =” EMAILWORK“ type=“ xs： sU39。s=” omaxOccurs=“ unbounded’協(xié) xs： elementnlLrnc=” TITLE” type=” xs： stdng” minOccurs= 0加“ occurs=” unbounded／ xs： dcmtl39。所有的 vCard數(shù)據(jù)都 是 XML中 vCard元素的子元素，每個 vCard元素可以包含 O個或者多個 vCardInfo元素。本部分僅按照 W3C的規(guī) 則對 YD／ T 1760． I一 2020《數(shù)字移動終端外圍接口數(shù)據(jù)交換第 1部分：數(shù)據(jù)格式技術要求》所要 求的 vCard字段進行 XML形式的封裝定義。dENT vcmendArversion(PCDATAb (!EU洲 ENT vCalendarRecord【眷 PCDATA) !EI正 MENT vCalendatLength(PCDATA》 !EI正 h仍 NT SMSVerslon餅 PCDATA) !EU!h皿 NT SM,SReeord(昔 PCDATA》 !ELEMENT SMSLetlgIh(PCDATA) (!ELEMENTMMSVersion(PC39。 頭信息在交換過程中利用 XML進行封裝，需要遵守如下 DTD： ?xrnl vel_sion=” 1． 0“ encoding=” UTF8” ? !ELEMENT DataExchangelnfo(Recordlnfo， vCard?,vCaldar7． SMS?， MMS?， Email?) [ELEMENTRecordlnfo(Vendorlnfo， Devicelnfo， UdxVersion， UserAgent,Userlnfo?， Encoding?,FileSize7． Date?,Languago? Re,eordOfvCard． RecordOfvCalendar， RecordOfSMS， RocordOfMMS， RecordOtEmail) !ELEMENT Vdorlnfo(PCDATA) [ELEMENT Devicelnfo(PCDATA) 6 !ELEMENT UdxVefsion(PC39。 此外，為了對 udx文件所攜帶的數(shù)據(jù)條目信息進行描述， udx文件的頭信息當中還應該包括如下內(nèi)容： 1． udx文件包含 vCard數(shù)據(jù)的條目信息，版本信息，文件長度，主要用于對 udx數(shù)據(jù)中 vCard條目進行版 本匹 配、數(shù)量檢測和文件長度的校驗： 2． udx文件包含 vCalenda數(shù)據(jù)的條目信息，版本信息／文件長度，主要用于對 udx數(shù)據(jù)當中的 vCalendar 條目進行版本匹配、數(shù)量檢測和文件長度的校驗； 3． udx文件包含 SMS數(shù)據(jù)的條目信息，版本信腳文件長度，主要用于對 udx數(shù)據(jù)中 SMS條目進行版本 匹配、數(shù)量檢測和文件長度的校驗： 4． udx文件包含 MMS數(shù)據(jù)的條目信息，版本信息，文件長度，主要用于對 udx數(shù)據(jù)中 MMS條目進行版 本匹配、數(shù)量檢測和文件長度的校驗： 5． udx文件包含電子郵件數(shù)據(jù)的條目信息／版本 信息度件長度，主要用于對 udx數(shù)據(jù)中 Email條目進 行版本匹配、數(shù)量檢測和文件長度的校驗。 5 YD廠 r 1 760． 22020 udx文件頭信息包括終端信息、用戶信息、 udx文件包含數(shù)據(jù)的統(tǒng)計信息和 udx文件完整性檢查信息。 需要進行交抉的數(shù)據(jù)在 udx文件中應 按下囤中的邏輯結構組織，其中頭信息不可缺少，用戶數(shù)據(jù)信息模 塊可根據(jù)實際數(shù)據(jù)交換的需求保留或刪減，每個數(shù)據(jù)信息模塊內(nèi)的具體字段也可以根據(jù)需求保留或刪減。 XlVlL的 Schema方式在本部分當中作為可選內(nèi)容要求。 6通用數(shù)據(jù)交換文件格式 6． 1通用數(shù)據(jù)交換文件 (udx文件 ) 本部分定義了一種標準的數(shù)據(jù)交換文件格式，命名為“通用數(shù)據(jù)交換文件” (UniversalDataeXchange file，簡稱為“ udx”文件 )，該類文件的應用后綴名為～． udx”。 A型終端 圖 3數(shù)據(jù)交換應用場景 2 當數(shù)據(jù)交換過程符合場景 2的條件時，應滿足如下要求： A型終端應能夠通過 DXAM生成和解析 udx文件，并通過 USB數(shù)據(jù)接口與計算機傳送 udx文件，數(shù)據(jù) 傳輸協(xié)議應完全兼容 usB Mass Storage Class Specification標準使 A型終端能夠工作在移動存儲模式，或 通過安裝通用軟件 (由第三方提供 )而使 A型終端能夠被計算機識別，并能夠通過上述方式將 udx文件 直接傳送到計算機。 YD廠 r 1 760． 22020 5_2數(shù)據(jù)交換應用場景 5． 2． 1場景 1 終端類型： A型終端； 數(shù)據(jù)交換代理類型： DXA． M； 外圍接口類型：藍牙、紅外等接口： 場景 1描述： A型終端使用藍牙、紅外 等接口進行數(shù)據(jù)交換。 DXA在生成和解析 udx文件時應保證數(shù)據(jù)的完整性。 圖 1數(shù)據(jù)交換示意圖 通用數(shù)據(jù)交換文件中所包含的發(fā)起方數(shù)據(jù)被交換到接收方移動終端的過程中，如果數(shù)據(jù)解析時發(fā)現(xiàn) 有超出接收方移動終端能力的數(shù)據(jù)，不得簡單丟棄，應明示用戶后進行處理，或者直接根據(jù)用戶選擇的 方式進行處理。 4． 3數(shù)據(jù)交換過程 4． 3． 1數(shù) 據(jù)交換過程描述 數(shù)據(jù)交換過程是指將移動終端內(nèi)部數(shù)據(jù)格式轉換成符合本部分規(guī)定的文件格式，或者是在計算機上 創(chuàng)建、編輯一個符合本部分規(guī)定的文件，將該文件最終交換到移動終端上，并轉換成移動終端內(nèi)部數(shù)據(jù) 格式的過程。 3‘ 2縮略語 下列縮略語適用于本部分。 3． 1． 6 B型終端 Terminal Class B B型終端是指具有通過本地外圍接 IZl進行數(shù)據(jù)交換能力，但是不支持在終端上實現(xiàn) udx文件的生成 和解析的移動終端。 3． 1． 2數(shù)據(jù)交換接收方 Data eXchange Receiver 數(shù)據(jù)交換接收方是指接收交換數(shù)據(jù)的移動終端及其數(shù)據(jù)交換代理。然而，鼓勵根據(jù)本部分達成協(xié)議的各方研究 是否可使用這些文