28

私にとって使用可能なことは次のことを意味します：

  • リアルワールドで使われている
  • ツールのサポートがあります。(少なくともいくつかの単純なエディター)
  • 人間が読める構文を持っています（山括弧は使用しないでください）

また、可能な限り XML に近いものにしたいと考えています。つまり、プロパティだけでなく属性もサポートする必要があります。したがって、YAMLは使用しないでください。現在、一致する言語はJSONの 1 つだけです。他の代替手段を知っていますか？

4

14 に答える 14

55

YAMLはJSONの100％スーパーセットであるため、YAMLを拒否して代わりにJSONを検討することは意味がありません。YAMLはJSONが行うすべてのことを行いますが、YAMLは（参照のように）さらに多くのことを行います。

私の経験ではオーバーヘッドの価値がなかったDTDを使用してドキュメントを検証することを除いて、YAMLができないXMLでできることは何も考えられません。しかし、YAMLはXMLよりもはるかに高速で、入力と読み取りが簡単です。

属性やプロパティに関しては、考えてみれば、実際には何も「追加」されません...それは、ノードの子ノードに配置するのではなく、ノードの属性として何かを記述するための単なる表記上のショートカットです。ただし、その便利さが気に入った場合は、YAMLのインラインリスト/ハッシュを使用してエミュレートできることがよくあります。例えば：

<!-- XML -->
<Director name="Spielberg">
    <Movies>
        <Movie title="Jaws" year="1975"/>
        <Movie title="E.T." year="1982"/>
    </Movies>
</Director>


# YAML
Director: 
    name: Spielberg
    Movies:
      - Movie: {title: E.T., year: 1975}
      - Movie: {title: Jaws, year: 1982}

私にとっては、各ノードタグを2回書き込む必要がないという贅沢と、すべての山かっこで囲まれたゴミからの解放が相まって、YAMLが好ましい選択肢となっています。また、正式なタグ属性がないことも実際に気に入っています。これは、本質的に同じ概念に対して2セットの構文（書き込み時とトラバース時の両方）を不必要に導入したXMLの灰色の領域のように常に思えたためです。YAMLはその混乱を完全に取り除きます。

于 2010-04-02T16:53:50.263 に答える
13

JSONは非常に優れた代替手段であり、そのためのツールが複数の言語で提供されています。また、ネイティブの JavaScript であるため、Web クライアントでの使用は非常に簡単です。

于 2008-09-09T09:56:13.673 に答える
8

TL;DR

Prolog はここでは言及されていませんが、データを表現するための私が知っている最良の形式です。Prolog プログラムは基本的に、エンティティ間の複雑な関係を持つデータベースを記述します。Prolog は非常に簡単に解析でき、おそらく唯一のライバルはこのドメインの S 式です。

完全版

プログラマーは、XML が実際に構成されているものを「忘れる」ことがよくあります。通常、それが何であるかの非常に小さなサブセットを指します。XML は非常に複雑な形式であり、少なくともDTD スキーマ言語、XSD スキーマ言語、XSLT 変換言語、RNG スキーマ言語、およびXPath (および XQuery) 言語の一部を備えています。これらはすべて XML 標準の一部です。さらに、 E4Xのような外典もいくつかあります。それらのそれぞれには独自のバージョンがあり、かなりの重複、非互換性などがあります。実際にそれらすべてを実装している XML パーサーはほとんどありません。人気のある解析の複数の癖やバグは言うまでもなく、いくつかは次のような顕著なセキュリティ問題につながりますhttps://en.wikipedia.org/wiki/XML_external_entity_attack .

したがって、XMLの代替を探すのはあまり良い考えではありません。おそらく、XML のようなものはまったく扱いたくないでしょう。

YAML は、おそらく 2 番目に悪いオプションです。XML ほど大きくはありませんが、すべてのベースをカバーするように設計されています... それぞれ 10 回以上... 誰も思いつかなかったさまざまなユニークな方法で。適切に動作する YAML パーサーについてはまだ聞いていません。YAML を多用する言語である Ruby は、YAML が原因で失敗したことで有名です。これまでに見た YAML パーサーはすべてlibyamlのコピーです、それ自体が手書きの (正式な記述から生成されたものではない) 種類のパーサーであり、コードの正確性を検証するのが非常に困難です (複雑な制御フローで数百行にまたがる関数)。すでに述べたように、JSON が完全に含まれています...いくつかの Unicode コーディング手法に加えて...同じドキュメント内にあり、おそらく聞きたくない他のものがたくさんあります。

一方、JSON は他の 2 つとはまったく異なります。おそらく、Maven Nexus から JSON パーサー アーティファクトをダウンロードするのを待っている間に、JSON パーサーを作成できます。できることはほとんどありませんが、少なくとも何ができるかはわかっています。驚く様な事じゃない。(文字列での文字エスケープと double エンコーディングに関連するいくつかの不一致を除く)。秘密のエクスプロイトはありません。コメントを書き込むことはできません。複数行の文字列は見た目が悪いです。プロパティと属性の区別によって意味するものは何でも、より多くのネストされた辞書で実装できます。

XML が間違っていたことを正したいと思ったとしても、YAML や JSON などの一般的なものではそれができません。どういうわけか、70 年代半ばのある時点で、ファッションと合理的思考がプログラミングに分かれました。したがって、マッカーシー、ホーア、コッド、コワルスキーですべてが始まった場所に戻り、何を表現しようとしているのかを理解し、自分が何であろうと、そこにある最良の表現手法を確認する必要があります。表現しようとしています:)

于 2016-08-19T09:19:13.107 に答える
6

S 式は、構造化されたデータを表現する優れた方法であることがわかりました。これは、生成と解析が容易な非常に単純な形式です。属性はサポートしていませんが、YAML や JSON と同様に、その必要はありません。属性は、XML が冗長性を制限するための手段にすぎません。よりシンプルでクリーンなフォーマットでは、それらは必要ありません。

于 2011-04-11T15:03:57.323 に答える
5

Jeff はこれについてこことここに書いています。それはあなたが始めるのに役立つはずです。

于 2008-09-09T10:17:59.300 に答える
4

あなたの要求は少し不可能です。XML に近いものが必要ですが、山かっこ (YAML) を持たない最も近い同等のものをおそらく拒否します。

私はそれが好きではありませんが、なぜ XML を使用しないのでしょうか? 実際に XML を読む必要はありません (デバッグは別として)。そのためのツールがばかげたほどたくさんあります。

XML 以外のほとんどのものは広く使用されないため、サポートされるツールは少なくなります。

JSONはおそらくほぼ同等ですが、ほとんど同じように読めません..しかし、繰り返しますが、実際に読む必要はありません(使用している言語にロードし、ネイティブ配列/辞書/変数/に変換する必要があります)なんでもいい）。

ああ、JSONは XML よりも解析しやすいと思います。Javascript とsimplejson Python モジュールで使用しました。約 1 つのコマンドで、ネイティブの Python dict または Javascript オブジェクトに適切に変換されます (したがって、名前が付けられます!)。

于 2008-09-09T10:20:41.150 に答える
4

XML と JSON の長所をカバーするAXONがあります。いくつかの例でそれを説明しましょう。

AXON は、短い形式の XML データと見なすことができます。

XML

<person>
   <name>Frank Martin</name>
   <age>32</age>
 </person>

アクソン

person{
  name{"Frank Martin"}
  age{32}}

また

person
  name:
    "Frank Martin"
  age:
    32

XML

<person name="Frank Martin" age="32" />

アクソン

person{name:"Frank Martin" age:32}

また

person
  name: "Frank Martin"
  age: 32

AXON には何らかの形式の JSON が含まれています。

JSON

{"name":"Frank Martin" "age":32 "birth":"1965-12-24"}

アクソン

{name:"Frank Martin" age:32 birth:1965-12-24}

AXON は、XML に似たデータと JSON に似たデータの組み合わせを表すことができます。

アクソン

table {
  fields {
    ("id" "int") ("val1" "double") ("val2" "int") ("val3" "double")
  }
  rows {
    (1 3.2 123 -3.4)
    (2 3.5 303 2.4)
    (3 2.3 235 -1.2)
  }
}

また

table
  fields
    ("id" "int")
    ("val1" "double")
    ("val2" "int") 
    ("val3" "double")
  rows
    (1 3.2 123 -3.4)
    (2 3.5 303 2.4)
    (3 2.3 235 -1.2)

python ライブラリpyaxonが利用可能になりました。

于 2015-05-09T20:48:59.843 に答える
3

JSONをお勧めします...しかし、すでに言及したので、Googleプロトコルバッファーをご覧ください。

編集：プロトコルバッファはプログラムで使用するように作られているため（c ++、java、python ...のバインディングがあります）、目的に合わない場合があります。

于 2008-09-09T09:58:21.593 に答える
2

Clearsilverは非常に優れた代替品だと思います。ここには比較ページとそれを使用するプロジェクトのリストもあります

于 2008-09-09T09:59:22.183 に答える
1

山かっこにアレルギーがある場合は、JSON、HDF (ClearSilver)、およびOGDLだけが私が直接知っているものです。

少しグーグルで調べた後、ここで代替案のリストも見つけました：
http://web.archive.org/web/20060325012720/www.pault.com/xmlalternatives.html

于 2008-09-09T10:38:56.860 に答える
0

AFAIK、JSON、および YAML は、データ構造に関してまったく同じです。YAML には括弧や引用符などが少ないだけです。ですから、あなたが一方を拒否してもう一方を保持している方法がわかりません。

また、XML の山かっこが、JSON の角かっこ、中かっこ、および引用符よりも「人間が読める」ものではないこともわかりません。

于 2008-09-09T10:53:37.450 に答える
0

XML に代わるものは本当にたくさんありますが、それらの多くの主な問題は、選択したすべての言語でライブラリを利用できるとは限らず、ライブラリを実装するのに比較的手間がかかることです。

ハッシュテーブルなどのキーと値のペアと比較すると、ツリー構造自体の解析はそれほど快適ではないかもしれません。ハッシュ テーブル インスタンスが、そのすべてのキーが文字列であり、そのすべての値が文字列であるという要件を満たしている場合、hashtable2string() および string2hashtable() を実装するのは比較的簡単です。

私は、PHP と JavaScript の間で AJAX でハッシュ テーブルのシリアル化を使用してきました。私が開発した形式は、ProgFTE (Programmer Friendly text Exchange) と呼ばれ、次の場所で説明されています。

http://martin.softf1.com/g/n//a2/doc/progfte/index.html

Kibuvits Ruby ライブラリの一部として、ProgFTE 実装の Ruby バージョンを見つけることができます: http://rubyforge.org/projects/kibuvits/

于 2011-08-02T07:06:45.023 に答える