Làm đẹp và Định dạng XML (XML Formatter & Prettify)

Công cụ làm đẹp và định dạng XML là gì?

Công cụ làm đẹp và định dạng XML là tiện ích nhận văn bản XML, kiểm tra cú pháp rồi trình bày lại theo chế độ được chọn. Với mã được cung cấp, công cụ có hai chức năng chính: làm đẹp bằng cách thêm xuống dòng, thụt lề và thu gọn bằng cách bỏ khoảng trắng giữa các thẻ. Kết quả vẫn là văn bản XML, không phải JSON hay một định dạng dữ liệu khác.

Nhu cầu format XML thường xuất hiện khi dữ liệu bị dồn thành một dòng dài. Trong tình huống đó, người đọc khó nhận ra phần tử nào bao chứa phần tử nào, đoạn nào là nội dung và đâu là vị trí đóng thẻ. Việc tách dòng, căn lề giúp quan sát cấu trúc thuận tiện hơn, nhất là với những đoạn XML có nhiều cấp lồng nhau. Tuy nhiên, thuật toán của công cụ dựa trên nhận diện mẫu văn bản nên không bảo đảm thụt lề đúng mọi cấu trúc XML hợp lệ.

Công cụ cũng hỗ trợ nhận biết lỗi cú pháp trước khi tạo kết quả, nhưng không tự sửa thẻ sai. Nếu đầu vào bị cơ chế kiểm tra từ chối, công cụ hiển thị thông báo lỗi thay vì tự thêm thẻ đóng hoặc đoán nội dung bị thiếu.

Bài viết này tập trung vào cách hiểu đầu vào, đầu ra và phạm vi sử dụng kết quả. Những giải thích về chức năng dựa trên mã được cung cấp; kiến thức chung về XML được dùng để làm rõ các trường hợp cần thận trọng, không phải để suy ra tính năng chưa có bằng chứng.

Những thuật ngữ cần hiểu khi định dạng XML

XML

XML là ngôn ngữ đánh dấu dùng để biểu diễn dữ liệu bằng phần tử, thuộc tính và cấu trúc lồng nhau. Chẳng hạn, một phần tử có thể chứa thông tin trực tiếp hoặc bao quanh các phần tử con. XML không đồng nghĩa HTML: tên thẻ trong XML thường được chọn theo mục đích dữ liệu, thay vì chủ yếu phục vụ hiển thị trang web. Công cụ này tiếp nhận XML để trình bày lại, không xác định ý nghĩa nghiệp vụ của từng thẻ.

Well-formed XML

Well-formed XML là XML tuân thủ các quy tắc cú pháp cơ bản, như đóng thẻ phù hợp, lồng thẻ đúng thứ tự và biểu diễn thuộc tính đúng cách. Đây là kiến thức nền giúp hiểu kết quả kiểm tra của công cụ. Một tài liệu đọc được về mặt cú pháp vẫn có thể thiếu trường bắt buộc hoặc chứa giá trị sai. Vì vậy, không nên nhầm “well-formed” với việc phù hợp lược đồ hay được hệ thống nghiệp vụ chấp nhận.

Pretty-print và thụt lề

Pretty-print là cách trình bày văn bản để dễ đọc hơn bằng xuống dòng và căn lề. Thụt lề thể hiện các cấp cấu trúc bằng khoảng trắng ở đầu dòng. Trong công cụ này, mỗi mức mà thuật toán nhận diện được dùng bốn dấu cách. Đó là quy tắc trình bày của công cụ, không phải yêu cầu bắt buộc của XML. Pretty-print cũng không đồng nghĩa sửa cú pháp hay chuẩn hóa XML để phục vụ chữ ký số.

Minify

Minify là thu gọn biểu diễn văn bản bằng cách loại bỏ một số ký tự trình bày. Ở đây, chế độ thu gọn chủ yếu xóa khoảng trắng giữa các thẻ và bỏ khoảng trắng ngoài cùng của đầu vào. Nó không phải nén ZIP hoặc GZIP, không đổi tên phần tử và không xóa mọi dấu cách. Nếu XML ban đầu đã liền mạch, kết quả có thể không ngắn hơn; công cụ cũng không tính tỷ lệ giảm dung lượng.

Mixed content và khoảng trắng có ý nghĩa

Mixed content là nội dung gồm văn bản và phần tử con xuất hiện xen kẽ trong cùng một phần tử. Với loại dữ liệu này, khoảng trắng có thể phân cách các từ chứ không chỉ dùng để căn lề. Ví dụ, dấu cách nằm giữa hai phần được đánh dấu riêng có thể cần thiết để đọc thành một câu. Công cụ không phân biệt đầy đủ hai vai trò đó, nên việc xử lý khoảng trắng có thể ảnh hưởng nội dung khi ứng dụng khác đọc XML.

Đầu vào, đầu ra và cách hiểu trạng thái kết quả

Văn bản XML nào được tiếp nhận?

Đầu vào là văn bản XML được nhập hoặc dán vào ô dữ liệu, không có đơn vị đo. Trong phần mã được cung cấp, không có chức năng tải tệp, lấy XML từ URL hay chọn lược đồ để xác thực. Vì thế, nên hiểu đây là công cụ xử lý một đoạn văn bản đã có sẵn, không phải tiện ích tự lấy dữ liệu từ dịch vụ bên ngoài.

Trước khi kiểm tra, khoảng trắng ở đầu và cuối toàn bộ đầu vào được loại bỏ. Nếu nội dung rỗng hoặc chỉ gồm khoảng trắng, công cụ không tạo XML mới mà đưa kết quả về rỗng và chuyển sang trạng thái chờ nhập liệu. Mã không khai báo giới hạn số ký tự, nhưng điều đó không chứng minh công cụ xử lý được dữ liệu lớn tùy ý.

Kết quả và thông báo trạng thái nói lên điều gì?

Có ba tình huống chính cần phân biệt:

• Chờ nhập liệu: không còn nội dung để xử lý sau khi bỏ khoảng trắng ngoài cùng.
• XML hợp lệ: đầu vào được cơ chế kiểm tra hiện có chấp nhận và đã được đưa qua chế độ làm đẹp hoặc thu gọn.
• Lỗi thẻ/cú pháp: cơ chế kiểm tra phát hiện dấu hiệu lỗi; kết quả bị xóa và thông báo lỗi được hiển thị.

Nhãn hợp lệ không chứng minh dữ liệu đúng XSD, DTD hay quy tắc nghiệp vụ. Khi có lỗi mới, công cụ không giữ kết quả cũ, giúp tránh nhầm bản trước đó với kết quả của đầu vào hiện tại.

Ô kết quả chỉ đọc và có chức năng sao chép qua API clipboard của trình duyệt. Khả năng sao chép thực tế phụ thuộc môi trường và quyền truy cập. Mã không thể hiện chức năng tải xuống tệp hoặc báo cáo số byte tiết kiệm sau khi thu gọn.

Công cụ kiểm tra, làm đẹp và thu gọn XML như thế nào?

Kiểm tra cú pháp trước khi xử lý

Trình tự xử lý là bỏ khoảng trắng ngoài cùng, kiểm tra XML rồi mới thực hiện chế độ đang chọn. Để kiểm tra, công cụ dùng DOMParser, một API giúp trình duyệt thử đọc văn bản thành tài liệu XML. Sau đó, công cụ tìm phần tử mang tên parsererror trong tài liệu nhận được. Nếu tìm thấy, nó lấy nội dung thông báo và chuyển sang trạng thái lỗi.

Đây là kiểm tra khả năng phân tích cú pháp bằng cơ chế của trình duyệt, không phải bước đối chiếu dữ liệu với một lược đồ được người dùng chọn. Nội dung thay đổi hoặc chế độ thay đổi sẽ kích hoạt xử lý lại; không cần một bước gửi dữ liệu riêng trong logic được cung cấp.

Quy tắc xuống dòng và thụt lề

Ở chế độ làm đẹp, công cụ thay ranh giới giữa các thẻ bằng xuống dòng, rồi xét từng đoạn văn bản. Nó nhận diện một số dạng thẻ mở và thẻ đóng để tăng hoặc giảm mức thụt lề. Mỗi mức được biểu diễn bằng bốn dấu cách, nên với mức được nhận diện là 2, phần căn lề là 2 × 4 = 8 dấu cách.

Một đoạn gồm thẻ mở, nội dung và thẻ đóng ở cuối thường được giữ trên cùng dòng. Thẻ đóng đứng đầu đoạn sẽ giảm mức thụt lề nếu mức hiện tại khác không. Những quy tắc này giúp trình bày các cấu trúc thông thường, nhưng không phải phép duyệt đầy đủ cây phần tử XML.

Phạm vi loại bỏ khoảng trắng của chế độ thu gọn

Chế độ thu gọn chỉ xóa nhóm khoảng trắng nằm ngay giữa dấu kết thúc một thẻ và dấu bắt đầu thẻ tiếp theo. Dấu cách thông thường bên trong nội dung văn bản không tự động bị xóa hết. Tuy nhiên, khoảng trắng giữa các thẻ vẫn có thể mang ý nghĩa dữ liệu, nên vị trí bị xóa không đồng nghĩa với việc chắc chắn được phép xóa.

Cả hai chế độ đều biến đổi chuỗi đầu vào, không tái tạo kết quả từ cây XML đã phân tích. Mã cũng không có bước phân tích cú pháp lại đầu ra. Vì vậy, kiểm tra đầu vào thành công không phải bảo đảm rằng mọi thay đổi trình bày đều bảo toàn nội dung hoặc tạo kết quả thích hợp cho mọi ứng dụng.

Ví dụ định dạng XML và cách đọc kết quả

Các ví dụ dưới đây được suy ra từ logic mã được cung cấp, không phải kết quả chạy thử trực tiếp. Đầu vào là văn bản minh họa, không có đơn vị đo; số dòng và số dấu cách chỉ mô tả cách trình bày.

Làm đẹp XML có phần tử lồng nhau

Giả định chọn chế độ làm đẹp với đầu vào:

<root><item>Ví dụ</item></root>

Cấu trúc này có một phần tử con nằm trong phần tử gốc. Quy tắc tách ranh giới thẻ và thụt lề cho kết quả suy ra gồm ba dòng:

<root>
    <item>Ví dụ</item>
</root>

Dòng chứa phần tử con có bốn dấu cách phía trước. Đoạn chứa cả thẻ mở và thẻ đóng của phần tử con không làm tăng thêm mức; thẻ đóng của phần tử gốc đưa mức thụt lề về không. Đây là ví dụ đơn giản phù hợp với mẫu nhận diện, không đại diện cho mọi tên thẻ.

Thu gọn nhưng giữ dấu cách trong nội dung

Giả định chọn chế độ thu gọn và nhập:

<root>   <item>Hai từ</item>   </root>

Các nhóm ba dấu cách giữa thẻ bị xóa, còn dấu cách giữa “Hai” và “từ” không nằm ở ranh giới hai thẻ. Kết quả suy ra là:

<root><item>Hai từ</item></root>

Ví dụ cho thấy thu gọn không xóa mọi dấu cách trong tài liệu. Không thể từ đó kết luận mọi khoảng trắng cần thiết đều được giữ lại.

XML sai cú pháp và khoảng trắng cần bảo toàn

Giả định nhập <root><item></root> ở bất kỳ chế độ nào. Thẻ con chưa được đóng phù hợp nên bộ phân tích XML thông thường sẽ báo lỗi. Khi công cụ phát hiện lỗi, ô kết quả rỗng; nội dung thông báo cụ thể phụ thuộc trình duyệt.

Với trường hợp khác, giả định thu gọn đầu vào:

<para><bold>Xin</bold> <italic>chào</italic></para>

Dấu cách giữa hai phần tử con bị loại bỏ:

<para><bold>Xin</bold><italic>chào</italic></para>

Nếu ứng dụng ghép văn bản của các phần tử con, nội dung có thể thành “Xinchào” thay vì “Xin chào”. Đây là thay đổi cần đánh giá theo cách ứng dụng sử dụng dữ liệu, không chỉ theo vẻ ngoài của mã.

Giới hạn cần biết trước khi dùng kết quả XML

Khi khoảng trắng là một phần của dữ liệu

Cần thận trọng với XML chứa văn bản xen kẽ phần tử, tài liệu biên tập hoặc nội dung yêu cầu giữ nguyên khoảng trắng. Cả làm đẹp lẫn thu gọn đều tác động đến khoảng trắng giữa thẻ. Mã không có nhánh riêng để bảo toàn nội dung theo xml:space, cũng không có xử lý chuyên biệt cho CDATA hoặc chú thích.

Do đó, không nên mặc định rằng mọi vùng nội dung đặc biệt sẽ giữ nguyên ý nghĩa. Nếu yêu cầu bảo toàn từng ký tự, hãy giữ bản gốc và kiểm tra kết quả trong ứng dụng sẽ đọc XML. Với dữ liệu có chữ ký số hoặc cơ chế kiểm tra tính toàn vẹn, không dùng kết quả định dạng thay cho bản gốc hay xem đây là phép chuẩn hóa XML.

Giới hạn kiểm tra và bảo toàn nội dung

Thụt lề có thể lệch ở một số trường hợp. Đặc biệt, mẫu nhận diện thẻ mở có thể bỏ sót tên thẻ chỉ một ký tự, khiến phần tử con không được tăng mức căn lề như mong đợi. Sai lệch trình bày này không nhất thiết có nghĩa đầu vào sai cú pháp.

Cơ chế tìm parsererror cũng có thể nhận nhầm tài liệu hợp lệ chứa phần tử cùng tên là lỗi. Ngoài ra, công cụ không có bước xác thực XSD hoặc DTD chuyên biệt, nên trạng thái hợp lệ không thay thế kiểm tra lược đồ.

Ngưỡng kích thước, hiệu năng và độ tương thích trên từng trình duyệt chưa được xác minh. Việc xử lý lại theo mỗi thay đổi đầu vào có thể ảnh hưởng độ phản hồi với tài liệu lớn. Đoạn mã xử lý không thể hiện gửi XML qua mạng, nhưng chưa đủ bằng chứng để kết luận về lưu trữ, bảo mật hoặc hoạt động của toàn trang.

Khi nào nên dùng công cụ định dạng XML?

Đọc và trao đổi các đoạn XML

Công cụ phù hợp khi cần đọc một đoạn XML từ cấu hình, phản hồi dịch vụ hoặc dữ liệu trao đổi mà bạn đã có. Nó không tự kết nối đến những nguồn đó. Chế độ làm đẹp có thể giúp quan sát quan hệ cha–con, nhận ra các nhóm phần tử và trao đổi một đoạn mẫu dễ đọc hơn với người khác.

Giá trị chính nằm ở việc hỗ trợ quan sát, không phải xác nhận toàn bộ dữ liệu đúng. Một cấu trúc căn lề đẹp vẫn có thể chứa giá trị không phù hợp với hệ thống đích. Khi trao đổi để tìm hiểu vấn đề, nên dùng đoạn đại diện đủ ngữ cảnh và loại bỏ thông tin nhạy cảm thay vì dán toàn bộ tài liệu không cần thiết.

Chuẩn bị chuỗi XML để sử dụng tiếp

Thu gọn có thể hữu ích khi cần một chuỗi ít khoảng trắng trình bày hơn, chẳng hạn để đưa vào một ô nhập văn bản khác. Điều kiện quan trọng là các khoảng trắng bị bỏ không mang ý nghĩa đối với ứng dụng tiếp nhận. Công cụ không bảo đảm kích thước nhỏ nhất và không thay thế phương pháp nén dữ liệu dùng khi truyền hoặc lưu trữ.

Một quy trình thận trọng gồm giữ bản gốc, xử lý bản sao và kiểm tra kết quả ở nơi sẽ sử dụng XML. Nếu tài liệu có dữ liệu cá nhân hoặc bí mật truy cập, ưu tiên mẫu đã làm sạch. Khi cần chuyển XML sang JSON, ánh xạ trường dữ liệu hoặc kiểm tra lược đồ, hãy coi đó là nhu cầu khác; hai chế độ hiện có chỉ phục vụ trình bày và thu gọn văn bản.

Làm đẹp, thu gọn và định dạng XML trong trình soạn thảo khác nhau thế nào?

Chọn làm đẹp hay thu gọn theo mục tiêu

Làm đẹp ưu tiên khả năng đọc: thêm xuống dòng và khoảng trắng để thể hiện cấu trúc. Thu gọn ưu tiên giảm ký tự trình bày giữa thẻ. Cả hai đều có thể ảnh hưởng khoảng trắng, vì vậy không nên lựa chọn chỉ dựa vào việc kết quả nhìn đẹp hơn hoặc ngắn hơn.

Với đoạn XML cần trao đổi để đọc hiểu, làm đẹp thường phù hợp hơn. Với chuỗi cần ít khoảng trắng trình bày, có thể cân nhắc thu gọn sau khi xác định cách ứng dụng đích diễn giải nội dung. Nếu nhiệm vụ yêu cầu giữ nguyên dữ liệu từng ký tự, bản gốc vẫn là điểm đối chiếu cần thiết.

Định dạng không phải sửa lỗi hoặc chuẩn hóa XML

Định dạng thay đổi cách trình bày; sửa lỗi xử lý cú pháp sai; xác thực lược đồ kiểm tra cấu trúc theo yêu cầu; chuẩn hóa XML tạo biểu diễn theo những quy tắc chuyên biệt. Đây là các tác vụ khác nhau, không nên gộp thành một chức năng chỉ vì đều liên quan đến XML.

Xử lý một đoạn văn bản qua web cũng khác quy trình chỉnh sửa tệp trong IntelliJ, Notepad++ hoặc Visual Studio Code. Trình soạn thảo có bối cảnh làm việc với tệp và cấu hình riêng; khả năng định dạng thực tế phụ thuộc phiên bản, thành phần hỗ trợ và thiết lập. Không thể suy ra phím tắt hoặc chất lượng xử lý của từng môi trường từ mã của công cụ web này. Lựa chọn nên dựa trên mục tiêu làm việc và yêu cầu bảo toàn dữ liệu, không chỉ tên tính năng.

Câu hỏi thường gặp

Vì sao ô kết quả trống sau khi tôi dán XML?

Hai nguyên nhân được mã xác nhận là đầu vào không còn nội dung sau khi bỏ khoảng trắng ngoài cùng hoặc cơ chế kiểm tra phát hiện lỗi cú pháp. Hãy phân biệt trạng thái chờ nhập liệu với trạng thái báo lỗi để hiểu tình huống. Khi phát hiện lỗi, công cụ chủ động xóa kết quả trước đó, không giữ một bản định dạng cũ. Thông báo đi kèm do bộ phân tích của trình duyệt cung cấp, nên cách diễn đạt có thể khác giữa các môi trường.

Thông báo XML hợp lệ có nghĩa là dữ liệu đúng XSD hoặc DTD không?

Không. Trong phạm vi công cụ này, nhãn hợp lệ chỉ cho biết đầu vào không bị cơ chế kiểm tra cú pháp hiện có phát hiện lỗi. Mã không có bước chọn lược đồ và đối chiếu tài liệu với XSD hoặc DTD để chứng nhận sự phù hợp. Một tài liệu vẫn có thể thiếu phần tử bắt buộc, chứa giá trị ngoài phạm vi hoặc không đáp ứng quy tắc nghiệp vụ. Nếu hệ thống tiếp nhận có yêu cầu riêng, cần kiểm tra bằng cơ chế xác thực phù hợp của hệ thống đó.

Tôi có thể đổi bốn dấu cách thụt lề thành tab hoặc hai dấu cách không?

Không có tùy chọn đó trong giao diện và logic được cung cấp. Chế độ làm đẹp sử dụng cố định bốn dấu cách cho mỗi mức thụt lề mà thuật toán nhận diện. Đây là lựa chọn trình bày của công cụ, không phải quy định bắt buộc đối với XML. Nếu cần tuân thủ quy ước khác của dự án, bạn cần môi trường định dạng có cấu hình tương ứng. Việc thay kiểu căn lề vẫn cần thận trọng nếu khoảng trắng tham gia vào nội dung dữ liệu.

Chế độ thu gọn có xóa dấu cách trong nội dung văn bản không?

Nó không xóa mọi dấu cách trong nội dung, nhưng cũng không bảo đảm giữ mọi dấu cách có ý nghĩa. Quy tắc chỉ nhắm đến khoảng trắng nằm giữa hai thẻ, nên dấu cách bên trong một cụm văn bản thông thường thường không bị tác động. Ngược lại, dấu cách phân cách nội dung của hai phần tử liền nhau có thể bị loại bỏ. Với văn bản xen kẽ phần tử, hãy kiểm tra cách ứng dụng đích ghép và hiển thị nội dung thay vì chỉ nhìn chuỗi XML.

Công cụ có tự sửa thẻ thiếu hoặc thẻ đóng sai không?

Không. Công cụ kiểm tra trước khi định dạng và dừng tạo kết quả khi phát hiện lỗi, chứ không đoán thẻ còn thiếu hoặc đổi thẻ đóng cho khớp. Cách xử lý này tránh tự tạo một cấu trúc có thể khác ý định ban đầu. Bạn cần đối chiếu với nguồn dữ liệu hoặc cấu trúc mong muốn để sửa nội dung. Cũng cần lưu ý rằng vị trí trình duyệt báo lỗi có thể là nơi lỗi được phát hiện, không nhất thiết là nơi vấn đề bắt đầu.

Vì sao tôi không sao chép được kết quả?

Công cụ không thực hiện sao chép khi kết quả rỗng hoặc đang hiển thị lỗi. Nếu đã có kết quả, thao tác còn phụ thuộc API clipboard, quyền truy cập và điều kiện của môi trường trình duyệt. Vì vậy, không nên quy mọi lần thất bại cho một nguyên nhân duy nhất là trình duyệt không hỗ trợ. Mã có phản hồi khi thao tác sao chép thất bại, nhưng chưa có bằng chứng kiểm thử khả năng này trên từng môi trường. Hãy kiểm tra trạng thái kết quả trước khi đánh giá lỗi sao chép.

Có nên dán XML chứa mật khẩu hoặc dữ liệu cá nhân vào công cụ không?

Nên tránh dán dữ liệu nhạy cảm khi chưa xác minh chính sách và môi trường sử dụng của toàn trang. Đoạn xử lý được cung cấp dùng API trình duyệt và không thể hiện thao tác gửi XML qua mạng, nhưng điều đó không đủ để cam kết dữ liệu không được truyền hoặc lưu bởi thành phần khác. Cách thận trọng là dùng bản mẫu đã loại bỏ mật khẩu, mã truy cập và thông tin nhận dạng. Nếu cần xử lý bản thật, hãy chọn môi trường đã được đánh giá theo yêu cầu bảo vệ dữ liệu của bạn.