開発者ツール · 構文コンバーター
YAML から JSON への型強制: Yes、No、および 0777 の意味の変化
· 仕組み
yaml json データ形式
YAML は引用符で囲まれていないスカラーを型に解決します。ルールは YAML 1.1 と 1.2 では異なります。この投稿では、コンバーターが値がブール値、整数、浮動小数点数、または文字列であることをどのように判断するか、および結果を制御する方法を正確に示します。
true として返された値 — テキストとして意味されるプレーンな YAML スカラーがブール値として JSON に変換され、その後誤動作したサービス
`NO` などの値は、YAML 1.1 ローダーで false になる可能性がありますが、このコンバーターの出荷時はそうではありません。どちらの ToolAcre の選択肢も YAML 1.2 スキーマを使用するため、`NO`、`yes`、`no`、`on`、および `off` は文字列のままになります。このパネルが `NO` を true または false に変えると主張する例は、テストされた動作とは逆のことを教えることになるため、修正された冒頭は重要です。
タイプサプライズはまだ存在します。デフォルトの JSON スキーマでは、`null` は null ですが、`~`、空の値、および `0o755` は文字列のままです。 「コア」を選択すると、これら 3 つの形式が null、null、493 に変更されます。この出力は、すべてのプレーン YAML トークンが明白な型を持っているように見せるのではなく、解決された JavaScript 値を公開するため、まさに役立ちます。
YAML 1.2 の下にテキストとして残った値
js-yaml がソースを読み取るときに、暗黙的な解決が発生します。選択された制限付きスキーマは、コンバーターが JSON を書き込む前に、プレーン スカラーが null、ブール、または数値形式と一致するかどうかを決定します。引用符はその決定を回避します。`"0o755"` はどちらのスキーマでもテキストであり、ブロック スカラーは、その chomping インジケーターで表される改行を含む文字列のままです。
これは解析とシリアル化であり、正規表現の置換ではありません。リーダーは文字列、数値、ブール値、null、配列、オブジェクトを構築します。 `JSON.stringify` は、選択したインデントを使用してそれらの値を出力します。コメントとトークンのスペルは書き込み段階までにすでに削除されているため、シリアライザーは数値が元々 10 進数であったのか、それとも別の受け入れられている YAML 表記で書かれたのかを再構築できません。
YAML 1.1 ルール — はい/no/on/off ブール値、0777 は 8 進数、1:30 は 60 進数、1.10 のようなバージョン文字列は浮動小数点数として読み取られます。
アウトラインには、60 進数や従来の 8 進数などの YAML 1.1 強制がリストされています。これらは互換性に関する危険性がありますが、ここでは利用できるモードではありません。 ToolAcre は意図的に 1.1 スキーマを提供しません。その UI には、出荷されたオプションのどちらも `NO` が false として読み込まれないことが記載されており、テストではその国コードと、yes、no、on、off という単語が文字列として固定されます。
その境界により、デバッグ方法が変わります。別のアプリケーションがこれらの単語をブール値に変換する場合は、同一の出力を期待するのではなく、そのパーサー設定を ToolAcre と比較してください。コンバーターは、独自の 2 つのスキーマが何を生成するかを表示できます。後でファイルを使用する CI ランナー、フレームワーク、またはデプロイメント システムによって使用されるスキーマまたはバージョンを認証することはできません。
YAML 1.1 強制は、このコンバータが回避する危険です
デフォルトの JSON スキーマは、JSON のモデルと互換性のあるスカラー スペルのみを受け入れます。 Core では、おなじみの YAML null 形式、16 進数および 8 進数の整数、Infinity および NaN が追加されています。コアは依然として制限されたローダー内に留まります。言語固有のオブジェクト タグ、日付、セット、順序付けされたマップ、およびバイナリ タグは構築されずに拒否されます。
無限大と NaN は別の境界を明らかにします。 JavaScript はそれらを保持できますが、JSON は書き込むことができません。コンバーターは各パスを識別し、値が null になることを警告します。これは損失の多いステップであることは認められており、損失のない変換ではありません。引用符で囲まれた `.inf` は、値がリテラル文字列 `.inf` のままになるため、これを回避します。
出荷された 2 つの YAML 1.2 スキーマは、文書化されたスカラー形式でのみ異なります
`tilde: ~`、`empty:`、`octal: 0o755`、`country: NO`、`answer: yes` を貼り付けます。厳密に選択すると、JSON 値は `"~"`、`""`、`"0o755"`、`"NO"`、および `"yes"` になります。 「コア」を選択すると、最初の 3 つだけが変更されます。チルダと空は null になり、8 進数は 493 になります。国と回答は両方の出力でテキストのままになります。
次に、すべての値を引用符で囲んで繰り返します。ソースが意図した型を示しているため、どちらのスキーマも文字列を返します。この比較はコード的に正確であり、1.1 を決して読み込まないツール内で YAML 1.1 と 1.2 を比較するよりも便利です。また、ドキュメントだけから推測することなく、別のパーサーをチェックするためのレビュー可能な治具も提供します。
動作例: ToolAcre の strict スキーマと Core スキーマの下にある 1 つのファイル
明示的な標準タグは、制限付きスキーマが認識する場合にのみ受け入れられます。`!!str 123` は文字列 `123` になり、`!!int "7"` は数値 7 になります。 `!!binary`、`!!timestamp`、`!!set`、`!!js/function` などのタグや Python オブジェクト コンストラクターは拒否されます。これにより、YAML リーダーが任意のオブジェクト ファクトリになるのを防ぎます。
構成値が単に入力されているように見える場合、引用符は移植可能な選択肢として残ります。別のツールで存続する明示的なタグに依存することなく、先頭のゼロ、バージョンのスペル、センチネルの単語が保持されます。 JSON の結果には、選択されたタイプが表示されますが、その値を生成した引用スタイルやタグを保持することはできません。
これでカバーされないもの — 結果の JSON のアプリケーション レベルの解析。型を再度強制する可能性があります (たとえば、文字列 '1' を数値に変換する)
アプリケーション コードは、結果の JSON を再度強制する可能性があります。 API は `"1"` を読み取って数値に変換したり、スキーマに対して拒否したりできます。構文コンバータは JSON テキストを生成した後に停止します。フレームワーク検証ツール、環境変数ローダー、ビジネス ルールは実行されません。したがって、クリーンな変換は構文とマッピングを証明するものであり、最終的なサービスが受け入れられることを証明するものではありません。
YAML キーの重複は別の問題です。 ToolAcre は最後の値を保持し、繰り返されたキーを位置とともにレポートします。複数のドキュメント ストリームは配列になります。これらの選択により、すべてのスカラー型が予期されている場合でも、アプリケーションで表示される内容が変更される可能性があるため、書式設定された JSON 本体だけを判断するのではなく、警告を読んでください。
要点: マシンが読み間違える可能性のあるものはすべて引用します。また、ブラウザーで YAML を JSON に変換すると、各スカラーが正確に何に解決されるかが明らかになります。
マシン トークンに似たテキストを引用符で囲み、JSON タイプを検査します。最小の JSON 型のスカラー語彙が必要な場合は strict を使用します。 YAML null および数値形式が必要な場合は、意図的にコアを選択してください。どちらのオプションも YAML 1.1 ではなく、下流の消費者に同じルールに従うようにもしません。
パネルはパーサーの選択を表示し、ターゲットが表現できない値に対して警告を返します。これは正直な約束です。これにより、この実装が各スカラーをどのように解決したかが明らかになります。普遍的な YAML 動作を主張したり、ラウンドトリップを通じてコメント、タグ、スペルを保持したりするものではありません。