対応する変換範囲と設計思想
本ツールは,Webフロントエンド上でJSON,YAML,TOMLの各データ形式を相互に変換するためのデータ変換ユーティリティです.全9通りの入力・出力形式の組み合わせに対応しており,同一形式同士の再シリアライズや整形も含めて,単なるテキストの素通しではなく共通の同期処理コアによって構文解析,バリデーション,および再シリアライズの全工程を経て出力されます.
各データ形式の広範な完全仕様を網羅するのではなく,相互運用が可能な定義済みサブセットに焦点を当てています.具体的には,YAMLの解析にはjs-yaml(JSON_SCHEMA適用)を利用し,TOMLについては定義された制限付きサブセットパーサーを適用して,共通して扱える構造化データのみを同期的に中継・変換します.
処理可能なデータモデルは,ルート要素がオブジェクトまたは配列である構造に限られます.TOML出力に関しては,ルート要素がオブジェクトである必要があります.扱える値の型は,文字列,有限で安全な範囲内の10進数値,真偽値,配列,オブジェクト,そしてJSONおよびYAMLにおけるnullです.
TOML仕様自体はインラインテーブルやテーブル配列により配列内オブジェクトを許容しますが,本ツールのサブセットでは配列内オブジェクトを拒否し,またTOMLにおけるnull値はオブジェクトのプロパティを含め一切未対応としているため,これらを含むデータ構造をTOML形式へ書き出そうとした場合は未対応エラーとして拒否されます.
本ツールでは入力およびデータ構造に対して定量的な制限を設けています.入力文字列長は構文解析前の段階で100,000 UTF-16コードユニット以下に制限され,解析対象のデータツリーはルートを深さ1として最大深さ32階層,巡回する値ノード数は重複除外を行わない訪問総数として最大20,000個までに制限されています.
また,展開後のキーと文字列の総量予算およびシリアライズ後の出力文字列長はそれぞれ1,000,000 UTF-16コードユニットを上限としています.一部の検査は構文解析後に実施されるため,厳密な実行時間やメモリ消費の回避を保証するものではありません.
変換処理はWeb Workerや300msのデバウンス処理を介さず,入力テキストや形式セレクターの変更に対して共通の同期処理コアにより実行されます.完全な仕様を網羅する万能な変換を目指すのではなく,明確に定義されたデータモデルのサブセットのみを変換対象とすることで,同一形式の再シリアライズを含め,すべての変換において共通の構文解析と検証手続きを経て結果を出力します.
JSONの扱いとネイティブ解析のメカニズム
JSON(JavaScript Object Notation)は,データ交換の標準規格として最も広く普及しているフォーマットです.本ツールにおいてJSON入力を処理する際は,JavaScriptの標準組み込み関数である JSON.parse を用いて構文解析を行い,出力時にはインデント2文字の整形設定を適用した JSON.stringify を使用します.
ただし,ブラウザ標準のJSON処理には言語仕様および実行環境に起因する特性が存在するため,単なる構文適合だけでなく,後続のバリデーションフェーズにおいて厳格な値の検査が実施されます.
まず注意すべき点として,JSONテキスト内に同一オブジェクト内で重複するキーが存在した場合,標準の JSON.parse の挙動により最後に出現したキーの値で上書きされ,先行するキーは暗黙のうちに破棄されます.また,JSON仕様上は数値の桁数に制限がありませんが,JavaScriptエンジンがパースする過程でIEEE 754倍精度浮動小数点数(Number 型)として解釈されるため,数値の語彙的表記(整数表記か浮動小数点表記かなど)が保持されず,精度限界(Number.isSafeInteger を超える巨大整数)において下位桁の丸めや精度の喪失が発生する可能性があります.
本ツールでは,これらの問題を放置せず,パース後にツリー全体を巡回して値の適合性を検査します.Number.isSafeInteger の範囲(-9,007,199,254,740,991 〜 9,007,199,254,740,991)を超える整数,無限大(Infinity / -Infinity),非数(NaN),および負のゼロ(-0)は無効な数値として検出し,変換を即座に中断します.
一方,"001" や "9007199254740993" のように引用符で囲まれた文字列は,先頭のゼロが削られたり数値化されたりすることなく,安全に文字列型として維持されます.
数値は有限な値(有限小数を許容)かつ負のゼロ(-0)を禁止とし,整数値については安全な整数範囲内の値のみを受け付けます.文字列内の孤立サロゲートについては,JSON.stringify 自体はエスケープしてシリアライズ可能であるものの,Unicodeポリシーに基づき明示的に拒絶されます.
__proto__ や constructor といった特殊なプロパティ名を含むオブジェクトは,通常のデータプロパティとして保持されます.
制限付きYAMLの解析と出力に関する仕様
YAMLはインデントによって階層を表現する人間可読性の高いフォーマットですが,仕様が極めて広範かつ複雑であり,暗黙の型変換や高度な参照機能が意図しない挙動を引き起こしやすい側面を持っています.本ツールでは,実証済みのライブラリである js-yaml(バージョン4.3.2)の JSON_SCHEMA モードを再利用し,最大深さ32階層の制約下で処理を行いますが,読み込み前に入力テキストに対する厳格な事前検査(preflight check)を実施して対応構文を安全なブロック構造に制限しています.
本ツールが受け付けるYAML構文は,単一ドキュメント形式のブロックマッピング(キーと値のペア)およびブロックシーケンス(ハイフンによる配列)です.キーとして許容されるのは単一引用符または二重引用符で囲まれた単一行の文字列キー,もしくは単純なプレーン文字列キーに限られます.
インデントによるネストされたマップや,配列要素内に記述されたマップ,および空のインライン構造([] や {})は正しく解釈されます.また,key: のようにコロンの後に値が指定されていない空値は,明示的に null として扱われます.
本ツールでは,YAMLの空のインラインフロースタイル([] や {})は受け付けられますが,要素を含む空でないフロースタイル([a, b] や {k: v})は拒否されます.また,アンカー(&),エイリアス(*),カスタム型タグ(!),リテラルブロックや折り返しブロックなどの複数行文字列(|,>),ディレクティブ行(%),ドキュメント区切りマーカー(---,...),明示的な複合キー(?),および数値・真偽値・nullなどの非文字列キーといった高度な機能は,本ツールの制限付きサブセットの対象外として意図的に排除されています.
YAML内のコメント(#)は構文上受け入れられますが,内部データツリーには保持されず出力時には失われます.また,日時形式に類似した文字列(ISO-8601形式など)は JSON_SCHEMA の適用によりDateオブジェクトへ変換されることなく文字列型として保持されます.
YAML出力時は,2スペースインデント,参照なし(noRefs),全文字列引用符強制(forceQuotes: true)の安全なブロックコレクション形式で一貫して再シリアライズされます.
制限付きTOMLの解析ロジックとテーブル階層
TOML(Tom's Obvious, Minimal Language)は,INIファイルに似た明確で簡潔な構文を持つ設定フォーマットです.本ツールでは,明確に定義されたルールに基づくTOML 1.0の制限付きサブセットパーサーを搭載し,同期的に構文解析を行います.
ルート要素は必ずテーブル(オブジェクト)として扱われ,ベアキー(英数字・アンダースコア・ハイフン)または単一・二重引用符で囲まれた引用キーによるキー代入と,角括弧で囲まれたテーブルヘッダー([section])による階層定義をサポートしています.
対応する構文要素としては,単一行の基本文字列(ダブルクォート)およびリテラル文字列(シングルクォート),厳格なエスケープシーケンス(\b,\t,\n,\f,\r,\",\\,および有効なUnicodeスカラー値を表す \uXXXX / \UXXXXXXXX),10進有限数値,真偽値,プリミティブ値による多次元配列が含まれます.
TOMLのインラインテーブル({})は未対応であり,空のテーブルはキーを持たないセクションヘッダー([table])として表現され,空の配列([])は値としてのみ有効でルートテーブルにはなれません.TOML出力はルートオブジェクトのみを受け付け,空のJSONオブジェクト({})はTOMLの改行のみへと変換されます.
空文字列の入力はUI上で空文字列のまま保持され,空白文字やコメントのみのTOML入力は空のオブジェクト({})として解釈されます.なお,TOML仕様自体は配列内のオブジェクトを許容しますが,本ツールのサブセットでは配列内オブジェクトを実装しておらず,またTOMLにおけるnull値は一切未対応です.
一方で,TOMLの複雑な構文や曖昧性を排除するため,以下の構文は非対応として厳密に拒絶されます.キー側でドットを連結するドット付きキー代入(a.b.c = 1),2進・8進・16進数やアンダースコアを含む数値表記,無限大・非数(inf,nan),日時・タイムスタンプ型,複数行文字列(トリプルクォート),値と同一行に記述されたインラインコメント,インラインテーブル({ ... }),配列テーブル([[array]])はサポートされず,未対応構文としてエラーを返します.
未知の識別子を勝手に文字列型へ丸め込んで成功と見なすような暗黙の処理は行いません.
構文規則として,同一セクションヘッダーの重複定義,同一スコープ内での重複キー,およびスカラー値とテーブルの衝突は拒絶されますが,子セクションヘッダー(例:[a.b])の記述によって暗黙的に親テーブルが生成された後,後続の記述でその親テーブル(例:[a])を明示的に定義することは許容されます.
TOML出力処理においては,各キーおよびセクション名を適切にエスケープ・クォート処理し,プリミティブ値の多次元配列構造を保持して整形出力します.なお,TOMLにおけるnull値はどこに現れても未対応であり,また配列内にオブジェクトを含むデータも本ツールの制約として出力できずエラーとなります.
往復で失われる情報とデータ変換の非可逆性
異なる設定フォーマット間で相互変換を行う場合,各言語が持つ表現力や内部データモデルの差異に起因して,元のテキストが持っていた情報の一部が必然的に失われます.本ツールによる変換は,元のファイルと完全に一致する表現を復元する「完全可逆なラウンドトリップ」を保証するものではありません.
変換処理はすべて一度内部の共通データ構造へとマッピングされてから再シリアライズされるため,構文上の装飾やメタ情報は切り捨てられます.
第1に,コメント行の完全な消失が挙げられます.YAMLやTOMLに記述されていた全行コメント(# で始まる行)は,構文解析時にコメントとして読み飛ばされ,内部のデータツリーには格納されません.そのため,他のフォーマットへ変換した場合はもちろん,同一フォーマット間での再変換を行った場合であっても,元のファイルに記載されていた注釈や解説テキストは出力に一切反映されません.
第2に,数値型における語彙的表現および精度の変化です.JavaScriptの内部数値モデル(IEEE 754倍精度浮動小数点数)を介して処理されるため,TOMLにおいて整数として記述されていた値と浮動小数点数として記述されていた値の厳密な型区別や,1.000 といった末尾のゼロ表記,指数表記の形式などは保持されません.
出力形式側の標準シリアライズ規則に従って数値文字列が再構成されるため,フォーマット固有の数値表現は均一化されます.
キーの並び順,引用符の種類,インデントや空行などのスタイル情報は,各形式の標準的なエミッター規則に基づいて再構成されます.元のファイルと完全に同一のバイト列,コメント,数値表記,あるいはテキスト配置が維持される保証はなく,構文解析の段階でJSONの重複キーや極端な数値精度が失われる可能性もあります.
一部のキー順序やスタイルが偶然一致することはあり得ますが,元のテキストや値の完全な再現性を前提とせず,重要な設定ファイルは必ず元のファイルを保持してください.
設定移行前の確認手順と安全な運用のためのガイドライン
本ツールは,設定ファイルの構造を素早く移行するための補助ユーティリティであり,ブラウザ上で直感的に利用できるよう設計されていますが,出力結果を直接本番環境のサーバーや稼働中のアプリケーションへ即座に投入することは避けてください.予期せぬトラブルを防ぎ,安全に設定を移行するためには,変換前後に以下の運用手順と確認プロセスを踏むことが不可欠です.
変換作業を行う前に,移行元となる元の設定ファイルを必ず別の安全な場所にバックアップとして保存してください.変換対象のデータ内に本ツールが非対応としている構文(YAMLのアンカーやエイリアス,タグ,複数行文字列,TOMLの配列内オブジェクトやインラインテーブル,日時型など)が含まれている場合は,これらを無作為に削除するのではなく,完全な仕様に対応したパーサーやローダーの利用を検討してください.
手動で調整を行う場合は,対象アプリケーションが求める意味やデータ型が崩れていないか慎重に検証する必要があります.
変換が完了したら,出力テキストエリアの内容を必ず目視で点検し,配列要素やネストされたセクションの階層関係,数値や文字列の型が正しく保たれているかを確認してください.コピー操作はクリップボードへの実際の書き込み完了を待機して成否を判定し,出力内容が変化した際には直前のコピー完了表示が解除されますが,入力のたびに同期的にリセットされるわけではありません.
変換エラー時や出力が空の場合にはコピーや入れ替え操作が無効化され,エラー時に不完全な出力が残ることはありませんので,表示された現在の出力結果を正確に確認してください.
最後に,出力されたテキストをエディタ等に貼り付けた後,対象アプリケーションの正式な設定パーサーやリンター,スキーマバリデーターを用いてテスト環境で検証を行ってください.アプリケーション固有の型定義や必須キーが正しく認識され,想定通りに動作することを確認した上で,本番環境への適用を実施してください.