| ファイル名拡張子 | .yaml、.yml |
|---|---|
| インターネットメディアの種類 | application/yaml[1] |
| 統一型識別子 (UTI) | パブリック.yaml [2] |
| 初回リリース | 2001年5月11日 |
| 最新リリース | 1.2 (リビジョン 1.2.2) 2021年10月1日 |
| フォーマットの種類 | データ交換 |
| オープンフォーマット? | はい |
| Webサイト | yaml.org |
YAML ( / ˈ j æ m ə l / ( § 歴史と名前を参照)は、人間が読める データシリアル化言語。設定ファイル、拡張マークアップ言語と同じ通信アプリケーションの多くを対象としています標準汎用マークアップ言語とは異なる最小限の構文を持っています。[3]入れ子を示すためにPython使用し[3]、ほとんどの文字列値を引用符で囲む必要はありません(JSONスタイル[...]と{...}混合もサポートしています)。[4]
カスタムデータ型も使用できますが、 YAML はスカラー(文字列、整数、浮動小数点数など)、リスト、連想配列(マップ、辞書、ハッシュとも呼ばれる) をネイティブにエンコードします。これらのデータ型はPerlプログラミング言語に基づいていますが、一般的に使用されている高水準プログラミング言語はすべて非常によく似た概念を共有しています。[5] [6] [7]キーと値のペアを表現するために使用されるコロンを中心とした構文は、 RFC 822 で定義されている電子メールヘッダーにヒントを得ており 、ドキュメント セパレーターはMIME ( RFC 2046 )から借用しています。エスケープ シーケンスはCから再利用され、複数行の文字列の空白の折り返しはHTMLにヒントを得ています。リストとハッシュにはネストされたリストとハッシュを含めることができ、ツリー構造を形成します。任意のグラフはYAML エイリアスを使用して表現できます ( SOAPの XML に似ています)。[3] YAML はストリームでの読み取りと書き込みを目的としており、これはSAXにヒントを得た機能です。[3] ---
YAMLの読み書きのサポートは、多くのプログラミング言語で利用可能です。[8] Vim、[9] Emacs、[10]などの一部のソースコードエディタや、さまざまな統合開発環境[11] [12] [13]には、ネストされた構造を折りたたんだり、構文エラーを自動的に強調表示したりするなど、YAMLの編集を容易にする機能があります。
YAMLファイルのファイル名拡張子は.yaml2006年から公式に推奨されています。 [14] 2024年にはMIMEタイプ application/yamlが確定しました。[1]
歴史と名前
YAML(/ ˈ j æ m əl /、camel [4]と韻を踏む)は、 Clark Evans [15]によって2001年に初めて提案され、 Ingy döt Net [16]および Oren Ben-Kiki [16]と共に設計されました。 もともと YAML はYet Another Markup Language [17]を意味すると言われていました。これは、プレゼンテーションと接続性のためのマークアップ言語(HTML、XML、SGMLなど)が急増した時代にリリースされたためです。 当初の名前は、テクノロジーの状況に対する皮肉な言及[18]として意図されており、 yet another構造を持つマークアップ言語としての目的を示していましたが、その後、ドキュメントマークアップではなくデータ指向としての目的を区別するために、再帰的な頭字語であるYAML Ain't Markup Languageとして再利用されました。
バージョン
デザイン
構文
チートシートと完全な仕様は公式サイトで公開されています。[19]以下は基本的な要素の概要です。
YAMLは、一部の制御文字を除くUnicode文字セット全体を受け入れ、UTF-8、UTF-16、UTF-32のいずれかでエンコードできます。(UTF-32は必須ではありませんが、パーサーがJSON互換性を持つためには必要です。)[20]
- 空白の インデントは構造を示すために使用されますが、タブ文字はそのインデントの一部として許可されていません。[21]
- コメントは番号記号( )で始まり
#、行のどこからでも開始でき、行末まで続きます。コメントは空白文字で他のトークンと区切る必要があります。[22] 文字列内に#文字が現れた場合、それは番号記号(#)リテラルです。 - リストのメンバーは先頭にハイフン( )が付き
-、1 行に 1 つのメンバーが表示されます。 - 連想配列のエントリは、コロンと スペースを使用して、キー: 値の形式で1 行に 1 つのエントリとして表されます。YAML では、コロンの後にスペースが続く必要があるため、URL スタイルの文字列を
http://www.wikipedia.org引用符で囲まなくても表すことができます。 - 文字列(YAML のスカラーの 1 つのタイプ) は通常は引用符で囲みませんが、二重引用符(
") または一重引用符( )で囲むことができます'。- 二重引用符内では、バックスラッシュ( ) で始まるC スタイルのエスケープ シーケンスを使用して特殊文字を表すことができます。ドキュメントによると、サポートされている唯一の 8 進エスケープは です。
\\0 - 一重引用符内でサポートされる唯一のエスケープ シーケンスは、
''一重引用符自体を表す二重一重引用符 ( ) です ( を参照)'don''t'。
- 二重引用符内では、バックスラッシュ( ) で始まるC スタイルのエスケープ シーケンスを使用して特殊文字を表すことができます。ドキュメントによると、サポートされている唯一の 8 進エスケープは です。
- ブロック スカラーは、オプションの修飾子を使用してインデントで区切られ、改行を保持する (
|) か折りたたむ (>) かを指定できます。 - 1 つのストリーム内の複数のドキュメントは、3 つのハイフン(
---) で区切られます。- 3 つのピリオド(
...) は、必要に応じてストリーム内のドキュメントを終了します。
- 3 つのピリオド(
- 繰り返されるノードは、最初はアンパサンド( )で示され、その後はアスタリスク( )
&で参照されます。* - ノードには、二重感嘆符( ) とそれに続く文字列を使用してタイプまたはタグのラベルを付けることができ
!!、この文字列は URI に展開できます。 - ストリーム内の YAML ドキュメントの前には、パーセント記号(
%) とそれに続く名前およびスペースで区切られたパラメータで構成される「ディレクティブ」が付く場合があります。YAML 1.1 では 2 つのディレクティブが定義されています。- %YAML ディレクティブは、特定のドキュメント内の YAML のバージョンを識別するために使用されます。
- %TAG ディレクティブは、URI プレフィックスのショートカットとして使用されます。これらのショートカットは、ノード タイプ タグで使用できます。
基本コンポーネント
従来のブロック形式では、リスト内の新しい項目を開始するためにハイフンとスペースが使用されます。
--- # 好きな映画-カサブランカ-北北西に進路を取れ-そこにいなかった男
オプションのインライン形式はカンマ+スペースで区切られ、括弧で囲まれます(JSONと同様)。[23]
--- # 買い物リスト[牛乳、パンプキンパイ、卵、ジュース]
キーはコロン + スペースで値から区切られます。YAML データ ファイルで一般的なインデント ブロックでは、インデントと改行を使用してキー/値のペアを区切ります。YAML データ ストリームで一般的なインライン ブロックでは、カンマ + スペースを使用して中括弧内のキー/値のペアを区切ります。
--- # インデントされたブロックname : John Smith age : 33 --- # インラインブロック{ name : John Smith , age : 33 }
文字列には引用符は必要ありません。複数行の文字列を記述する方法は 2 つあります。1 つは改行を保持する方法 (|文字を使用)、もう 1 つは改行を折りたたむ方法 (>文字を使用) で、どちらの場合もその後に改行文字が続きます。
データ: |昔、イーリング出身の背の高い男がいました。ダージリン行きのバスに乗りました。ドアに「床に座らないでください」と書いてあったので、彼は慎重に天井に座りました。
デフォルトでは、先頭のインデント (最初の行) と末尾の空白は削除されますが、他の動作を明示的に指定することもできます。
データ: >折り返されたテキストは1つの段落に折り返されます
空白行は
段落区切りを示す
折り畳まれたテキストは改行をスペースに変換し、先頭の空白を削除します。
--- # スミス一家- {名前:ジョン・スミス、年齢: 33 } -名前:メアリー・スミス、年齢: 27 - [名前、年齢]: [レイ・スミス、4 ] # キーとしてのシーケンスがサポートされています--- # 人物、性別別男性: [ジョン・スミス、ビル・ジョーンズ]女性: -メアリー・スミス-スーザン・ウィリアムズ
オブジェクトとリストは yaml の重要なコンポーネントであり、混在させることができます。最初の例は、Smith 家の全員を表すキー値オブジェクトのリストです。2 番目の例は、性別別にリストしたもので、2 つのリストを含むキー値オブジェクトです。
高度なコンポーネント
YAMLを他のデータシリアル化言語の機能と区別する2つの機能は、構造[24]とデータ型です。
YAML構造により、1つのファイル内に複数の文書を保存したり、繰り返しノードへの参照を使用したり、任意のノードをキーとして使用したりすることが可能になる。[24]
明確さ、簡潔さ、およびデータ入力エラーの回避のために、YAML はノード アンカー ( を使用&) と参照 ( を使用*) を提供します。アンカーへの参照は、すべてのデータ型で機能します (以下の例の ship-to 参照を参照)。
以下は、完全に記述されずに 2 つのステップが参照されるインストゥルメント シーケンサーのキューの例です。
--- # レーザー眼科手術のシーケンサー プロトコル-ステップ: &id001 # アンカー ラベル &id001 を定義します。機器: Lasik 2000パルスエネルギー: 5.4パルス期間: 12繰り返し: 1000スポット サイズ: 1mm
-ステップ: &id002機器: Lasik 2000パルスエネルギー: 5.0パルス継続時間: 10繰り返し: 500スポットサイズ: 2mm -機器1 : *id001 # 最初のステップを参照します (アンカー &id001 を使用) -機器2 : *id002 # 2 番目のステップを参照します
YAML は単純な型を自動検出するため、明示的なデータ型指定はほとんどの YAML ドキュメントではほとんど見られません。データ型は、コア、定義済み、ユーザー定義の 3 つのカテゴリに分類できます。コアは、どのパーサーにも存在すると予想されるデータ型です (例: float、int、文字列、リスト、マップなど)。バイナリ データなどのより高度なデータ型は、YAML 仕様で定義されていますが、すべての実装でサポートされているわけではありません。最後に、YAML は、ユーザー定義のクラス、構造体、またはプリミティブ (例: 4 倍精度浮動小数点数) に対応するために、データ型定義をローカルに拡張する方法を定義します。
YAML はエンティティのデータ型を自動検出しますが、データ型を明示的にキャストしたい場合もあります。最も一般的な状況は、数値、ブール値、またはタグのように見える単語 1 つの文字列を引用符で囲むか、明示的なデータ型タグを使用して曖昧さを解消する必要がある場合です。
---
a : 123 # 整数b : "123" # 引用符で区別される文字列c : 123.0 # 浮動小数点数d : !!float 123 # 明示的なデータ型でプレフィックスが (!!) であるため浮動小数点数でもあるe : !!str 123 # 明示的な型によって区別される文字列f : !!str Yes # 明示的な型による文字列g : Yes # ブール値 True (yaml1.1)、文字列 "Yes" (yaml1.2) h : Yes we have No bananas # コンテキストによって区別される文字列 "Yes" と "No"。
YAML のすべての実装に、仕様で定義されたすべてのデータ型があるわけではありません。これらの組み込み型は、二重感嘆符の接頭辞 ( ) を使用します。特に興味深いのは、ここに示されていないセット、順序付きマップ、タイムスタンプ、および 16 進数です。以下は、 base64でエンコードされたバイナリ データ
!!の例です。
---
画像: !!バイナリ| R0lGODdhDQAIAIAAAAAAANn Z2SwAAAAADQAIAAACF4SDGQ ar3xxbJ9p0qa7R0YxwzaFME 1IAADs=
YAML の多くの実装では、オブジェクトのシリアル化のためにユーザー定義のデータ型をサポートできます。ローカル データ型はユニバーサル データ型ではありませんが、YAML パーサー ライブラリを使用してアプリケーションで定義されます。ローカル データ型では、単一の感嘆符 ( !) が使用されます。
例
データ構造の階層はアウトラインのインデントによって維持されます。
---
領収書: Oz-Ware 購入請求書日付: 2012-08-06顧客: first_name : Dorothy family_name : Gale
アイテム:
-部品番号: A4786説明:ウォーターバケツ(充填済み)価格: 1.47数量: 4
-部品番号: E1628説明:ハイヒール「ルビー」スリッパサイズ: 8価格: 133.7数量: 1
請求先: &id001住所: | 123 Tornado Alley Suite 16市: East Centerville州: KS
発送先: *id001
specialDelivery : >黄色いレンガの道をたどってエメラルド シティへ。カーテンの後ろにいる男には注意を払わないでください。...
文字列は引用符で囲む必要がないことに注意してください。並列要素の左揃えが同じで、階層的にネストされた要素がさらにインデントされている限り、インデントのスペースの具体的な数は重要ではありません。このサンプル ドキュメントは、7 つのトップ レベル キーを持つ連想配列を定義します。キーの 1 つである "items" には 2 要素のリストが含まれ、各要素はそれ自体が異なるキーを持つ連想配列です。リレーショナル データと冗長性の削除が表示されます。"ship-to" 連想配列の内容は、アンカー ( &) および参照 ( *) ラベルで示されるように、"bill-to" 連想配列の内容からコピーされます。読みやすくするために、オプションで空白行を追加できます。1 つのファイル/ストリームに複数のドキュメントを含めることができ、 で区切られます---。オプションで を...ファイルの末尾に使用できます (パイプを閉じずにストリーム通信の終了を通知するのに役立ちます)。
特徴
インデント区切り
YAML は主にアウトライン インデントを使用して構造化しているため、区切り文字の衝突|に特に耐性があります。YAML はスカラー値内の引用符や中括弧を区別しないため、ブロック リテラルでインデントするだけで (またはを使用)、YAML ドキュメント内に XML、JSON、さらには YAML ドキュメントを埋め込むことができます>。
---
例: > HTML は変更されずに YAML に入りますメッセージ: |
<blockquote style="font: italic 1em serif">
<p>「3 は常に 2 より大きい。2が大きな値であっても同じである」</p> <p>--著者不明</p> </blockquote>日付: 2007-06-01
YAML は、すべての内部引用符を引用符で囲んでエスケープすることで JSON に配置できます。YAML は、予約文字 (、、、、) をエスケープし<て空白を変換するか、CDATAセクションに配置することで>XMLに配置できます。
&'"
非階層型データモデル
各子ノードが単一の親を持つ階層モデルでのみデータを表すことができる JSON とは異なり、YAML は、ツリー内の 2 つ以上のポイントから同じデータの繰り返しを参照できるシンプルなリレーショナル スキームも提供します。これらのポイントで重複して入力されることはありません。これは、XML に組み込まれている IDREF 機能に似ています。[25]次に、YAML パーサーは、これらの参照を、読み込まれたときに暗示される完全に設定されたデータ構造に展開します。そのため、パーサーを使用するプログラムは、参照を展開しない XML プロセッサとは異なり、リレーショナル エンコーディング モデルを意識する必要はありません。この展開により、可読性が向上し、構成ファイルまたは処理プロトコルでのデータ入力エラーが削減されます。これらのプロトコルでは、連続する一連のレコードで多くのパラメーターが同じままで、いくつかのパラメーターのみが異なります。たとえば、請求書の「発送先」レコードと「請求先」レコードは、ほぼ常に同じデータです。
実用的な考慮事項
YAML は行指向であるため、既存のプログラムの非構造化出力を YAML 形式に変換することは、多くの場合、元のドキュメントの外観をほぼ維持しながら簡単に行うことができます。バランスを取る必要がある終了タグ、中括弧、引用符がないため、一般的に、単純なプログラム内の分散印刷ステートメントから直接、整形式の YAML を生成することは簡単です。同様に、空白区切り文字により、grep、AWK、Perl、Ruby、Python の行指向コマンドを使用して、YAML ファイルを素早く簡単にフィルタリングできます。
特に、マークアップ言語とは異なり、連続する YAML 行のチャンクは、それ自体が整形式の YAML ドキュメントである傾向があります。これにより、ドキュメント全体を処理する必要がないパーサー (開始タグと終了タグのバランスをとる、引用符で囲まれた文字やエスケープされた文字をナビゲートするなど) を非常に簡単に作成してから、特定のレコードを抽出し始めることができます。この特性は、データ構造全体がメモリに保持するには大きすぎるファイル内のレコードを単一のステートレス パスで反復処理する場合や、1 つの項目を抽出するために構造全体を再構成するとコストがかかりすぎる場合に特に便利です。
直感に反して、インデントによる区切りは深くネストされた階層を複雑にしているように見えるかもしれませんが、YAML は 1 つのスペースほどの小さなインデントも処理するため、マークアップ言語よりも優れた圧縮を実現できます。さらに、次のいずれかの方法で、極端に深いインデントを完全に回避できます。1) インデントのない「インライン スタイル」(つまり JSON のような形式) に戻す。2) リレーショナル アンカーを使用して階層をフラットな形式に展開し、YAML パーサーが透過的に完全なデータ構造に再構成する。[26]
安全
YAML は純粋にデータ表現言語であるため、実行可能なコマンドはありません。検証と安全な解析はどのデータ言語でも本質的に可能ですが、実装は非常に落とし穴が多いため、YAML には関連するコマンド言語がないため、相対的にセキュリティ上の利点がある可能性があります。
しかし、YAML では言語固有のタグが許可されているため、それらのタグをサポートするパーサーによって任意のローカル オブジェクトを作成できます。高度なオブジェクトのインスタンス化を実行できる YAML パーサーは、インジェクション攻撃の可能性があります。任意のクラスのオブジェクトの読み込みを許可する Perl パーサーは、いわゆる「祝福された」値を作成します。これらの値を使用すると、クラスがオーバーロードされた演算子を使用する場合など、予期しない動作が発生する可能性があります。これにより、任意の Perl コードが実行される可能性があります。[27] [信頼できないソース? ]
PythonやRubyパーサーでも状況は同様です。PyYAMLのドキュメントによると: [28]
インターネットなどの信頼できないソースから YAML ドキュメントを受け取った場合、任意の Python オブジェクトを構築する機能は危険な場合があることに注意してください。この関数は、
yaml.safe_load整数やリストなどの単純な Python オブジェクトにこの機能を制限します。[...]PyYAML を使用すると、あらゆるタイプの Python オブジェクトを構築できます。Python クラスのインスタンスも、
!!python/objectタグを使用して構築できます。
データ処理と表現
YAML仕様では、インスタンス文書を「プレゼンテーション」または「文字ストリーム」として識別します。[29] YAMLインスタンス文書の主な論理構造は、スカラー、シーケンス、およびマッピングです。[30] YAML仕様では、これらの主な論理構造に適用されるいくつかの基本的な制約も示されています。たとえば、仕様によると、マッピングキーには順序がありません。ノードの順序が重要な場合は常に、シーケンスを使用する必要があります。[31]
さらに、YAMLプロセッサの適合性を定義する際に、YAML仕様では、ダンプとロードという2つの主要な操作を定義しています。すべてのYAML準拠プロセッサは、これらの操作の少なくとも1つを提供する必要があり、オプションで両方を提供することもできます。[32]最後に、YAML仕様では、ダンプとロードの両方の操作の処理中に作成する必要がある情報モデルまたは「表現グラフ」を定義していますが、この表現はAPIを通じてユーザーに提供される必要はありません。[33]
他のシリアル化形式との比較
JSONとの比較
JSON構文は YAML バージョン 1.2 の基礎であり、YAML を「公式サブセットとして JSON に準拠させる」という明確な目的で公布されました。[4]以前のバージョンの YAML は厳密には互換性がありませんでしたが、[34]相違はほとんど目立たず、ほとんどの JSON ドキュメントは Syck などの一部の YAML パーサーで解析できます。[35]これは、JSON のセマンティック構造が、YAML のオプションの「インライン スタイル」と同等であるためです。拡張階層は JSON のようにインライン スタイルで記述できますが、明瞭性を高める場合を除いて、これは推奨される YAML スタイルではありません。
YAML には、コメント、拡張可能なデータ型、リレーショナル アンカー、引用符なしの文字列、キー順序を保持するマッピング タイプなど、JSON にはない多くの追加機能があります。
簡潔さのおかげで、JSONのシリアル化とデシリアル化はYAMLよりもはるかに高速です。[36] [37]
TOMLとの比較
TOML は.ini ファイル形式の発展形として設計されました。YAML のインジケータ文字の使用は最小限で、TOML の引用符と角括弧の厳格な要件と比較すると好ましいです。[意見] YAML の重要なインデントの使用は、同じ意味構造を伝えるために TOML のキーとテーブル名のドット表記法と対比されています。どちらの規則がより読みやすい設定ファイルにつながるかについては意見が分かれています。[38] [39]
XMLとの比較
YAML には、XML にあるタグ属性の概念がありません。代わりに、YAML には拡張可能な型宣言 (オブジェクトのクラス型を含む) があります。
YAML 自体には、たとえばドキュメントの自己検証を可能にする XML の言語定義ドキュメント スキーマ記述子がありません。ただし、その役割を果たす YAML 用の外部定義スキーマ記述言語がいくつかあります (例: Doctrine、 Kwalify 、 Rx)。さらに、YAML ドキュメント自体の YAML 言語定義型宣言によって提供されるセマンティクスにより、単純で一般的な状況では検証の必要性が緩和されることがよくあります。さらに、YAML データ構造を XML で表現する YAXML を使用すると、XML スキーマ インポーターとXSLTなどの出力メカニズムをYAML に適用できます。
データシリアル化形式の比較では、 YAML と他のシリアル化形式をより包括的に比較します。
ソフトウェア(エミッターとパーサー)
固定データ構造の場合、データと YAML 固有の装飾の両方を書き込む印刷コマンドを使用して、YAML ファイルを簡単に生成できます。ただし、変化する、または複雑な階層データをダンプするには、専用の YAMLエミッターが適しています。同様に、単純な YAML ファイル (キーと値のペアなど) は、正規表現を使用して簡単に解析できます。より複雑または変化するデータ構造の場合は、正式な YAMLパーサーをお勧めします。
YAMLエミッターとパーサーは多くの人気言語に存在します。そのほとんどはネイティブ言語自体で書かれています。いくつかはCライブラリlibyamlの言語バインディングで、より高速に実行される可能性があります。以前はSyckと呼ばれる別のCライブラリがありましたが、 why the lucky stiffによって作成され孤立しています。メンテナンスされておらず、信頼できるソースバンドルがなく、Webサイトがハイジャックされています。したがって、推奨される唯一のCライブラリはlibyamlです。これはもともとKirill Simonovによって開発されました。2018年に、新しいメンテナーであるIan CordascoとIngy döt Netによって開発が再開されました。[40]
C++プログラマーは、CライブラリlibyamlとC++ライブラリlibyaml-cppのどちらかを選択できます。どちらも完全に独立したコードベースと完全に異なるAPIを持っています。ライブラリlibyaml-cppのメジャーバージョン番号は0のままで、バージョン0.3以降実際に起こったように、APIがいつでも変更される可能性があることを示しています。ネストされた要素の拡張を目的として、C#で書かれた文法に重点を置いた実装があります。[41]
Perl の YAML.pm などの一部の YAML 実装では、ファイル全体 (ストリーム) をロードして一括して解析します。PyYaml などの他の実装は遅延型で、要求があった場合にのみ次のドキュメントを反復します。ドキュメントを個別に処理する予定の非常に大きなファイルの場合、処理前にファイル全体をインスタンス化するのは困難です。そのため、YAML.pm では、ファイルをドキュメントに分割し、個別に解析する必要がある場合があります。YAML では、ドキュメント終了マーカーで分割するだけで済むため、これは簡単です。ドキュメント終了マーカーは、行頭の 3 つのピリオドとそれに続く空白 (およびコメントの可能性あり) として定義されます。このマーカーはコンテンツでは禁止されています。[42]
批判
YAMLは、空白が多く、機能がわかりにくく、デフォルトが安全でなく、仕様が複雑で曖昧であるという批判を受けてきた。 [43] [44] [45]
- 設定ファイルは、ユーザーが気付かないうちにコマンドを実行したり、コンテンツを読み込んだりすることができます。[43]
- 大きなYAMLファイルの編集は、インデントエラーが気付かれない可能性があるため困難です。[43]
- 型の自動検出はエラーの原因となる。例えば、引用符で囲まれていない
YesとNoブール値に変換され、ソフトウェアのバージョン番号は浮動小数点数に変換される可能性がある。[43] [46] - 切り捨てられたファイルは、終端文字がないため、有効な YAML として解釈されることがよくあります。
- 標準の複雑さにより実装に一貫性がなくなり、言語が移植不可能になった。[43] [47]
YAMLの欠陥と複雑さが認識されたため、StrictYAMLやNestedTextなどのより厳格な代替手段が登場しました。[46]
参照
参考文献
- ^ ab Polli, Roberto; Wilde, Erik; Aro, Eemeli (2024-02-21). YAML メディア タイプ (レポート). Internet Engineering Task Force. 2024-02-21 時点のオリジナルよりアーカイブ。2024-02-21に取得。
- ^ "yaml". Apple Developer Documentation: Uniform Type Identifiers . Apple Inc. 2023-05-22 のオリジナルからアーカイブ。2023-05-22に取得。
- ^ abcd 「Yet Another Markup Language (YAML) 1.0 / Working Draft」。2001年12月10日。2019年7月10日時点のオリジナルよりアーカイブ。 2019年5月28日閲覧。
- ^ abc 「YAML Ain't Markup Language (YAML) Version 1.2」。YAML.org。2019年1月24日時点のオリジナルよりアーカイブ。2019年5月29日閲覧。
- ^ 「組み込み型 — Python 3.9.6 ドキュメント」。docs.python.org。2020年 6 月 14 日時点のオリジナルよりアーカイブ。2021 年 8 月 19 日閲覧。
- ^ 「標準組み込みオブジェクト - JavaScript | MDN」。developer.mozilla.org。2021年1月19日時点のオリジナルよりアーカイブ。2021年8月19日閲覧。
- ^ corob-msft (2021 年 8 月 17 日). 「組み込み型 (C++)」. docs.microsoft.com . 2024 年 6 月 13 日時点のオリジナルよりアーカイブ。2021年 8 月 19 日閲覧。
- ^ 「公式YAML Webサイト」。yaml.org 。 2021年3月18日時点のオリジナルよりアーカイブ。2019年2月5日閲覧。
- ^ 「YAML編集用にVimを設定する」arthurkoziel.com。2021年11月23日時点のオリジナルよりアーカイブ。 2021年12月20日閲覧。
- ^ “Yaml Mode”. EmacsWiki. 2015-06-12. 2016-11-08 にオリジナルからアーカイブ。2016-12-05に取得。
- ^ aukaost. 「Pretty YAML - パッケージ - パッケージ コントロール」。Packagecontrol.io。2016 年 11 月 8 日にオリジナルからアーカイブ。2016年 12 月 5 日に取得。
- ^ 「yaml | Eclipse プラグイン、バンドル、製品 - Eclipse Marketplace」。Marketplace.eclipse.org。2016 年 11 月 8 日時点のオリジナルよりアーカイブ。2016年 12 月 5 日閲覧。
- ^ Ruth Kusterer. 「NetBeans IDE - Ruby および Ruby on Rails 開発」。Netbeans.org。2016 年 11 月 19 日時点のオリジナルよりアーカイブ。2016 年 12 月 5 日閲覧。
- ^ 「YAML はマークアップ言語ではない」。2006 年 9 月 24 日。2006 年 9 月 24 日時点のオリジナルよりアーカイブ。
- ^ Evans, Clark (2001年5月11日). 「YAML Draft 0.1」. Yahoo! Tech groups: sml-dev. 2001年6月3日時点のオリジナルよりアーカイブ。 2019年3月21日閲覧。
- ^ ab 「YAML はマークアップ言語ではない: 概要」YAML.org。 2019 年 4 月 14 日時点のオリジナルよりアーカイブ。2019 年 5 月 29 日閲覧。
- ^ 「Yet Another Markup Language (YAML) 1.0」。YAML.org。2019年4月14日時点のオリジナルよりアーカイブ。2019年5月29日閲覧。
- ^ 「Yet Another Markup Language (YAML) 1.0」。stackoverflow.com。2021年4月23日時点のオリジナルよりアーカイブ。2021年3月24日閲覧。
- ^ 「YAML 1.1 リファレンス カード」。YAML.org。2019年 4 月 14 日時点のオリジナルよりアーカイブ。2019 年 5 月 29 日閲覧。
- ^ 「YAML Ain't Markup Language (YAML) バージョン 1.2」。YAML.org 。2019年 1 月 24 日時点のオリジナルよりアーカイブ。2019 年 5 月 29 日閲覧。
- ^ 「YAML仕様v1.2.2 セクション6.1. インデントスペース」。2023年3月12日時点のオリジナルよりアーカイブ。2023年3月12日閲覧。
- ^ 「YAML Ain't Markup Language (YAML) バージョン 1.2」。YAML.org 。2019年 1 月 24 日時点のオリジナルよりアーカイブ。2019 年 5 月 29 日閲覧。
- ^ 「クラウドベースの管理アプリ」。JigoCloud.com 。 2016年9月17日時点のオリジナルよりアーカイブ。2016年9月28日閲覧。
- ^ ab 「YAML 1.2 Structures仕様」YAML.org。2019年1月24日時点のオリジナルよりアーカイブ。2019年5月29日閲覧。
- ^ 「Extensible Markup Language (XML) 1.0 (Second Edition)」。W3.org。2022年5月15日時点のオリジナルよりアーカイブ。2015年5月27日閲覧。
- ^ 「無料コース | YAML入門 - 実践コース」Insidelearn . 2022年8月26日時点のオリジナルよりアーカイブ。2022年8月4日閲覧。
- ^ “YAML”. Teknik Informatika . 2022-08-04. 2022-12-26時点のオリジナルよりアーカイブ。 2022-08-04に閲覧。
- ^ 「PyYAML ドキュメント、YAML のロード」。Pyyaml.org。2016年 9 月 24 日時点のオリジナルよりアーカイブ。2016年 9 月 28 日閲覧。
- ^ 「Ain't Markup Language (YAML) バージョン 1.1」。YAML.org。2019年 4 月 14 日時点のオリジナルよりアーカイブ。2019 年 5 月 29 日閲覧。
- ^ 追加のオプション使用の論理構造は、YAML タイプ リポジトリに列挙されています。「Language-Independent Types for YAML Version 1.1」。YAML.org 。2019年 4 月 14 日にオリジナルからアーカイブ。2019 年 5 月 29 日に取得。YAML タイプ リポジトリ内のタグ付けされたタイプはオプションであるため、準拠する YAML プロセッサにとって必須ではありません。「これらのタグの使用は必須ではありません。」
- ^ 「YAML Ain't Markup Language (YAML) バージョン 1.1」。YAML.org 。2024年 6 月 13 日時点のオリジナルよりアーカイブ。2019 年 5 月 29 日閲覧。
- ^ 「Ain't Markup Language (YAML) バージョン 1.1」。YAML.org。2024年6月13日時点のオリジナルよりアーカイブ。2019年5月29日閲覧。
- ^ 「YAML Ain't Markup Language (YAML) バージョン 1.1」。YAML.org 。2019年 4 月 14 日時点のオリジナルよりアーカイブ。2019 年 5 月 29 日閲覧。
- ^ 非互換性は以下のとおりです。JSON は UTF-32 などの拡張文字セットを許可していますが、YAML とは互換性のない Unicode 文字エスケープ構文を持っていました。YAML ではカンマ、イコール、コロンなどの区切り文字の後にスペースが必要ですが、JSON では必要ありません。JSON の非標準実装の中には、文法を拡張して Javascript の
/*...*/コメントを含めるものもあります。このようなエッジケースを処理するには、インライン YAML として解析する前に JSON の軽い前処理が必要になる場合があります。[1] Archived 2013-08-29 at the Wayback Machineも参照してください。 - ^ SYCK による JSON の解析 Archived 2016-09-17 at the Wayback Machine。たとえば、Symfony の YAML パーサーは [] または {} 構造内の改行をサポートしていないため、JSON との大きな非互換性があることに注意してください。
- ^ “YAML vs JSON vs XML in Go” . Medium . 2021年6月15日. 2024年1月24日時点のオリジナルよりアーカイブ。 2024年1月31日閲覧。
- ^ “YAMLとJSONの違い”. Baeldung . 2020年7月9日. 2023年3月7日時点のオリジナルよりアーカイブ。 2023年3月7日閲覧。
- ^ Siebenmann, Chris (2019-04-30). 「YAML の空白の使用に関する私の問題」。2023 年 12 月 1 日時点のオリジナルよりアーカイブ。2023年 10 月 6 日閲覧。
- ^ TOML の何が問題なのですか?
- ^ yaml-core@lists.sourceforge.net、2018 年 6 月 27 日のメール。
- ^ 「Lexepars の YAML 文法」。GitHub。2020年9 月 17 日のオリジナルからアーカイブ。2020 年 2 月 20 日閲覧。
- ^ 「YAML Ain't Markup Language (YAML) バージョン 1.2 # 9.1.2 ドキュメントマーカー」YAML.org。 2019 年 1 月 24 日時点のオリジナルよりアーカイブ。 2019 年 5 月 29 日閲覧。
- ^ abcde Tournoij, Martin (2016年9月4日). 「YAML: 結局のところそれほど素晴らしいものではない可能性が高い」。2019年5月10日時点のオリジナルよりアーカイブ。2019年5月16日閲覧。
- ^ “That's a lot of YAML”. 2019年3月2日時点のオリジナルよりアーカイブ。2019年5月16日閲覧。
- ^ “YAML は最悪だ” 。GitHub。2019年4月7日時点のオリジナルよりアーカイブ。2019年5月16日閲覧。
- ^ ab “ノルウェー問題 - StrictYAML が暗黙的な型指定を拒否する理由と、あなたもそうすべき理由”. 2020年2月21日時点のオリジナルよりアーカイブ。2020年6月3日閲覧。
- ^ 「YAML テスト マトリックス」。2020 年 7 月 16 日時点のオリジナルよりアーカイブ。2020 年 4 月 3 日閲覧。
外部リンク
- 公式サイト
- YAMLスクリプト
