Giới thiệu dạng thức hợp quy XML

Giúp XML phù hợp với phép thử hồi quy, chữ ký số, và hơn thế

XML cẩn thận tách các chi tiết của một tệp hay một nguồn dữ liệu khác theo từng byte, từ mô hình trừu tượng của một tài liệu XML. Đây có thể là một điều bất tiện khi so sánh chất lượng của hai tài liệu XML ngang nhau -- hoặc so sánh trực tiếp (thí dụ, như là một phần của bộ thử nghiệm) hoặc so sánh các chữ ký số dành cho những mục đích bảo mật -- để xác định liệu một tài liệu XML đã bị giả mạo theo một cách nào đó hay chưa. Vì thế, W3C đã giải quyết vấn đề này với một đặc tả XML Canonicalization (c14n), cái mà định ra một dạng thức chuẩn cho một tài liệu XML đảm bảo cung cấp những so sánh theo từng byte phù hợp và do đó có những chữ ký số thống nhất. Trong bài viết này, Uche Ogbuji sẽ giới thiệu về XML Canonicalization (Hợp quy hóa XML).

Uche Ogbuji, Tư vấn trưởng

Uche Ogbuji là một tư vấn viên và là người đồng sáng lập của Fourthought Inc., một hãng bán và tư vấn phần mềm chuyên về các giải pháp XML cho quản lý tri thức doanh nghiệp. Fourthought phát triển 4Suite, một nền tảng mã nguồn mở cho XML, RDF, và các ứng dụng quản lý tri thức. Ông Ogbuji cũng là một nhà phát triển hàng đầu của ngôn ngữ truy vấn Versa RDF. Ông là một kỹ sư máy tính kiêm nhà viết sách sinh ra ở Nigeria, sống và làm việc ở Boulder, Colorado, USA. Bạn có thể liên hệ với ông Ogbuji theo địa chỉ uche@ogbuji.net.



08 01 2010

Tinh hoa của XML là nằm trong thế giới tài liệu, và điều này được phản ánh trong các quy luật cú pháp của nó. Cú pháp của nó lỏng lẻo hơn cú pháp của các dạng thức dữ liệu liên quan với những bản ghi cơ sở dữ liệu. Một bộ phân tách XML chuyển một dạng thức đã được mã hóa của một tài liệu XML (việc mã hóa được chỉ định trong khai báo XML) thành một mô hình trừu tượng hiển thị thông tin trong tài liệu XML đó. W3C dạng thức hóa mô hình trừu tượng này như một XML Infoset (xem Tài nguyên ), nhưng rất nhiều xử lý XML phải tập trung vào dạng thức gốc đã được mã hóa, cho phép rất nhiều phương sai từ vựng: Các thuộc tính có thể đi theo bất cứ trật tự nào; các quy tắc khoảng trắng rất linh hoạt ở những chỗ như là giữa một tên phần tử và những thuộc tính của nó; có một vài cách được sử dụng để hiển thị ký tự và tránh khỏi các ký tự đặc biệt, vân vân. Không gian tên còn đưa ra tính linh hoạt từ vựng hơn nữa (ví dụ như lựa chọn các tiền tố). Kết quả là bạn có thể có vô số các tài liệu tương đương một cách chính xác trong các quy tắc của XML 1.0, trong khi nếu chúng được so sánh theo từng byte theo nguồn đã được mã hóa thì rất khác biệt.

Tính linh hoạt từ vựng này gây ra những vấn đề trong các phần như là thử nghiệm quy hồi và chữ ký số. Giả sử bạn có thể tạo ra một bộ thử nghiệm bao gồm trường hợp mong muốn tài liệu trong Ví dụ 1 như một đầu ra đúng.

Ví dụ 1. Tài liệu XML mẫu
<doc>
  <a a1="1" a2="2">123</a>
</doc>

Nếu bạn tiến hành một thử nghiệm XML hoàn chỉnh bạn sẽ phải công nhận tài liệu trong Ví dụ 2 là một đầu ra đúng.

Ví dụ 2. Biểu mẫu tương đương của tài liệu XML trong Ví dụ 1
<?xml version="1.0" encoding="UTF-8"?>
<doc>
  <a
     a2="2"   a1="1"
  >123</a>
</doc>

Khoảng trắng trong thẻ là khác, các thuộc tính nằm theo thứ tự khác nhau, và các thực thể ký tự đã được thay thế bằng các ký tự chữ tương ứng -- nhưng các Infoset là giống nhau. Sẽ khó để thiết lập sự giống nhau này thông qua so sánh theo từng byte. Trong trường hợp các chữ ký số, bạn có thể muốn chắc chắn rằng khi bạn gửi một tài liệu qua hệ thống tin nhắn thì nó chưa bị làm hỏng hoặc bị làm giả trong quá trình. Để làm như vậy, bạn sẽ muốn có một băm mật mã hoặc chữ ký số được phát triển đầy đủ của tài liệu. Tuy nhiên, nếu bạn gửi Ví dụ 1 qua hệ thống tin nhắn, nó có thể thông qua xử lý thông thường trông giống như Ví dụ 2. Nếu vậy, dấu thăng đơn giản hoặc chữ ký số không khớp nhau, cho dù tài liệu vẫn chưa thay đổi.

Giải pháp của W3C cho việc này được phát triển như một phần của những đặc tả chữ ký số cho XML. W3C xác định canonical XML - XML chuẩn (xem Tài nguyên), là một biểu mẫu từ vựng được thường hóa cho XML ở đó tất cả những thay đổi cho phép đã được gỡ bỏ, và các quy tắc nghiêm ngặt được đặt ra để cho phép một so sánh theo từng byte thống nhất. Quá trình chuyển đổi thành dạng thức hợp quy được biết đến là quy trình hợp quy hóa - canonicalization (thường được viết tắt là "c14n"). Trong bài viết này, các bạn sẽ tìm hiểu dạng thức XML hợp quy.

Các quy tắc của dạng thức hợp quy

Tổng quan rõ nhất của quá trình c14n là danh sách sau (mà tôi đã biên soạn), được cung cấp trong đặc tính:

  • Tài liệu được mã hóa theo UTF-8.
  • Các ngắt dòng được thường hóa thành "#xA" trên đầu vào, trước khi phân tách.
  • Các giá trị thuộc tính được thường hóa, như thể là bởi một bộ xử lý hợp lệ.
  • Các thuộc tính mặc định được thêm vào mỗi phần tử, như thể là bởi một bộ xử lý hợp lệ.
  • Các đoạn CDATA được thay thế bằng nội dung ký tự chữ của chúng.
  • Ký tự và các tham chiếu thực thể được phân tích sẽ được thay thế bằng các ký tự chữ (ngoại trừ các ký tự đặc biệt).
  • Các ký tự đặc biệt trong các giá trị thuộc tính và nội dung ký tự được thay thế bởi các tham chiếu ký tự (mà thông thường dành cho XML được định dạng tốt).
  • Khai báo XML và DTD được gỡ bỏ. (Chú ý rằng mặc dù tôi luôn đề nghị dùng một khai báo XML nói chung, nhưng tôi đánh giá cao sự hợp lý nếu bỏ qua nó trong dạng thức hợp quy XML.)
  • Các phần tử rỗng được chuyển thành các cặp thẻ bắt đầu-kết thúc.
  • Các khoảng trắng bên ngoài phần tử tài liệu và trong các thẻ bắt đầu và kết thúc được thường hóa.
  • Tất cả khoảng trắng trong nội dung ký tự được giữ lại (ngoại trừ các ký tự được gỡ bỏ trong quá trình thường hóa dòng tin).
  • Các dấu phân cách giá trị thuộc tính được thiết lập thành các dấu ngoặc (ngoặc kép).
  • Các khai báo không gian tên không cần thiết được gỡ bỏ khỏi các phần tử.
  • Trình tự từ điển được đặt trên các khai báo không gian tên và các thuộc tính của mỗi phần tử.

Đừng lo lắng nếu một số các quy tắc này có vẻ không rõ ràng tại thời điểm này. Tôi sẽ đưa ra các giải thích dài hơn cùng ví dụ của các quy tắc phổ biến hơn đang hoạt động. Trong bài viết này, tôi không nói đến bất kỳ bước nào trong c14n liên quan đến hiệu lực DTD. Tôi đã đề cập đến XML Infoset một vài lần, nhưng điều thú vị là W3C đã chọn xác định c14n không phải về mặt Infoset, mà về mặt mô hình dữ liệu XPath, một mô hình dữ liệu đơn giản (và một số người còn coi là sạch) hơn Infoset. Đây có thể là một chi tiết nhỏ không ảnh hưởng nhiều đến sự am hiểu của bạn về dạng thức hợp quy, nhưng nó đáng nhớ nếu bạn cũng phải làm việc với các công nghệ dựa trên Infoset.


Các thẻ hợp quy hóa

Các thẻ được hợp quy hóa bằng cách áp dụng các quy tắc khoảng trắng cụ thể trong các thẻ đó, cũng như là một trật tự cụ thể của các khai báo không gian tên và các thuộc tính thông thường. Sau đây là chuỗi không chính thức dạng thức của một thẻ bắt đầu hợp quy hóa của riêng tôi:

  1. Dấu ngoặc mở (<), được theo sau đó bởi phần tử QName (tiền tố cộng dấu hai chấm cộng tên cục bộ).
  2. Khai báo không gian tên mặc định, nếu có, tiếp đến tất cả các khai báo không gian tên khác, theo thứ tự alphabet của các tiền tố mà chúng xác định. Hãy bỏ qua tất cả các khai báo không gian tên không cần thiết (những khai báo mà đã được thực hiện bởi một phần từ đi trước đó, và vẫn chưa bị gối lên). Hãy sử dụng một dấu cách đơn trước mỗi khai báo không gian tên, không đặt dấu cách nào cả ở hai bên dấu bằng và các dấu ngoặc kép xung quanh URI không gian tên.
  3. Tất cả các thuộc tính theo thứ tự bảng chữ cái alphabet, được đứng trước là dấu cách, không có dấu cách nào ở hai bên dấu bằng, và các dấu ngoặc kép xung quanh giá trị thuộc tính.
  4. Cuối cùng, là dấu ngoặc đóng (>).

Một thẻ kết thúc của dạng thức hợp quy đơn giản hơn nhiều: Trước và sau phần tử QName là dấu ngoặc mở (<)và dấu ngoặc đóng (>). Ví dụ 3 là một mẫu ví dụ của XML không nằm trong dạng thức chuẩn.

Ví dụ 3. Mẫu XML không nằm trong dạng thức hợp quy
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns:x="http://example.com/x" xmlns="http://example.com/default">
  <a
     a2="2"   a1="1"
  >123</a>
  <b y:a1='1' xmlns="http://example.com/default" a3='"3"'
     xmlns:y='http://example.com/y' y:a2='2'/>
</doc>

Ví dụ 4 là tài liệu tương tự trong dạng thức hợp quy.

Ví dụ 4. Ví dụ 3 như một XML hợp quy
<doc xmlns="http://example.com/default" xmlns:x="http://example.com/x">
  <a a1="1" a2="2">123</a>
  <b xmlns:y="http://example.com/y" a3=""3"" y:a1="1" y:a2="2"></b>
</doc>

Những thay đổi sau được yêu cầu để hợp quy hóa Ví dụ 3:

  • Gỡ bỏ khai báo XML (tài liệu đã ở dạng mã UTF-8, vì thế không cần phải chuyển đổi).
  • Hãy đặt khai báo không gian tên mặc định lên doc trước khai báo của các không gian tên khác (không gian tên cho tiền tố x trong trường hợp này).
  • Giảm một dấu cách trong thẻ bắt đầu a để có một khoảng đơn trước mỗi thuộc tính.
  • Gỡ bỏ khai báo không gian tên mặc định không cần thiết trên thẻ start b.
  • Hãy đảm bảo rằng khai báo không gian tên còn lại (cho tiền tố y ) đi trước các thuộc tính khác.
  • Đặt các thuộc tính còn lại theo thứ tự alphabet đối với các QNames của chúng (ví dụ, "a3" sau đó "y:a1" sau đó "y:a2").
  • Thay đổi dấu phân tách ngoặc trên khai báo không gian tên xmlns:y và các thuộc tính y:a1, y:a2, và a3 từ một ngoặc đơn (') sang một ngoặc kép ("), cái mà trong trường hợp của a3 cũng yêu cầu rằng các ký tự dấu ngoặc kép bị nhúng (") chuyển thành ".

Tôi đã kiểm tra việc chuyển đổi dạng thức hợp quy sử dụng module c14n cho Python, đi cùng với PyXML (xem Tài nguyên). Ví dụ 5 là mã trình tôi đã sử dụng để hợp quy hóa Ví dụ 3 thành Ví dụ 4.

Ví dụ 5. Mã trình Python để hợp quy hóa XML
from xml.dom import minidom
from xml.dom.ext import c14n
doc = minidom.parse('listing3.xml')
canonical_xml = c14n.Canonicalize(doc)
print canonical_xml

Hợp quy hóa dữ liệu ký tự

Dữ liệu ký tự ở trong dạng thức hợp quy về cơ bản là chữ đến hết mức có thể: Các thực thể ký tự được xử lý theo mã Unicode thô sơ (sau đó được xếp như mã UTF-8); các đoạn CDATA được thay thế bằng nội dung thô sơ của chúng, và nhiều thay đổi khác dọc theo những dòng này. Điều này đúng với dữ liệu ký tự trong các giá trị thuộc tính cũng như nội dung. Các thuộc tính cũng được thường hóa theo các quy tắc cho loại DTD của chúng, nhưng điều này hầu hết ảnh hưởng đến các tài liệu sử dụng một DTD, mà tôi không đề cập đến trong bài viết này. Ví dụ 6 là một tài liệu mẫu được dựa một phần trên một ví dụ trong đặc tính c14n.

Ví dụ 6. XML mẫu để thể hiện việc hợp quy hóa cho dữ liệu ký tự
<?xml version="1.0" encoding="ISO-8859-1"?>
<doc>
   <text>First line&#x0d;&#10;Second line</text>
   <value>&#x32;</value>
   <compute><![CDATA[value>"0" && value<"10" ?"valid":"error"]]></compute>
   <compute expr='value>"0" &amp;&amp; value&lt;"10" ?"valid":"error"'>valid</compute>
</doc>

Ví dụ 7 là tài liệu tương tự trong dạng thức hợp quy.

Những thay đổi sau đây được yêu cầu để hợp quy hóa Ví dụ 6:

  • Gỡ bỏ khai báo XML và chuyển chúng thành mã UTF-8.
  • Thay đổi các tham chiếu ký tự &#x32; thành số thực 2.
  • Thay thế đoạn CDATA bằng nội dung của nó, và thay các ngoặc đóng (>) bằng &gt;, kí hiệu (&) bằng &amp;, và dấu ngoặc mở (<) bằng &lt;.
  • Thay thế các dấu ngoặc đơn được sử dụng cho thuộc tính expr bằng các dấu ngoặc kép, và sau đó thay dấu ngoặc kép (") bằng &quot;.

Một bước quan trọng mà tôi chưa nói đến trong các Ví dụ 67 là phép chuyển đổi thành mã UTF-8, cái mà không dễ để minh họa trong một ví dụ của một bài viết. Hãy tưởng tượng rằng tài liệu gốc có tham chiếu ký tự &#169; (thể hiện dấu bản quyền) trong nội dung. Dạng thức hợp quy sẽ thay thế cái này với một chuỗi UTF-8 bao gồm byte C2 hệ mười sáu theo sau bởi byte A9 hệ mười sáu.


Xin đừng quên tùy chọn riêng biệt

Đôi khi bạn chỉ muốn đánh dấu hoặc so sánh một cây con của một tài liệu XML, hơn là cả tài liệu. Có lẽ bạn muốn đánh dấu chỉ phần thân của một tin nhắn SOAP và bỏ qua lớp vỏ phong bì (envelope). W3C cung cấp cho điều này trong đặc tính dạng thức hợp quy riêng, mà phần lớn có liên quan đến việc phân loại các khai báo không gian tên bên trong và bên ngoài cây nhỏ đó.

Tôi đã đề cập đến sự mâu thuẫn tiềm tàng bị gây ra bởi việc lựa chọn các tiền tố. Các không gian tên XML quy định rằng các tiền tố không hợp lý, và vì thế hai tệp thay đổi khi lựa chọn các tiền tố không gian tên sẽ được xử lý như nhau. Thật không may, c14n lại không đề cập đến trường hợp này. Một số thao tác xử lý XML hoàn toàn có hiệu lực có thể thay đổi các tiền tố, vì thế hãy nhận thức đúng về vấn đề tiềm tàng này.

Canonical XML là một công cụ quan trọng luôn phải có. Bạn có thể không phải ngay lập tức làm việc có liên quan đến an ninh bảo mật hay phép thử phần mềm liên quan đến XML, nhưng bạn sẽ ngạc nhiên về tần suất nhu cầu đối với c14n xuất hiện một khi bạn đã quen với nó. Nó là một trong những thứ giúp bạn giảm thiểu được rất nhiều phức tạp mà bạn chưa bao giờ nghĩ là phải tránh lúc ban đầu.

Tài nguyên

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Nguồn mở
ArticleID=460409
ArticleTitle=Giới thiệu dạng thức hợp quy XML
publish-date=01082010