YamlBoxに関する質問

いいえ。コンバータはバンドルされた YAML パーサーを使用してブラウザ内で完全に実行されます。構成 (内部のシークレットを含む) がデバイスから離れることはなく、ツールはページの読み込み後にオフラインで動作します。

--- で区切られたドキュメントは個別に解析され、ドキュメントごとに 1 つのオブジェクトとして JSON 配列に結合されます。最初のドキュメントのみが必要な場合は、マルチドキュメント オプションを「最初のドキュメントのみ」に切り替えます。

はい。有効な YAML 1.2 はすべて動作します: Kubernetes マニフェスト、docker-compose.yml、GitHub Actions および GitLab CI パイプライン、Ansible Playbook、OpenAPI 仕様、および Helm 値ファイル。 Helm テンプレートで使用されるアンカーとエイリアスは、最終値に解決されます。

最も一般的な原因は、インデントにタブが使用されている (スペースのみが許可されます)、キーの後にコロンが欠落している、または同じマッピング内の重複キーです。エラー パネルには問題の行とその列が表示され、通常は問題が明らかになります。

コメントは JSON には存在しないため、削除されます。それらを保持する必要がある場合は、YAML を信頼できる情報源として保持し、JSON をビルド アーティファクトとして扱います。

数メガバイトまでのファイルはミリ秒以内に変換されます。非常に大きなファイル (数十メガバイト) はデバイスのメモリに依存します。携帯電話では処理できない場合でも、デスクトップ ブラウザでは快適に処理できます。

これは、JSON ソース内の数値であり、YAML は数値を正規にレンダリングするためです。値が意味的にバージョンまたは識別子の場合は、「強制引用符」をオンにして、YAML 内の文字列のままにします。

はい。ジェネレーターは、YAML パーサーを混乱させる可能性のあるキーを引用符で囲み、プレーン キーを引用符で囲まないままにするため、出力は読み取り可能でありながら明確なままになります。

はい - ファイルを貼り付けるか、入力ペインにドロップするか、[ファイル] ボタンを使用します。数メガバイトのドキュメントはデスクトップ ブラウザでは問題ありません。変換自体には数ミリ秒かかります。

デフォルトでは、yes - キーは JSON の順序を維持します。バージョン管理でクリーンな差分を生成する決定的なアルファベット順のファイルが必要な場合は、「ソートキー」を有効にします。

これは、パーサーが、見つかった場所に表示できない文字 (通常は、閉じ中括弧の前の末尾のコンマ、二重引用符の代わりに一重引用符、または引用符で囲まれていないキー) をヒットしたことを意味します。このフォーマッタは行と列を表示するので、数秒で修正できます。

両方。フォーマットには解析が成功する必要があるため、出力が表示されれば、入力は有効です。構造上の問題は、間違った出力を黙って生成するのではなく、その場所のエラーとして表示されます。

数メガバイトのファイルは即座にレンダリングされます。非常に大きなドキュメントの場合、実際の制限はフォーマッタではなくブラウザのメモリです。一般的なラップトップは問題なく数十メガバイトを処理します。

はい — 「キーのソート」を有効にすると、キーはすべてのレベルで再帰的にソートされます。これによりファイルが決定的になるため、バージョン管理の差分には実際の変更のみが表示されます。

一度もない。すべてがブラウザのタブで解析されます。ページをロードした後にネットワークから切断しても、フォーマッタは動作し続けます。

テキストの差分は行を比較するため、キーの再フォーマットまたは並べ替えによってノイズが発生します。このツールは両方のドキュメントを解析し、パスごとに値を比較するため、実際の意味上の変更のみを報告します。

はい — 配列は要素ごとに比較されます。一方のドキュメントには存在するが、もう一方のドキュメントには存在しない要素は、$.users[2] などのインデックス付きパスで追加または削除されたとして報告されます。

はい。両方のドキュメントが最初に解析されるため、キーの順序は関係ありません。 {"a":1,"b":2} と {"b":2,"a":1} は同一のものとして比較されます。

まず別のタブの YAML から JSON コンバータを使用して変換し、次に両方の JSON 出力をここに貼り付けます。 diff は構造的なものであるため、最初に YAML を JSON に変換しても結果には影響しません。

提供されたサンプルの種類と構造は正確です。推論で知り得ないのは、年齢が正でなければならない、またはフィールドが列挙型であるというビジネス ルールです。出力を強力な開始点として扱い、手動で制約を追加します。

項目スキーマはマージされます。すべての項目に存在するプロパティは必須になりますが、一部の項目にのみ存在するプロパティはオプションのままです。型の違いにより、type: ["string", "number"] などの共用体が生成されます。

バリデーターが AJV 6/7、古いエディター、または最近更新されていないものである場合は、draft-07 を選択してください。これは最も広範なサポートがあり、ほとんどの OpenAPI 3.0 ツールが期待するものです。新しいプロジェクトと AJV 8 には 2020-12 を選択してください。

実行時チェックのための AJV およびその他のバリデータ、JSON ファイルのオートコンプリートと検証のための VS Code、API 応答を文書化するための OpenAPI 仕様、および応答がコントラクトから逸脱した場合にビルドを失敗させる CI パイプライン。

入力がオブジェクトの配列である場合、すべての項目にわたって各プロパティがチェックされます。一部の項目にないキーには「?」が付いてオプションとしてマークされ、どこにでも存在するキーは必須のままです。

null は独自の型として扱われるため、文字列である場合もあれば null である場合もあるフィールドは string | 型となります。 null — コンパイラが信頼する嘘ではなく正直な型。

インターフェイスはより一般的な規則であり、宣言にうまく統合されます。型エイリアスは、共用体と交差の場合に読みやすくなります。機能的には、生成されたデータ形状については、既存のコードベースと一致するどちらでも機能します。

直接ではありません。同じペイロードから JSON スキーマを生成してバリデータを導出するか、Zod スキーマを手動で作成してこれらのインターフェイスを静的側に使用します。型はコンパイル時に形状を記述します。バリデーターは実行時にあなたを保護します。

はい。 JSON ファイルを貼り付けるかドロップします。ネストは再帰的に推論されます。非常に大きなペイロードは、ジェネレーター自体ではなくブラウザーのメモリによって制限されます。

JSON null はプレーン文字列または int に格納できないため、null 許容フィールドはポインタ (*string, *int) を取得します。これにより、エンコーディング/json は失敗することなく「存在しない」と「存在するが null」を区別できるようになります。これがまさにポインター型の目的です。

値が、ある項目では文字列であり、別の項目では数値である場合、ジェネレーターは間違った具体的な型を作成するのではなく、any を使用します。 API が本当に緩い場合は、カスタム UnmarshalJSON を決定できます。

サンプル内の少なくとも 1 つの項目に欠落していたフィールドのみ。必須フィールドにはプレーンなタグが付けられるため、ラウンドトリップによってデータが削除されることはありません。

はい — タブ、配置、フィールドの順序は gofmt の規則に従います。貼り付け後に gofmt -l を実行すると、変更は報告されません。

はい。ネストされたオブジェクトは個別の名前付き構造体になりますが、解析された JSON では循環が不可能であるため、深くネストされたペイロードであっても、フラットで読み取り可能な型のセットが生成されます。

各列はすべての行にわたってスキャンされます。すべての整数は INTEGER/INT になり、小数は NUMERIC/DOUBLE になり、ブール値は BOOLEAN になり、JSON に見える文字列は TIMESTAMPTZ になり、ネストされたオブジェクトまたは配列は方言に応じて JSONB/JSON/TEXT になります。

これは文字列リテラルが正しくエスケープされたプレーンなスクリプトであるため、開始点として安全です。本番環境で実行する前に確認してください。ジェネレータが推論できない主キー、インデックス、NOT NULL 制約、外部キーが必要になる場合があります。

これらは、ネストされた値を保持する単一の JSON/JSONB/TEXT 列になります。ネストされた構造のリレーショナル モデリングは設計上の決定であるため、ジェネレーターは結合を推測しません。

JSONB と TIMESTAMPTZ が必要な場合は PostgreSQL、DOUBLE 数値を含む JSON 列には MySQL、ファイルベースのデータベースとテストには SQLite。スクリプトの構造は同じです。型名とブール値リテラルのみが変更されます。

先頭のゼロは、郵便番号、製品コード、電話番号などの識別子で重要です。したがって、型キャストはデフォルトではオフになっています。数値に見えるすべての列が実際に数値である場合にのみ有効にします。

正しくは、パーサーは RFC 4180 に従っているため、「Hopper, PhD」は 2 つのフィールドではなく 1 つのフィールドです。埋め込まれた二重引用符はエスケープされず、複数行の引用符で囲まれた値は保持されます。

はい。区切り文字は最初の行から自動検出され、オプション バーで選択を明示的にオーバーライドできます。

JSON 行 (行ごとに 1 つの JSON オブジェクト) は、ほとんどのデータ ツール、ログ プロセッサ、および LLM パイプラインが期待する形式です。また、ストリーミングも改善され、各行を独立して処理できます。

人為的な制限はありません。非常に大きなファイルはブラウザのメモリによってのみ制限されます。 50 MB CSV は、一般的なラップトップで快適に変換できます。

これらはドット表記でフラット化されるため、{"customer":{"name":"Ada"}} は列 customer.name になります。ネストされた配列は意味のあるフラット化ができず、セル内で JSON としてシリアル化されます。

列リストは、すべてのレコードにわたるすべてのキーの結合です。キーが欠落していると空のセルが生成されるだけで、すべての行が同じヘッダーに揃えられます。

はい。出力は、UTF-8 エンコードを使用した標準 RFC 4180 CSV です。 Excel で、ダブルクリックすると古いバージョンのエンコードがマングルになる場合は、データ → テキスト/CSV を使用します。

はい - 各行は 1 つのレコードとして解析されるため、JSONL 入力は同じテーブルを同等の JSON 配列として生成します。

XML では、同じ名前の属性と子要素を許可します。JSON は 1 つのキーで表現できません。 @ 接頭辞により属性が要素と区別されるため、変換中に何も失われません。

同じタグが兄弟間で複数回出現する場合、値は JSON 配列になります。単一の出現はスカラーまたはオブジェクトのままです。これが、消費者が両方を許容する必要がある理由、またはコード内で正規化する必要がある理由です。

はい。名前空間要素はローカル名を保持し、接頭辞の衝突はソースに記述されたとおりに保持されます。名前空間の完全な忠実性が必要な場合は、元の XML を JSON と並行して保持してください。

はい — エンベロープとボディは他の XML と同様に変換されます。 SOAP の場合は、数値フィールドが文字列ではなく数値として届くように、キャストを有効にしておきます。

いいえ。.xlsx ファイルは、バンドルされているリーダーを使用して、ブラウザー タブの JavaScript によって解析されます。デバイスから離れることはないため、このツールは人事、財務、顧客データにとって安全です。

.xlsx (Excel 2007 以降) および .csv。従来のバイナリ .xls 形式はサポートされていません。まず Excel で開き、.xlsx または .csv として保存してください。

Excel によって保存されたキャッシュされた値が使用されます。ファイルが数式とともに保存され、結果がキャッシュされていない場合 (まれではありますが、可能性はあります)、それらのセルが空になる可能性があります。 Excel で再保存するとキャッシュが更新されます。

Excel は日付をシリアル番号として保存します。リーダーはそれらを JavaScript 日付に変換し、ISO 文字列を出力するため、「2025-03-14」は 45730 ではなくテキストとして届きます。

<track> 要素とすべての主要なブラウザ プレーヤーは、WebVTT 仕様を実装しています。 SRT はブロードキャスト ツールのレガシー形式です。これを受け入れるプレーヤーは通常、内部で不完全に変換します。

いいえ。変換はクライアント側のテキスト変換です。機密または未公開のコンテンツはブラウザから離れることはありません。これは多くの場合、スタジオの契約上の要件です。

WebVTT ではこれらは必須ではなく、オプションです。デフォルトでは、キューは順番に番号が付け直されます。番号付けを完全にオフにすることもできます。

はい — SRT <b>/<i>/<u> タグは有効な WebVTT であり、保存されます。 WebVTT は位置決めを異なる方法で表現するため、SRT 固有の {an8} スタイルの位置決めオーバーライドは削除されます。

現実世界の通常の癖、または を許容します。ミリ秒、1 桁の時間、有効なタイムコードを持つキュー間の空白行の欠落。本当に壊れたファイルは、サイレント破損ではなく明確なエラーが表示されます。

このツールを使用すると、トークン自体はそうです。デコードはブラウザー内の純粋な JavaScript であり、どこにも何も送信されません。ただし、それに関係なくトークンを秘密として扱います。JWT はベアラー資格情報であり、有効期限が切れるまでそれを保持している人に有効です。実稼働トークンの場合は、独自のデバッガーでローカルにデコードすることを推奨します。

いいえ、秘密鍵または公開鍵がなければデコーダも機能しません。 Base64url のみをデコードすると、セグメントがデコードされます。検証には署名キーが必要で、バックエンドまたは jose や jsonwebtoken などのライブラリに属します。

通常の原因は次のとおりです。exp クレームがパスした、トークンが別の対象者 (aud) または発行者 (iss) に対して発行された、サーバー クロックが nbf を将来に引き込むほど異なっている、または署名キーがローテーションされた。請求委員会は最初の 3 つについて即座に回答します。

iat は発行時刻、exp は有効期限、nbf は not-before です。 3 つはすべて秒単位の Unix タイムスタンプです。トークンは、nbf ≤ now < exp の場合 (これらのクレームが存在する場合) に有効です。

ペイロードを編集することはできますが、署名は一致しなくなるため、署名を検証するサーバーは、正しく言えば、ペイロードを拒否します。テストのために、環境内のキーを使用して再署名します。それが認証パスを正直にテストする唯一の方法です。

大きさ別: 現在のエポック秒は 10 桁 (1735689600)、ミリ秒は 13 (1735689600000) です。コンバーターはそのルールを適用し、明示的な小数も尊重します。つまり、1735689600.5 は小数部を含む秒として扱われます。

どちらも同じ瞬間を表しています。 UTC はタイムゾーンに依存しないため、ストレージとログにとって常に安全です。ローカルでは、ユーザーが認識するブラウザのタイムゾーンを使用して、デバイスの時計が表示されます。

ほとんどの場合、タイムスタンプのバグではなくタイムゾーンのバグです。ローカルタイム パーサーで作成された値が UTC として読み取られます (またはその逆)。ここで UTC 行とローカル行を比較します。UTC オフセットが異なる場合、それが原因です。

はい。負の Unix タイムスタンプは有効であり、エポックより前の日付を表します。コンバーターはそれらを処理し、過去の日付文字列も解析します。

2038 年 1 月 19 日の 03:14:07 UTC に発生した 32 ビット符号付き整数のオーバーフローは、タイムスタンプを int32 として保存する古いシステムに影響を与えます。 JavaScript では、このツールは影響を受けません。また、64 ビットまたはミリ秒ストレージの現在の慣行は影響を受けません。

クエリパラメータ (?q=…) 内に配置する値には encodeURIComponent を使用します。これは &、=、?、/、# をエスケープするので、値が URL の構造を壊すことはありません。完全な URL をそのまま保持したい場合は encodeURI を使用します。これにより、:、/、? が残ります。一人で。

パスまたはフラグメント内のスペースは %20 である必要があります。 application/x-www-form-urlencoded データ (従来の HTML フォームの本体) では、スペースは + です。ここでのクエリ パーサーは + をスペースとして扱います。これはフォーム エンコードされた文字列の正しい動作です。

これは 2 回エンコードされたためです。多くの場合、すでにエンコードされた値をフレームワークがエンコードしています。ここで一度デコードします。結果にまだ % シーケンスが含まれている場合は、再度デコードしてから、1 回だけエンコードされるようにパイプラインを修正します。

はい。テキストは UTF-8 バイトとしてエンコードされ、パーセントでエスケープされるため、日本語、アラビア語、キリル文字、絵文字はすべて、相互運用可能な正しい URL を生成します。

いいえ、Base64 は暗号化ではなくエンコードです。キーがなく、機密性はゼロです。 Base64 でエンコードされたデータを、単にスクランブルされているように見えるプレーンテキストとして扱います。機密性が必要な場合は、暗号化 (TLS、AES、エージ) を使用します。

標準 Base64 では + と / が使用されますが、これは URL と識別子の内部で問題になります。 URL セーフ バリアント (RFC 4648 §5) は、- と _ を置き換え、= パディングを省略することが多いため、値はクエリ文字列またはファイル名に配置されても存続します。

このツールはテキストにデコードします。これはテキスト ペイロードに適しています。デコードされたバイトが画像またはアーカイブの場合、このデコーダはゴミを出力するのではなく、それを明確に報告します。これらにはバイトからファイルへのツールを使用します。

パディング。 Base64 は 3 バイトを 4 文字にエンコードします。入力長が 3 の倍数ではない場合、エンコードではブロックを完全に保つために = が埋め込まれます。パディングは多くの場合オプションであり、URL セーフな使用法では削除されます。

リクエストの変換は正確です。メソッド、URL、ヘッダーおよび本文は、curl が送信するものと一致します。出荷前に追加する必要があるもの: エラー処理 (response.ok を確認)、AbortController によるタイムアウト、べき等呼び出しの再試行ロジック。

ノードフェッチはデフォルトで TLS を検証し、コード内で TLS を無効にするのはセキュリティ上の決定であるため、これは翻訳ではなくコメントに記載されています。代わりに証明書を修正してください。本当に必要な場合は、使い捨て環境でのみ NODE_TLS_REJECT_UNAUTHORIZED=0 を設定してください。

-u user:pass は、認証情報 Base64 でエンコードされた Authorization: Basic ヘッダーになります。これはまさにcurlが送信するものです。 API がサポートしている場合は、基本認証よりもトークンを優先します。

圧縮はフェッチ時に透過的に行われるため、 --compressed にはコードが必要ありません。フェッチではデフォルトでリダイレクトが続き、curl と -L が一致します。手動のリダイレクト処理が必要な場合は、redirect: "manual" を設定します。

ほとんどの失敗は、パーサーが認識できない複雑なシェル文字列またはフラグ内のエスケープされていない引用符に起因します。エラーでは、エラーが発生したトークンに名前が付けられます。通常は、推測するよりもコマンドを修正する方が早いです。

README ファイルは、エディター、差分、ターミナルなど、レンダリングされた形式と少なくとも同じ頻度で生の形式で読み取られるからです。列を埋め込むとソースが読みやすくなり、Markdown レンダラーは余分なスペースを無視します。

はい — 表を貼り付けます。パイプで区切られた入力が認識され、既存の区切り行がスキップされるため、書式設定なしでデータが返されます。

はい、バックスラッシュ (\|) を使用します。これは、標準の GitHub 風味の Markdown エスケープです。これがないと、値内のパイプが黙って行を追加の列に分割します。

GitHub、GitLab、Bitbucket、Obsidian、Notion (ペースト経由)、Jira、ほとんどの静的サイト ジェネレーター、およびテーブルをサポートする CommonMark レンダラー。 GitHub フレーバー付き Markdown がここでは事実上の標準です。