Việc sử dụng một cái gì đó không phải là XML có thể khuyên dùng cho tệp cấu hình của tôi không?

Tôi có một công cụ nhỏ mà tôi đang thiết kế sẽ yêu cầu một tệp cấu hình nào đó. Tệp cấu hình trong trường hợp của tôi thực sự là một cơ sở dữ liệu, nhưng nó cần phải gọn nhẹ và nếu cần, người dùng cuối sẽ dễ dàng chỉnh sửa nó. Tuy nhiên, nó cũng sẽ chứa rất nhiều thứ trong đó. (tùy thuộc vào các yếu tố nhất định, có thể là 1Mb trở lên)

Tôi đã quyết định tôi muốn sử dụng văn bản ol 'đơn giản hơn là cố gắng sử dụng SQLite hoặc một số thứ khác. Tuy nhiên, với việc sử dụng văn bản, tôi cũng phải đối phó với sự đa dạng của các định dạng. Cho đến nay, lựa chọn của tôi là

• XML
• JSON
• Định dạng tùy chỉnh

Dữ liệu trong tệp của tôi khá đơn giản bao gồm hầu hết các phần của loại khóa-giá trị. Vì vậy, một định dạng tùy chỉnh sẽ không khó lắm ... nhưng tôi không phải lo lắng về việc viết hỗ trợ cho nó. Tôi chưa bao giờ thấy JSON được sử dụng cho các tệp cấu hình. Và XML sẽ làm tăng kích thước tệp đáng kể tôi nghĩ. (Tôi cũng không thích XML nói chung).

Tôi nên làm gì trong trường hợp này?

Các yếu tố cần xem xét:

• Tập tin cấu hình này có thể được tải lên một dịch vụ web (vì vậy vấn đề kích thước)
• Người dùng phải có thể chỉnh sửa bằng tay nếu cần thiết (dễ dàng chỉnh sửa và đọc các vấn đề)
• Phải có khả năng tạo và xử lý tự động (tốc độ không thành vấn đề, nhưng không quá chậm)
• "Khóa" và "giá trị" là các chuỗi đơn giản, nhưng phải được thoát vì chúng có thể chứa bất cứ thứ gì. (unicode và thoát phải hoạt động dễ dàng)
• Nhiều tập tin cấu hình. Về cơ bản, mỗi tệp cấu hình được gắn với một "dự án"

tôi nghĩ YAML phù hợp nhất cho trường hợp của bạn. Theo hiểu biết của tôi, YAML là định dạng chuẩn thực tế cho các tệp cấu hình cần được chỉnh sửa bằng tay. Nhiều ngôn ngữ lập trình có một thư viện để đọc và / hoặc viết YAML. JSON có liên quan chặt chẽ với YAML, nhưng dễ viết hơn một chút so với YAML và được sử dụng nhiều hơn để liên lạc giữa máy chủ web và chương trình máy khách.

Nếu bạn sử dụng JSON, mọi người sẽ không thể nhận xét các bit cấu hình để thử những thứ khác nhau. Đối với tôi, đó là một công cụ thỏa thuận.

Điều đó cũng có nghĩa là bạn không thể cung cấp tệp cấu hình mẫu được nhận xét độc đáo để người dùng tùy chỉnh.

XML là tiêu chuẩn và nếu bạn có thể cung cấp một lược đồ, người dùng của bạn sẽ cảm ơn bạn.

Sau khi xem xét các yêu cầu của bạn và thấy rằng bạn không thích XML, tôi sẽ khuyên bạn nên dùng JSON. Tôi phải thừa nhận rằng tôi chỉ xử lý XML và JSON, vì vậy tôi không thể nói cho bất kỳ định dạng cấu hình phổ biến nào khác ngoài đó.

JSON thực sự dễ viết và nếu được định dạng chính xác, dễ đọc. Google chỉ YÊU THÍCH JSON để sử dụng cấu hình trong các công cụ của họ. Ngoài ra, JavaScript có thể biến nó thành các đối tượng nguyên bản.

Tệp "thuộc tính" tốt cho khóa / giá trị vì định dạng chính là khóa / giá trị. Nó chỉ đơn giản là 1 dòng trên mỗi khóa / giá trị. Dấu đầu tiên = trong dòng chia khóa và giá trị.

Nó sẽ nhỏ hơn một tệp XML tương đương vì định dạng duy nhất là dấu phân cách "=" và ký tự dòng mới. Trong một tệp XML, việc đánh dấu có thể chiếm nhiều dung lượng như chính nội dung đó. Nó có nghĩa đen là sự khác biệt giữa tải lên 1MB và 2MB. Nén giúp nhưng bạn vẫn đi trước nếu bạn bắt đầu nhỏ.

Thư viện hiện tại có thể xử lý truy cập vào các tập tin tài sản. Nhưng nó quá tầm thường, bạn có thể tự làm trong vài phút. Chuông và còi trong dưới một giờ.

IP=11.22.33.44
BuildNumber=5.02.004
MaxFrameRate=50

Một số câu trả lời tốt ở đây rồi. Nhưng nếu tôi ở vị trí của bạn, trước khi ném XML lên bảng, tôi sẽ xem xét các điểm sau:

• XML được hỗ trợ rất tốt bởi .NET framework và các công cụ của bên thứ ba, đối với JSON, bạn sẽ phải chọn thư viện của bên thứ ba và xem liệu nó có đáp ứng tất cả các yêu cầu của bạn không.

• nếu bạn chỉ cần chỉnh sửa thủ công cho một vài trường hợp đặc biệt, thì XML có thể sẽ chịu đựng nhu cầu của bạn. Nếu có rất nhiều chỉnh sửa phải được thực hiện và danh sách các tùy chọn cấu hình của bạn có độ phức tạp đặc biệt, thì người dùng của bạn rất có thể cần một loại ứng dụng tùy chọn / cấu hình dựa trên hộp thoại - điều đó có nghĩa là, định dạng XML cơ bản là 100 % thân thiện với người dùng. Nếu bạn không muốn viết một thứ như vậy, ít nhất bạn có thể giới thiệu một số loại trình soạn thảo XML cho người dùng của mình. Các công cụ như notepad XML hoặc các công cụ XML cho Notepad ++ hoạt động tốt cho nhiều người.

• Tôi đoán khả năng cao hơn là người dùng cuối của bạn đã thấy một số loại XML trước đó so với cơ hội mà họ đã thấy JSON trước đây - điều này sẽ giúp họ dễ dàng nắm bắt hơn một chút (nếu họ thực sự phải làm vậy)

• JSON không hỗ trợ các bình luận, điều này có thể khiến việc chỉnh sửa thủ công trở nên khó khăn

• nếu kích thước thực sự là một vấn đề khi tải dữ liệu lên dịch vụ web, hãy cân nhắc sử dụng nén dữ liệu

Thực tế, nếu bạn nghĩ về những điểm này và dù sao bạn cũng không muốn sử dụng XML, thì hãy đi với JSON thay thế. Sử dụng XML hoặc JSON cung cấp cho bạn các cách thoát chuỗi tiêu chuẩn, các cách mở rộng cấu trúc cấu hình tiêu chuẩn của bạn sau đó và các lib sẵn sàng để đọc và viết các định dạng đó - không cần phải phát minh lại bánh xe với bất kỳ "định dạng tùy chỉnh" nào.

Theo như các tập tin cấu hình, "1Mb trở lên" chắc chắn là về mặt lớn, và nhu cầu thoát chuỗi và duy trì nhiều trích dẫn phù hợp không chơi tốt với con người. Đó là lý do tại sao đối với các tệp cấu hình lớn cần được duy trì bởi con người, bạn chắc chắn nên xem xét việc xác định định dạng tùy chỉnh và xây dựng trình phân tích cú pháp tùy chỉnh. Đây là một bài viết về chủ đề con người phải viết XML: Con người không cần phải mò mẫm XML .

Khi trình phân tích cú pháp và trình tạo trình phân tích cú pháp còn ở giai đoạn sơ khai, bạn có thể tạo ra một trường hợp không xây dựng một tùy chỉnh bằng cách nói rằng việc xây dựng một ngôn ngữ tùy chỉnh là quá phức tạp. Bây giờ các trình tạo trình phân tích cú pháp đơn giản và tuyệt vời đã hoàn thiện, không có lý do gì: bạn có thể xây dựng trình phân tích cú pháp tùy chỉnh trong vài giờ, ngang với thời gian bạn sẽ xây dựng trình phân tích cú pháp cho ngôn ngữ dựa trên XML ^* .

Dưới đây là một hướng dẫn nhỏ giải thích quá trình xây dựng trình phân tích cú pháp tùy chỉnh với ANTLR . Nó có trong Java, nhưng ANTLR cũng hỗ trợ C #.

JSON là một lựa chọn tốt vì tính linh hoạt, dễ đọc và chỉnh sửa bên ngoài chương trình của bạn, có sẵn nhiều thư viện phân tích cú pháp để hỗ trợ nó. Nó hỗ trợ phân cấp, cho phép khả năng tương thích tiến / lùi đơn giản mà một tệp chỉ lưu dữ liệu theo trình tự không có. Tôi nghĩ rằng nó cũng có các kỹ thuật dễ dàng để chuyển đổi giữa các lớp Java và dữ liệu tệp và sau đó ngược lại. Rất nhiều người biết và đã mã hóa cho định dạng này, và định dạng này rất quan trọng đối với các chương trình khác mà bạn có thể sẽ cần phải làm việc trong tương lai.

Nhiều hệ thống dựa trên định dạng .ini và chúng khá dễ phân tích nếu bạn đang viết một trình phân tích cú pháp từ đầu.

csv có thể nhanh chóng viết mã và hoạt động với rất ít chi phí, nhưng có vấn đề với tính linh hoạt, khả năng tương thích tiến / lùi.

Sử dụng sổ đăng ký là một cách phổ biến trong Windows.

Sử dụng cookie là phổ biến để phát triển web.

Đối với một hàm tiện ích, có thể chỉ cần sử dụng văn bản định dạng miễn phí phù hợp với các tùy chọn dòng lệnh của bạn, chỉ cần đọc nó và tạo một chuỗi chuỗi argv từ nó.

Đừng sử dụng XML.

XML là một ngôn ngữ đánh dấu. Khi được sử dụng để tuần tự hóa hoặc ngôn ngữ cấu hình, XML có một vấn đề cơ bản, đó là các thuộc tính và nội dung văn bản của một phần tử có thể mô tả cùng một thứ. Bạn cần phải quyết định giữa các thuộc tính và nội dung văn bản. Hơn nữa, XML là dài dòng không cần thiết, ví dụ như chỉ định tên thành phần hai lần (mở, đóng).

Sử dụng XML cho ý nghĩa của nó: như một ngôn ngữ đánh dấu. Các tập tin cấu hình không yêu cầu ngôn ngữ đánh dấu.

Đừng sử dụng JSON.

JSON là tuyệt vời như định dạng tuần tự hóa dữ liệu. Tuy nhiên, JSON thiếu bình luận. Điều đó, với tôi, là một công cụ thỏa thuận. Hơn nữa, bạn cần phải thoát khỏi tất cả các lần xuất hiện của "nhân vật.

Đừng sử dụng INI.

Các tệp INI có một vấn đề cơ bản: chúng thiếu các cấu trúc dữ liệu lồng nhau. Khái niệm duy nhất về lồng nhau là một thẻ có thể có một số thuộc tính. Đó chỉ là 1 cấp độ làm tổ. Trong các trường hợp sử dụng thực tế, tôi đã thấy hạn chế này vô cùng khó chịu. Tôi đã làm việc như một phần của dự án trong đó cấu hình nằm trong các tệp INI và các cơn đau là chủ yếu.

Sử dụng ngôn ngữ tùy chỉnh nếu khả thi.

Nếu bạn có quyền truy cập vào các công cụ tạo trình phân tích cú pháp như Lex & Yacc, hãy sử dụng ngôn ngữ tùy chỉnh. Tôi không chắc trạng thái của trình tạo trình phân tích cú pháp trên .NET, nhưng đối với mã C, tôi sẽ chọn Lex & Yacc. Thời gian học ban đầu có thể hơi dốc (Lex & Yacc không phải là công cụ dễ sử dụng nhất), nhưng thời gian đầu tư cho việc học là hoàn toàn xứng đáng.

Nếu ngôn ngữ tùy chỉnh không khả thi, hãy sử dụng YAML.

Y AML, như tên gọi của mình, một in't m arkup l anguage. Đó là một ngôn ngữ tuần tự hóa xảy ra do các thuộc tính của nó được chấp nhận cho các tệp cấu hình, vì nó hỗ trợ các bình luận. YAML không cần dài dòng như XML: nó không yêu cầu chỉ định tên thành phần hai lần (mở, đóng). YAML không có vấn đề thuộc tính so với nội dung văn bản của XML.

Hãy xem xét pro.per.ty = giá trị là tốt.

Nếu bạn muốn cấu hình giống INI, trong đó lồng nhau được hỗ trợ, hãy xem xét một định dạng bao gồm các pro.per.ty=valuecặp (cặp giá trị khóa), trong đó khóa có thể có một số mức lồng nhau, sử dụng .ký tự làm dấu phân cách.