JSONとYAMLはマークアップ言語と見なされますか? [閉鎖]

JSONとYAMLはマークアップ言語と見なされますか? [閉鎖]

明日、Comp Tia Linux+(XK0-004)試験があります。 Amazonで「Compt Tia Linux + All in one Exam Guide」という本を購入しましたが、JSONとYAMLに関するGoogle検索と矛盾しました。

この本はCH 18 Reviewで次のように非常に明確に述べています。

JSONとYAMLは、データのシリアル化に使用できるマークアップ言語です。

YAMLは別のマークアップ言語(Another Markup Language)を意味します。

Stackoverflowの検索結果:

正確な引用YAMLを作成したと主張する貢献者の回答は+140です。:

「私たちが数ヶ月間一緒に働いた後、私はYAML(当時は確かにAnother Markup Languageを意味します)が実際にはマークアップ言語(テキスト文書のさまざまな要素をマークアップする)ではなく、シリアル化言語(タイプ化/循環データグラフのテキスト表現)私たちはどちらもYAMLという名前が好きだったので、名前をYAML Ai n't Markup Languageに変更しました。

ベストアンサー1

両方の技術について学ぶには、その仕様を読むことをお勧めします。

YAMLの人々が言うのは一般的に正しいです。表示言語などシンボルもののようなものの場合。 JSONの定義が問題を最もよく説明していると思います。

JSON(JavaScript Object Notation)は軽量データ交換形式です。

表示言語表示テキストなど。

マークアップ言語が完全なオブジェクト構造(HTMLやXMLなど)を定義するために頻繁に使用されるため、2つの間の区別があいまいになります。ただし、YAMLやJSONなどの言語は完全な構造のみを定義します(大きなオブジェクト構造の下位部分でも)。コレクションなど)、マークアップがドキュメントにまったくない可能性があります。 HTMLなどの場合、空の文書にはまだいくつかの構造が含まれています(たとえば、後で追加される制約のため)<html> <head> ... </head> <body> ... </body> </html>。技術的に言えば、タグがまったくないプレーンテキスト文書も有効なHTMLです。

もう一つの興味深いアプローチは値下げ、これは明らかにマークアップ言語であり、情報交換のためにオブジェクトなどの構造を定義するためにほとんど使用されません。一方、あなたはTOML(「Tom's Own Markup Language」)自分自身をマークアップ言語と呼びますが、明らかにそうではありません。

JSONがマークアップ言語として使用されているのを見たことはなく、TOMLも同様です。技術的には、YAMLはマークアップ言語として使用できますが、より良い解決策があるため、必ずしも必要ではありません。いくつかのマークアップ言語はある程度良いオブジェクト定義言語(XMLなど)を作成しますが、データ定義言語を使用したマークアップは一般的に悪い経験です。しかし、場合によっては、区別は通常非常にあいまいです。表示両方を実行する言語(HTMLなど)ある程度は、ユースケースによって異なります。レンダリング、ネットワーク通信など、注釈に主に使用される言語ですが、ここで主な焦点は注釈のないコンテンツなので、マークアップ言語です。

代わりに、実際のコンテンツが「文書」ではなく単にデータと見なされる場合、これはデータ定義言語などです。ドキュメントにタグがない場合、ドキュメントは破損せず、コンテンツはそのまま残り、クリーンアップ、読み取り、または解析が難しくなる可能性があります。

JSONなどのデータ定義言語でJSONなどの構造が欠落していてコンテンツ(プレーンテキストなど)が残っている場合、データセットは実際には存在せず、もはやJSONではありません。

私の考えでは、最大の誤った名前はXMLです。名前が示すように、マークアップ言語ですが、実際にはほとんど使用されず、代わりにデータシリアライゼーションにのみほとんど排他的に使用されます。そのため、名前に「マークアップ言語」という用語が間違って使用されることが多いようです。その理由は、おそらく(おそらくはわかりませんが)元の意図です。 XMLはもともと故意に「拡張可能なマークアップ言語」として、これは最終的にはデータのシリアライゼーションやオブジェクト表現などの目的にのみ使用されます。もう一つの理由は、マーケティングなどです。

最後に、この要約を引用したいと思います。YAML仕様 (私が強調したいくつかの言葉):

1.3。 JSONとの関係

JSONとYAMLの両方が人間が読めるデータを目指しています。交換形式。ただし、JSONとYAMLは優先順位が異なります。 JSONの最も重要な設計目標は、シンプルさと一般性です。したがって、JSONは生成と解析が簡単ですが、人間の読みやすさが低下するという欠点があります。また、最小共通分母情報モデルを使用して、最新のプログラミング環境ですべてのJSONデータを簡単に処理できるようにします。

対照的に、YAMLの最も重要な設計目標は、人間の読みやすさと任意の基本データ構造のシリアル化をサポート。したがって、YAMLを使用すると読みやすいファイルを生成できますが、生成と解析はより複雑です。さらに、YAML は最小共通分母データ型を超えているため、異なるプログラミング環境を横断する場合は、より複雑な処理が必要です。

したがって、YAMLは、人間の可読性の向上とより完全な情報モデルを提供するJSONの自然な親セットと見なすことができます。これは実際にも同じです。すべてのJSONファイルは有効なYAMLファイルでもあります。これにより、追加機能が必要な場合は、JSONからYAMLに簡単に移行できます。

[… ]

YAMLとJSONの間の中間形式を定義すると便利です。この形式はJSONのように解析するのは簡単ですが、人間が読むのは難しいです。同時に、YAMLなどの任意の基本データ構造を直列化できます。この形式はYAMLの「正規形式」としても使用できます。これらの「YSON」形式(YSONはシリアライズされたオブジェクト表記)を定義するには、JSON仕様を強化するか、YAML仕様を制限するだけです。そのような定義はこの仕様の範囲外です。

この段落には「マークアップ言語」という用語はありません。代わりに、これがどのように交換形式であり、データのシリアル化のために設計されているかについて言及します。最後のセクションでは、指定された要件に適している中間形式を作成する方法について説明します。これは、「マークアップ言語」と「マークアップ言語」との境界が明確ではなく、ある種の定義「灰色領域」があるというさらなる証拠である。


全体的に私は単に「Google検索」をするのではなく、その技術の定義を探し、その技術開発者の定義を読んでみてください。これで Google 検索ステップが完了しました。次に、該当する文書などをお読みください。

あなたの本が開発者が自分の技術や製品について話すのと矛盾している場合は、教科書が間違っている可能性があり、開発者や著者が定義したすべてが意味をなさない可能性があるため、どちらかを福音として受け入れないでください。疑わしい場合は、両方のスキルを見て、スキル自体の説明や教科書に記載されているものとどれだけ一致しているかを確認してください。一部の教科書の著者は、単に開発者の定義などを採用することもあります。

通常、少し広い定義を使用していつでも参照できます。 XMLとJSONは間違いなくオブジェクト表現であり、定義言語として使用できます。絵OGDL単に「順序グラフ定義言語」と呼ぶのは、XMLやJSONを含むツリー構造を使用するほとんどすべての言語の有効な説明です。

おすすめ記事