Như đã nói ở trên, BlackBerry Desktop Manager là một chương trình dùng để kết nối thiết bị với máy tính. Ngoài ra chương trình này còn cung cấp cho người dùng các tiện ích như: Triển khai chương trình trên thiết bị, tạo tập tin với đuôi mở rộng của Research In Motion là .alx để triển khai.
Tập tin có đuôi mở rộng .alx là một tập tin định nghĩa dựa trên ngôn ngữ XML, nó cung cấp các thông tin về ứng dụng, để tạo tập tin này. Chọn menu Project, chọn
Generate ALX File. Nếu chương trình có tên là FirstApp, thì file alx sẽ có dạng:
120 <application id="FirstApp"> <name > </name> <description > </description> <version > </version> <vendor > MyCompany </vendor> <copyright > Copyright (c) 2010 MyCompany </copyright> <fileset Java="1.5"> <directory > MyCompany </directory> <files > FirstApp.cod </files> </fileset> </application> </loader>
Bảng A.2 - cấu trúc một tập tin .alx
Để triển khai chương trình bằng công cụ Blackberry Desktop Manager: Khởi động chương trình Blackberry Desktop Manager, chọn Application Loader, chọn tập tin .alx đã tạo ở trên và cài đặt vào thiết bị.
121
Phụ lục B: Tống hợp các giao thức mail B.1 Cấu trúc MIME
Có 2 loại cấu trúc MIME: cấu trúc đơn giản (discrete media) và cấu trúc phức tạp (composite media).
o Cấu trúc đơn giản: text, video, audio, image, application.
o Cấu trúc phức tạp: multipart, message.
Các thành phần cơ bản của MIME (được miêu tả trong RFC-2045):
1. MIME-Version:
Mỗi message yêu cầu có 1 trường MIME-Version trong header. Thông tin này nhằm cho biết message được chuyển mã sang dạng MIME và cho biết phiên bản MIME được sử dụng.
Cú pháp: MIME-Version: 1*DIGIT“.”1*DIGIT (1.0)
2. Content-Type:
Dùng để cho biết cách nội dung phần thân được biểu diễn, nhờ đó tác nhân nhận gói tin biết cách để hiểu thị nội dung với người dùng.
Trường này gồm 2 thông tin kiểu (type) và kiểu con (subtype) đi kèm nhau theo cấu trúc type/subtype và có thể kèm thêm các tham số khác như charset, name, ... Tên type, subtype, parameter không phân biệt hoa thường. Tuy nhiên giá trị các parameter thường phân biệt hoa thường.
Một số content type chính : application, multipart, text, message, audio, video, image và extension-token. Chú ý thông tin subtype là bắt buộc vì không có subtype mặc định cho các type trên.
Một số subtype ứng với các type:
1. text: plain (primary), richtext.
2. multipart: mixed (primary), alternative, parallel, digest, related, signed. 3. message: rfc822 (primary), partial, External-body.
4. image: jpeg, gif 5. audio: basic. 6. video: mpeg
7. application: octet-stream, PostScript.
Khi tác nhân đọc mail không nhận ra được giá trị của Content-Type, thường nên xem như là một application/octet-stream.
Cấu trúc:
122
Text: là Content-Type mặc định, dùng để gửi dữ liệu đang text. Content-Type mặc định cho Internet mail là “text/plain; charset=us-ascii”. Tham số “charset” có thể được dùng để chỉ tập kí tự được dùng. Giá trị của tham số này không phân biệt hoa thường như các tham số khác. Các giá trị bao gồm: “us-ascii” / “iso-8859-1” / “iso-8859-2” /“iso-8859-3” /“iso-8859-4” /“iso-8859-5” /“iso- 8859-6” /“iso-8859-7” /“iso-8859-8” /“iso-8859-9” / extension-token.
Application: dùng để gửi những dữ liệu cần được xử lí bằng một ứng dụng trên máy tính, thường là các chương trình. Hai loại thường được sử dụng là
“application/octet-stream” và “application/PostScript”.
o application/octet-stream: là subtype chính dùng trong “application” Content-Type cho biết thân của message chứa dữ liệu nhị phân. Các tham số thường dùng : type, padding và name.
o application/PostScript: cho biết nội dung dữ liệu là một chương trình PostScript (Một ngôn ngữ lập trình để chỉ ra cách bố trí (layout) của một trang được in).
Image: cho biết nội dung của phần này là một hình ảnh. Giá trị subtype cho biết định dạng của file ảnh được sử dụng. Một số subtype hỗ trợ: g3fax / gif / ief / jpeg / tiff. Nhưng 2 loại thường phổ biến là jpeg và gif.
Cấu trúc header:
image-type := “image” “/” (“gif” / “jpeg” / extension-token)
Audio: cho biết nội dung của phần này là một file âm thanh. Subtype được sử dụng là “basic”
Cấu trúc header:
audio-type := “audio” “/” (“basic” / extension-token) Video: nội dung của phần này là một file phim ảnh. Cấu trúc header:
video-type := “video” “/” (“mpeg” / extension-token)
Multipart: phần thân bao gồm 1 hay nhiều phần dữ liệu khác nhau (body part) kết hợp với nhau. Phần định nghĩa “multipart” Content-Type phải xuất hiện trên header, phần thân gồm 1 hay nhiều phần. Mỗi phần phân biệt cách nhau bằng đường biên (boundary). Boundary không được xuất hiện trong phần thân của body part, do đó phải có cách phát sinh ra boundary duy nhất. Mỗi phần gồm phần header của chính nó, một dòng trống và theo sau là phần thân. Chỉ những header bắt đầu bằng Content- mới có ý nghĩa trong phần header của body part.
o boundary không được dài quá 70 kí tự (không bao gồm 2 dấu ‘-‘ dầu dòng. Với boundary theo sau part cuối cùng sẽ được gắn thêm 2 dấu ‘-‘ vào cuối.
o Tham số boundary bắt buộc phải có trong “multipart” Content-Type.
....
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="exampledelimtext123"
123 --exampledelimtext123
Content-Type: text/plain
Jane, here is the photo you wanted me for the new client. Here are some notes on how it was processed.
(Blah blah blah…) Talk to you soon,Joe. --exampledelimtext123
Content-Type: image/jpeg; name="clientphoto.jpg" Content-Transfer-Encoding: base64 SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs … zv/wAARCADIARoDASIAAhEBAxEB/8QAHAAAAQUBA --exampledelimtext123-- Bảng B.1 – Ví dụ về tập tin MIME
Cấu trúc của boundary được định nghĩa như sau:
boundary := 0*69<bchars> bcharsnospace bchars := bcharsnospace / " "
bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /"_" / "," / "-" / "." / "/" / ":" / "=" / "?"
Multipart/mixed: được dùng khi các body part độc lập với nhau và cần được giữ theo một trật tự. Bất kì subtype của multipart không thể nhận biết phải được xem như “mixed”.
Multipart/alternative: mỗi body part được xem như là một bản thay thế biểu diễn cùng một nội dung thông tin. Hệ thống sẽ chọn ra cách tốt nhất để hiển thị nội dung. Thứ tự của các part trong “multipart/alternative” mang ý nghĩa rằng tính chính xác của dữ liệu gốc tăng dần. Và thường hệ thống sẽ chọn ra phần sau nhất được hỗ trợ để hiển thị nội dung. Mỗi phần nên có một Content-ID, giá trị này giống nhau khi nội dung các phần giống hệt nhau và nên khác nhau khi nội dung của các phần không giống nhau hoàn toàn. Các Content-ID này khác với Content-ID của toàn bộ entity “multipart/alternative”.
Multipart/digest: được dùng để gửi tập các message dạng văn bản. Nhưng giá trị mặc định của Content-Type trong mỗi phần là “message/rfc822”.
Multipart/parallel: dùng để hiển thị tất cả các phần đồng thời trên cả phần cứng và phần mềm mà nó hỗ trợ. Ví dụ, hiển thị một hình ảnh trong khi đang chơi một bản nhạc.
124
Hình B.1 - Cấu trúc của một message kiểu multipart (Nguồn: The TCP/IP Guide - www.tcpipguide.com)
Message: cho phép message có thể chứa các messages khác hoặc chứa các con trỏ trỏ tới các message khác.
message/rfc822: Phần thân của message chứa một message khác theo cấu trúc của RFC822 message. Tuy nhiên phần thân của
“message/rfc822” không yêu cầu các trường “From”, “Subject”, “To”. Một message “message/rfc822” cũng có thể là một MIME message. message/partial: được định nghĩa nhằm cho phép gửi các đối tượng dữ liệu có kích thước lớn qua nhiều đoạn message khác nhau, sau đó tự động hợp lại với nhau thành một message hoàn chỉnh. Chỉ có 7bit
Content-Transfer-Encoding được dùng trong trường hợp này. Có 3 tham số bắt buộc phải có khi dùng “message/partial” Content-Type là id, number và total. Id là một giá trị duy nhất để kết hợp các phần lại với nhau. Nếu như id cho biết các phần thuộc về cùng một message thì number cho biết thứ tự của các phần và có giá trị là một số tự nhiên. Tham số cuối cùng là total, một số tự nhiên cho biết tổng số phần được tách ra của message. Tham số này buộc phải có trong phần cuối cùng nhưng nên dùng trong tất cả các phần. Chú ý giá trị của tham số number
125
bắt đầu từ 1. Khi phát sinh và hợp các phần của một message, các header của message được gói gọn phải được kết hợp với các header của message bao quanh bên ngoài theo các quy tắc sau:
(1) Tất cả các trường trong header của part 1 (enclosing entity), ngoại trừ các trường bắt đầu bằng “Content-“ và các trường “Message-ID”, “Encrypted” và “MIME-Version” phải được sao chép theo thứ tự sang message mới.
(2) Chỉ những trường trong header của (enclosed message) bắt đầu bằng “Content-” và các trường “Message-ID”, “Encrypted”, “MIME-
Version” phải được thêm theo thứ tự vào header của message mới. (3) Tất cả các trường trong header của các message tiếp theo bắt đầu từ message thứ 2 sẽ bị bỏ qua.
Ví dụ: Một message được tách thành 2 phần, phần thứ nhất có nội dung: X-Weird-Header-1: Foo
From: Bill@host.com To: joe@otherhost.com Subject: Audio mail
Message-ID: <id1@host.com> MIME-Version: 1.0 Content-type: message/partial; id="ABC@host.com"; number=1; total=2 X-Weird-Header-1: Bar X-Weird-Header-2: Hello Message-ID: <anotherid@foo.com> MIME-Version: 1.0 Content-type: audio/basic Content-transfer-encoding: base64
... first half of encoded audio data goes here...
Phần thứ 2 có nội dung:
Enclosing entity
126 From: Bill@host.com
To: joe@otherhost.com Subject: Audio mail MIME-Version: 1.0
Message-ID: <id2@host.com> Content-type: message/partial;
id="ABC@host.com"; number=2; total=2 ... second half of encoded audio data goes here...
Theo các quy tắc trên thì message được hợp nhất có nội dung: X-Weird-Header-1: Foo
From: Bill@host.com To: joe@otherhost.com Subject: Audio mail
Message-ID: <anotherid@foo.com> MIME-Version: 1.0
Content-type: audio/basic
Content-transfer-encoding: base64
... first half of encoded audio data goes here... ... second half of encoded audio data goes here...
message/external-body: Cho phép nội dung của message nằm bên ngoài của message và chỉ được tham chiều tới message đó. Tham số buộc phải có khi sử dụng “message/external-body” là “access-type”, cho biết cơ chế truy cập file. Một số cơ chế thường sử dụng:
(1) “FTP” và “TFTP”: truy cập file thông qua giao thức FTP và TFTP. Với các truy cập này, có thể sử dụng các tham số NAME, SIZE, DIRECTORY và MODE (NETASCII, OCTET và MAIL cho TFTP; ASCII, EBCDIC, IMAGE, LOCAL8 cho FTP). Nếu tham số MODE không được chỉ định, mặc định giá
127
trị này sẽ là NETASCII cho TFTP và ASCII cho FTP.
(2) “non-ftp”: giống như FTP ngoại trừ không dùng username và password để đăng nhập và mà đăng nhập dạng ẩn danh (anonymous) với password ứng với tài khoản email sử dụng.
(3) “local-file” và “afs”: “local-file” chỉ cho biết file được truy cập nằm trên máy cục bộ trong khi “afs” cho biết file được truy cập thông qua hệ thống file AFS. Tham số bắt buộc là NAME có giá trị là tên của file. Có thể dùng thêm tham số SITE để chỉ ra các máy tính có quyền truy cập nội dung của file. (4) “mail-server”: nội dung thực sự nằm trên mail server. Tham số bắt buộc là SERVER chứa địa chỉ mail của mail server chứa nội dung dữ liệu.
“message/external-body” phải sử dụng trường Content-ID trong header với một giá trị duy nhất để tham chiếu tới phần dữ liệu bên ngoài.
Content-Transfer-Encoding: Dùng để chỉ ra cơ chế biến đổi được dùng để biểu diễn nội dung phần thân thành dạng có thể truyền được trên các protocols giới hạn tập kí tự chuyển qua. Nhờ đó bên nhận biết cách để chuyển ngược lại dữ liệu gốc ban đầu. Một số cơ chế thường dùng:
o “7bit” (phân biệt hoa thường):
o “quoted-printable”
o “base64”
o “8bit”
o “binary”
o x-token
7bit là giá trị mặc định. 7bit, 8bit và binary chủ yếu dùng để chỉ loại dữ liệu chứa trong đối tượng. 7bit bao gồm các dòng ngắn (<1000) với các kí tự US-ASCII. 8bit gồm các dòng ngắn bao gồm các kí tự không phải ASCII. Binary gồm các kí tự không phải ASCII và không giới hạn độ dài của mỗi dòng.
Có thể định nghĩa thêm cơ chế mới với cấu trúc x-my-new-encoding. Tuy nhiên, chỉ có 2 bên trong hệ thống mới hiểu cơ chế này.
Nếu Content-Transfer-Encoding xuất hiện trong header của message thì có ảnh hưởng trên toàn bộ message đó. Nếu xuất hiện trong header của một phần của
message thì chỉ ảnh hưởng trên phần đó của message. Nếu một message (hoặc body part) loại “multipart” hoặc “message” thì chỉ có 7bit, 8bit và binany được dùng.
3. Content-ID:
Là một giá trị duy nhất cũng gần giống với Message-ID.
Content-ID là không bắt buộc, tuy nhiên khi sử dụng trong message có Content-ID là “message/external-body” thì bắt buộc phải có để cache dữ liệu được tham chiếu tới.
4. Content-Description:
Được dùng để bổ sung một số thông tin miêu tả cho nội dung của message, thường dùng dạng US-ASCII.
128
5. Content-Disposition:
Hai giá trị thường sử dụng là “inline” và “attachment”, có thể kèm thêm các tham số khác. “inline” cho biết nội dung của phần message đó sẽ tự động hiển thị giống như các phần khác. Trong khi “attachment” cho biết nội dung phần message bị tách riêng khỏi phần nội dung chính (xem thêm RFC-2183).
6. Content-Location:
Thông tin URI (uniform resource identifier) mà phần message sử dụng.
7. Content-Length:
Tổng số byte dữ liệu chứa trong thực thể MIME (MIME entity).
B.2 Cấu trúc mã trả về và ý nghĩa các chữ số
Mỗi mã trả về gồm một dãy 3 chữ số liên tiếp nhau “xyz” với ý nghĩa như sau: Chữ số đầu tiên (“x”): Chữ số đầu tiên cho biết kết quả của lệnh thành công hay thất bại, lệnh đã hoàn thành hay chưa hoàn thành. Các giá trị có thể của chữ số này như sau:
Định dạng Ý nghĩa
1yz Lệnh được chấp nhận và đang được xử lí. 2yz Lệnh được thực hiện thành công và kết thúc.
3yz Lệnh được chấp nhận, quá trình xử lí tạm dừng chờ cung cấp thêm thông tin.
4yz Lệnh không được chấp nhận và không có hành động nào được thực hiện, nhưng lỗi xảy ra chỉ là tạm thời và có thể thử thực hiện lại lệnh.
5yz Lệnh không được chấp nhận và không có hành động nào được thực hiện, thường do lệnh không đúng.
Bảng B.2 - Chữ số “x”
Chữ số thứ hai (“y”): Định dạng Ý nghĩa x0z Lỗi cấu trúc
x1z Thông tin trạng thái lệnh.
x2z Thông tin trạng thái kết nối client-server. x3z Không được chỉ định.
x4z Không được chỉ định.
x5z Thông tin liên quan đến dịch vụ (giao thức).
Bảng B.3 – Chữ số “y”
B.3 Base64 và Quoted-printable Encoding
B.3.1 Base64:
Phương pháp chuyển mã sử dụng các kí tự a-z, A-z, /, + và = để biểu diễn dữ liệu sau khi encode.
129
Các byte cần encode sẽ được biểu diễn dưới dạng nhị phân (nguyên vẹn 8 bit). Với mỗi 6 bit liên tiếp nhau trong dãy mã nhị phân tương ứng với một giá trị thập phân từ 1-63, giá trị này được ánh xạ vào bảng chuyển đổi bên dưới sang giá trị được encode.
Khi số kí tự cần encode là bội của 3 (24 bit) thì kết quả encode không có phần padding (các dấu =). Khi số kí tự cần encode chia 3 dư 2 thì kết quả sẽ có một dấu = ở cuối. Nếu số dư là 1 thì sẽ có 2 dấu = ở cuối kết quả encode.
Bảng mã chuyển đổi: Value Char Value Char Value Char Value Char 0 A 16 Q 32 g 48 W 1 B 17 R 33 H 49 X 2 C 18 S 34 I 50 Y 3 D 19 T 35 J 51 Z 4 E 20 U 36 K 52 0 5 F 21 V 37 L 53 1 6 G 22 W 38 M 54 2 7 H 23 X 39 N 55 3 8 I 24 Y 40 O 56 4 9 J 25 Z 41 P 57 5 10 K 26 a 42 Q 58 6
130 11 L 27 b 43 R 59 7 12 M 28 C 44 S 60 8 13 N 29 D 45 T 61 9 14 O 30 E 46 U 62 + 15 P 31 F 47 V 63 / Bảng B.4 – Bảng mã chuyển đổi Ví dụ: Text content M A n ASCII 77 97 110 Bit pattern 0 1 0 0 1 1 0 1 0 1 1 0 0 0 0 1 0 1 1 0 1 1 1 0 Index 19 22 5 46 Base64-encoded T W F u