XMLフォーマッター & 構文検証ツール

本ツールは，入力されたXMLテキストをブラウザの標準APIである DOMParser（application/xml 指定）を用いて構文解析（well-formedness検証）します．パーサーを呼び出す前の事前検証として，入力サイズが上限である100,000 UTF-16コード単位（code units）を超えていないかのチェックが行われ，同時にDOCTYPE宣言（<!DOCTYPE ...>）の存在が検知された場合は解析前に即座に処理が拒否されます．

構文解析時に入力データが整形式（well-formed）を満たさない場合，Mozilla系の予約されたエラー名前空間だけでなく，WebKit等では部分解析ドキュメント内にXHTMLのparsererrorパネルが挿入される挙動が確認されています．そのため共有コアでは，単にparsererrorというタグ名だけで判定するのではなく，Mozillaのエラー名前空間と，既知のWebKit/Blink系XHTML生成エラーパネル（名前空間，スタイル指標，2つのエラー見出しを含む構成）の両方を厳格に検出して拒否します．

名前空間のみですべてのブラウザを網羅できるとは想定せず，既知の生成パネル判定も保守的であるため，類似構造や全環境での検知は保証されません．なお，名前空間のない通常要素や，生成パネル指標を持たない通常のXHTML parsererror要素は有効なデータとして受容されます．

解析失敗時は生のエラーHTMLや行番号を露出させず，部分的な出力も行わずに局所化された汎用エラーを提示します．

構文エラーが検出された場合，UIにはブラウザ固有の実装差がある行番号や列番号の生情報ではなく，統一された汎用エラーメッセージが明瞭に表示されます．また，ネイティブDOM解析が成功した後にも厳格なリソース上限ガードが適用され，XML階層の最大深さ（depth）64，ルート要素が単一（root 1つ）であること，属性ノードを含めてカウントした総ノード数が20,000ノード以下であること，さらにシリアライズ後の出力が2,000,000 UTF-16コード単位以内であることが順次検証されます．

これらの上限を超過した場合は安全のため処理が中断されます．本ツールはWebWorkerを用いずにメインスレッド上で動作するため，極端な高負荷入力に対する処理時間やブラウザの完全なフリーズ回避を保証するものではありません．エラー発生時は不正な出力結果が画面に残らないよう即時に非表示化されます．

構文解析と各種ガードチェックを通過したXMLドキュメントは，要素の階層構造に基づいて視覚的なインデントが付与されます．インデント幅はUI上のセレクトボックスから「2スペース」「4スペース」「8スペース」の3種類を選択して指定することが可能です．タブ文字によるインデント挿入には対応しておらず，半角スペースによるインデント処理に統一されています．

本ツールのインデントアルゴリズムにおける極めて重要な特徴は，既存のテキストノードに対する保護方針です．ある要素が直接の子ノードとして空白文字のみで構成されるテキストノードやCDATAセクションを含む場合であっても，直接のTextノードまたはCDATAが1つでも存在する要素については，その内部に対するスペースの挿入や既存空白の再インデント，置換，フィルタリングを一切行いません．

そのような要素は XMLSerializer を用いて要素全体がそのままシリアライズされます．既存の空白や改行を安全に保つための設計であり，勝手な空白整形によるテキストデータの破損を防止します．

新たなインデント（2・4・8スペース）と改行文字が付与される対象は，子ノードにTextノードやCDATAセクションが一切存在しない「純粋な要素のみを含む分岐（text-free branches）」に限定されます．DOMツリーの再帰的走査において，テキストを含まない親要素の配下にある子要素群に対してのみ，深さに応じたスペース文字列が行頭に計算されて付与されます．

これにより，構造的なタグの階層関係のみを綺麗に整列させつつ，テキスト内容に含まれる重要な空白情報を完全にそのまま温存することが可能となっています．

DOMツリーの各ノードをXML文字列へと再構築するシリアライズ処理には，ブラウザ標準の XMLSerializer が利用されます．このAPIを経由することにより，DOMツリー内の要素構造，属性値，コメントノード（<!-- -->），処理命令（Processing Instructions: <?...?>），および CDATA セクションがブラウザの標準仕様に準拠した形式で忠実に保持され，適切に出力文字列へと書き戻されます．

属性値やテキストノードに含まれる特殊記号（<，>，&，"，' など）は，XMLSerializer のシリアライズ仕様に基づいて標準的なエンティティ参照（&lt;，&amp; など）へとエスケープされます．ただし，元のXMLソースに記述されていた引用符の種類（シングルクォートかダブルクォートか）の完全な一致や，数値文字参照・エンティティ参照の記述形態，元のバイト列との完全一致は保証されません．

また，本ツールの出力生成においては，不自然なエスケープの混入を防ぐため，引用符の直前に不要なバックスラッシュを挿入するような特殊な加工は一切排除されています．

なお，DOCTYPE宣言については前述のとおり入力段階で拒否されるため，シリアライズ対象として出力に現れることはありません．本ツールはブラウザ標準の DOMParser および XMLSerializer を用いてDOMツリーを構築・再出力する仕組みを採用しています．

構文解析時に改行コードの正規化や属性値空白の処理が行われ，シリアライズ時にもタグの記述形式や属性順序などがブラウザ仕様に準じた形へ再構成されるため，入力元の字句表現やバイト列と完全一致する出力が得られるわけではありませんが，定義された構文木に基づいた明確な変換スコープで処理されます．

XMLの取り扱いにおいて特に繊細な配慮が求められるのが，同一の親要素内にテキストノードと子要素ノードが混在する「mixed content（混合内容）」や，直接テキストを含む要素の扱いです．たとえばHTML/XHTMLの <p> タグ内にプレーンテキストと <strong> などのインライン要素が同居しているケースや，コード片などを保持する要素がこれに該当します．

本ツールのフォーマッター実装では，対象要素の直接の子ノードを走査し，空白文字のみのノードを含めて何らかの直接のTextノードが存在するか，あるいはCDATAセクションが含まれているかを厳格に検査します．これらが1つでも検出された場合，その要素全体は内部インデントの追加対象から完全に除外され，XMLSerializer によって内部の空白・改行・文字の並びが一切変更されることなくそのままシリアライズされます．

余分な空白や改行を挿入してしまうと，文書の表示結果やパース後の文字列値が変化してしまうリスクがあるためです．

既存の空白テキストノードを間引いたり，内部の改行位置を揃え直すような再インデント処理は行われません．要素にxml:space="preserve"が指定されている場合だけでなく，タグ間に改行やインデントとしてのみ存在する空白テキストノードが含まれている場合であっても，要素が直接のテキストノードやCDATAを持つ階層ではインデント付与処理自体がバイパスされます．

インデントの追加処理は，直接のテキストを一切含まない要素に対してのみ適用されます．これにより解析後のDOMデータとしてのテキスト内容は保持されますが，入力元と同一の生バイト列や字句表現をそのまま復元することを保証するものではありません．

本ツールには，インデントを付加して構造を読みやすくする整形機能に加えて，データサイズを削減するための「圧縮（Minify）」機能も備わっています．UI上で圧縮を指定した場合，各要素間に新たなインデント用スペースや改行文字を一切付加することなく，要素ノードが連続して出力されるコンパクトなXML文字列が生成されます．

この圧縮処理において最も留意すべき点は，要素内の既存テキストに含まれる空白文字（インデントや改行文字を含む）は決して削除されないという点です．ルート要素の外側に存在するドキュメントレベルのセパレータ（余分な空行など）は除去される場合がありますが，圧縮によって要素間の空白テキストが網羅的に圧縮・除去されると主張するものではありません．

前述のとおり，直接テキストノードが存在する要素内部の空白は手つかずのまま維持されます．

また，コメントノード，CDATAセクション，処理命令（PI）についても圧縮処理によって勝手に間引かれたり破棄されたりすることはなく，そのまま出力内に保持されます．極限まで無条件にバイト数を削るような非可逆の圧縮ではなく，XMLとしての文法構造と文書内に含まれる既存のテキスト空白の完全性を損なわない範囲でのコンパクト化を実現しています．

本ツールの整形結果や圧縮結果をシステムや連携処理で扱う際は，ツールが前提とする変換仕様と技術的制約を把握しておく必要があります．第一に，XMLデジタル署名（XML Signature）が付与されたドキュメントについてです．署名の検証結果は署名対象範囲（SignedInfoや参照要素）の指定方法および正規化アルゴリズム（Canonical XML規則など）の適用状況に依存します．

本ツールではテキストを持たない要素階層へのインデント追加や，XMLSerializerによる改行コードの正規化，属性の出力順序，空要素タグの表記変更などが発生するため，これらのシリアライズ結果が署名対象の生バイト列や正規化結果に影響を与える場合があります．署名検証が完了していない原本データには適用せず，必ず元の署名付きデータを保管した状態で使用してください．

第二に，スキーマ検証と宣言の取り扱いです．本ツールはDOMParserによる整形式（well-formedness）の確認のみを実行し，外部DTDやXSD（XMLスキーマ），XPath式やXSLT変換を用いた構文・妥当性検証には対応していません．入力データの先頭に存在するXML宣言（<?xml version="1.0" ...?> など）は正規表現を用いて抽出され，整形後の出力先頭に文字列として保持されます．

ただし，この処理は宣言文字列の抽出に留まり，XML宣言内の encoding 属性（Shift_JISやEUC-JPなど）に応じた実際の文字エンコーディングのバイト変換処理は行われません．JavaScriptの実行環境上では常にUTF-16文字列としてメモリ内で処理され，クリップボードへのコピーやファイル保存時の文字コードは利用者の実行環境に依存するため，文字コード変換を前提としたパイプラインでは事前の変換確認が必要です．

第三に，クリップボードへのコピー操作についてです．フォーマット結果のコピー処理は非同期の Clipboard API（navigator.clipboard.writeText）の完了を待機（await）して実行され，書き込みが失敗した場合にはUI上でエラーが明瞭に通知されます．

構文エラーやサイズ超過などの検証エラーが発生した状態では，不正な結果がクリップボードに送られたり画面に表示されたりすることはありません．

最後に，処理性能と安全性の境界についてです．本ツールは入力時点で100,000 UTF-16コード単位，DOM解析後に最大深さ64，最大20,000ノード，出力2,000,000 UTF-16コード単位という厳格なガードを設けていますが，WebWorkerを用いないブラウザのメインスレッド実行であるため，極端に複雑なデータにおけるメモリ消費やブラウザの一時的な応答遅延を完全に皆無にできる保証はありません．

仕様上の制限を十分にご理解の上，安全にご利用ください．