Các lựa chọn thay thế JSON (cho mục đích chỉ định cấu hình)?

Question

Tôi thích json dưới dạng định dạng cho các tệp cấu hình cho phần mềm tôi viết. Tôi thích nó nhẹ, đơn giản và được hỗ trợ rộng rãi. Tuy nhiên, tôi thấy rằng có một số điều tôi thực sự thích trong json rằng nó không có.

Json không có nhiều chuỗi hoặc tài liệu ở đây (http://en.wikipedia.org/wiki/Here_document) và thường rất khó xử khi bạn muốn tệp json của mình trở nên dễ đọc và có thể chỉnh sửa được. Bạn có thể sử dụng mảng của chuỗi, nhưng đó là một cách giải quyết kludgy.

Json không cho phép nhận xét.

Nếu bạn nhìn vào các định dạng của tệp cấu hình unix, bạn sẽ thấy rất nhiều người thiết kế các định dạng khó xử của riêng mình cho những thứ thực sự sử dụng một số loại mục đích chung. Ví dụ, đây là một số mã từ một tập tin cấu hình Apache:

RewriteEngine on 
RewriteBase /temp 
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml 
RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml\s*;\s*q=0 
RewriteCond %{REQUEST_URI} \.html 
RewriteCond %{THE_REQUEST} HTTP/1\.1 
RewriteRule t\.html t.xhtml [T=application/xhtml+xml] 

Về cơ bản, những gì đang xảy ra ở đây là họ đã phát minh ra một cách vô cùng đau đớn của việc viết một hàm boolean f (w, x, y, z) = w &! x & y & z. Bạn muốn có một "hoặc" hợp lý? Họ cũng có một cơ chế riêng biệt (xấu xí) cho điều đó.

Điều này dường như chỉ ra là một số loại ngôn ngữ mô tả dữ liệu đơn giản và không đầy đủ, nhưng vẫn biểu cảm hơn, linh hoạt và thuận tiện hơn so với json. Có ai biết ngôn ngữ như vậy không?

Theo sở thích của tôi, XML quá phức tạp và biểu thức lisp có tính năng sai (Turing-completeeness) và thiếu các tính năng phù hợp (ở đây tài liệu, cú pháp biểu cảm).

[EDIT] Tiêu đề gây hiểu lầm. Tôi không thực sự quan tâm đến sự lặp lại tiếp theo của json. Tôi không quan tâm đến các ngôn ngữ là một tập con của javascript. Tôi quan tâm đến các ngôn ngữ mô tả dữ liệu thay thế.

Answer 1

Chữ 'J' trong JSON là "Javascript". Nếu một cú pháp cụ thể mong muốn xây dựng không phải là trong Javascript, sau đó nó sẽ không được trên JSON.

Heredocs nằm ngoài tầm nhìn của JSON. Đó là cấu trúc cú pháp ngôn ngữ cho định nghĩa chuỗi nhiều dòng được đơn giản hóa, nhưng JSON là ký pháp vận chuyển. Nó không có gì để làm với xây dựng. Tuy nhiên, nó có chuỗi nhiều dòng, chỉ đơn giản bằng cách cho phép \n ký tự dòng mới trong chuỗi. Không có gì trong JSON nói rằng bạn không thể có một dòng trong một chuỗi. Miễn là các ký tự trích dẫn có chứa là chính xác, nó hoàn toàn hợp lệ. ví dụ.

{"x":"y\nz"} 

là 100% hợp pháp JSON hợp lệ, và là một chuỗi multiline, trong khi

{"x":"y 
z"} 

không và sẽ thất bại trên phân tích cú pháp.

Answer 2

Luôn có những gì tôi muốn gọi là "JSON thực". JSON là viết tắt của JavaScript Object Notation và JavaScript hiện có các nhận xét và một cái gì đó đủ gần với heredocs.

Đối với heredoc, bạn sẽ sử dụng E4X inline XML JavaScript của:

{ 
    longString: <> 
       Hello, world! 
       This is a long string made possible with the magic of E4X. 
       Implementing a parser isn't so difficult. 
       </>.toString() // And a comment 
    /* And another 
     comment */ 
} 

Bạn có thể sử dụng công cụ JavaScript của Firefox (FF là trình duyệt duy nhất để hỗ trợ E4X hiện tại) hoặc bạn có thể thực hiện phân tích cú pháp của riêng mình, mà thực sự không quá khó.

Here's the E4X quickstart guide, too.

Answer 3

Một thuộc tính quan trọng của JSON (có lẽ là quan trọng nhất) là bạn có thể dễ dàng "lật" giữa đại diện chuỗi và các đại diện ở dạng đối tượng, và các đối tượng sử dụng để đại diện cho hình thức đối tượng là tương đối các mảng và bản đồ đơn giản. Đây là điều làm cho JSON trở nên hữu ích trong ngữ cảnh mạng.

Các chức năng bạn muốn sẽ xung đột với bản chất kép của JSON này.

Answer 4

EDN format là một tùy chọn dựa trên chữ cái Clojure. Nó gần như là một siêu của JSON, ngoại trừ việc không có ký hiệu đặc biệt nào tách các khóa và giá trị trong các bản đồ (như : thực hiện trong JSON); thay vào đó, tất cả các phần tử được phân tách bằng khoảng trắng và/hoặc dấu phẩy và bản đồ được mã hóa dưới dạng danh sách có số phần tử chẵn, được đính kèm trong {..}.

EDN cho phép nhận xét (cho dòng mới sử dụng ; hoặc để kết thúc phần tử tiếp theo đọc bằng cách sử dụng #_), nhưng không phải tài liệu ở đây. Nó có thể mở rộng với các loại mới sử dụng một thẻ ký hiệu:

#myapp/Person {:first "Fred" :last "Mertz"} 

Đối số của thẻ myapp/Person (ví dụ: {:first "Fred" :last "Mertz"}) phải là một biểu hiện EDN hợp lệ, mà làm cho nó unextensible để hỗ trợ ở đây-doc.

Thẻ có hai thẻ được gắn sẵn: #inst cho dấu thời gian và #uuid. Nó cũng hỗ trợ các ký hiệu không gian tên (nghĩa là từ định danh) và từ khóa (tức là các khóa bản đồ); nó phân biệt danh sách (..) và vectơ [..]. Một phần tử của bất kỳ loại nào có thể được sử dụng làm khóa trong bản đồ.

Trong ngữ cảnh của vấn đề trên, người ta có thể phát minh ra một thẻ #apache/rule-or chấp nhận một chuỗi các phần tử có ngữ nghĩa mà tôi để lại cho bạn!

Answer 5

Đối với cấu hình bạn có thể sử dụng ngôn ngữ kịch bản có thể nhúng, chẳng hạn như lua hoặc python, trên thực tế, đây không phải là điều không bình thường để làm cho cấu hình. Điều đó cung cấp cho bạn chuỗi nhiều dòng hoặc tài liệu ở đây và nhận xét. Nó cũng giúp dễ dàng có những thứ như hàm boolean mà bạn mô tả. Tuy nhiên, ngôn ngữ kịch bản là, tất nhiên, Turing hoàn thành.

Answer 6

Hãy xem http://igagis.github.io/stob/

Nó thậm chí còn đơn giản hơn JSON.

Nó có nhận xét kiểu C++.

Có thể định dạng chuỗi nhiều dòng và sử dụng ký tự dòng \ n mới và tab \ t thoát nếu cần dòng hoặc tab mới "thực".

Dưới đây là đoạn mã ví dụ:

"String object" 
AnotherStringObject 
"String with children"{ 
    "child 1" 
    Child2 
    "child three"{ 
     SubChild1 
     "Subchild two" 

     Property1 {Value1} 
     "Property two" {"Value 2"} 
     //comment 

     /* multi-line 
      comment */ 

     "multi-line 
     string" 

     "Escape sequences \" \n \r \t \\" 
    } 

R"qwerty(
This is a 
raw string, "Hello world!" 
int main(argc, argv){ 
    int a = 10; 
    printf("Hello %d", a); 
} 
)qwerty" 
}