XMLビューアー
XMLビューアーは、ドキュメントを折りたたみ可能なツリーとしてブラウザ内で表示します。ツリーは仮想化されているため、大きなSOAPレスポンスやサイトマップも小さなものと同じ速度で開けます。さらに、属性は子要素とはっきり区別して表示されます。見慣れないXMLドキュメントを読めるようにしてくれるのは、まさにこの区別です。
XMLビューアーはどう動きますか？
20行のドキュメントのためにXMLビューアーを開く人はいません。開くのは、SOAPレスポンス、サイトマップ、SVG、Maven POM、そしてテキストとして読むには大きすぎ、テキストエディタの折りたたみ機能では追いきれないほどネストが深い設定ファイルです。したがって、本当に問うべきはただ一つ、サイズが大きいときに何が起きるかです。
ツリーは仮想化されているので、サイズはほとんど問題にならない
ありきたりな実装では、ノードごとにコンポーネントを1つ描画します。つまり5万ノードのドキュメントは5万個のDOM要素を生み出し、そのうち実際に見えているのは40個程度です。スクロールはカクつき、タブは数百メガバイトを消費します。このツールでは、まずドキュメントを行の配列に平坦化します。各行には深さと種類、そして部分ツリーの終端位置が記録されており、描画されるのはビューポート内の行だけです。ドキュメントがどれだけ大きくても、DOMが保持する要素は50個前後です。
部分ツリーの終端を記録しておくことが、折りたたみを低コストにしています。枝を隠すのはインデックス比較1回で済み、中身を一つずつたどる必要がありません。巨大なドキュメントのルートを折りたたんでも一瞬です。
属性は要素と分けて表示
XMLのメンバーには2種類ありますが、多くのビューアーは両者を混ぜて1つにしてしまい、<line sku="X"/>と<line><sku>X</sku></line>の区別が失われます。属性は@という接頭辞付きで表示されるため、どちらも保持され、片方がもう片方を上書きすることもありません。同じ名前の属性と子要素を両方持つ要素は、実際に使われるXML語彙ではよくあることなので、この区別は重要です。
検索は開いている部分ではなく、ドキュメント全体が対象
折りたたまれた部分ツリーの奥に埋もれている一致も見つけて表示します。対象までのパス上の先祖もすべて併せてです。パスのない値は、それがどこから来たのかを何も教えてくれないからです。
不正な入力は推測ではなく、名指しで報告
タグの対応の崩れや閉じられていない要素は、タグと行を特定したエラーとして報告されます。途中で切れたXMLは、ビューアーに貼り付けられる入力として最もよくあるものです。壊れているからこそビューアーにかけたくなるのですから。壊れたドキュメントからそれらしい表示を作り出すビューアーは、むしろ有害です。
整形ビューは独立した機能で、内容は失われません。テキストに手を触れずにインデントだけを付け直し、CDATA、コメント、処理命令、要素内のテキストをそのまま保ちます。
XML
<order id="1"><line sku="A" qty="2"/></order>
ツリー
▾ order { 2 }
@id "1"
▾ line { 2 }
@sku "A"
@qty "2"XMLビューアーが対応するオプションとエッジケースは？
| パラメータ | 型 | デフォルト | 動作とエッジケース |
|---|---|---|---|
| 仮想化 | 表示範囲のみ | — | 文書のサイズに関係なく、どの瞬間にもDOMに存在するのは約50行だけです。10 MBのSOAPログを開けるか、タブが固まるかの分かれ目です。 |
| 属性 | @プレフィックス | 表示 | 子要素と区別して扱います。sku属性とskuという子要素の両方を持つ要素では、一方が黙って勝つのではなく、両方が表示されます。 |
| テキストノード | #text | 表示 | 要素のテキストは要素に折りたたまれず、専用の行に表示されます。テキストと子要素の両方を持つ要素は、両方とも表示されます。 |
| コメント | #comment | 表示 | 保持されます。設定ファイルのコメントは、値がそうなっている理由を語る唯一のドキュメントであることが多いからです。 |
| CDATA | リテラル | — | そのまま表示します。CDATAセクション内の実体参照は実体参照ではない、というのがこの仕組みの要点です。 |
| 名前空間 | 保持 | プレフィックス維持 | soap:Bodyはsoap:Bodyのまま残り、xmlns宣言は属性として表示されます。除去できるのはXML→JSON変換ツールのほうで、これは表示ではなく変換の選択肢です。 |
| 検索 | 部分一致 | 大文字小文字を区別しない | 文書全体の名前と値が対象で、折りたたまれた枝も含まれます。一致したノードの祖先はすべて残るので、経路が見え続けます。 |
| 不正な入力 | エラー | 名前付き | 対応関係のないタグや閉じられていないタグは、タグ名と行番号付きで報告されます。入力中に画面が白くなるのではなく、解析できた最後の文書を木は表示し続けます。 |
| 入力サイズ | バイト | 8 MB | トークナイズ処理はメインスレッドで動きます。上限を超えると、タブを固める代わりにツールは処理を断ります。木そのものは、この上限よりずっと多くのノードを扱えます。 |
よくある質問
大きなSOAPレスポンスやサイトマップも開けますか？
8 MBの上限まで開けます。ボトルネックはツリーではありません。ツリーは画面に見えている部分だけを描画するため、ノード数の影響はほとんど受けません。上限を決めるのはトークナイザーです。トークナイザーはメインスレッドで動作しており、8 MBを超える入力は試みるのではなく拒否します。試みればタブが数秒間固まってしまうからです。
@で始まる行があるのはなぜですか？
@で始まる行は属性です。XMLには属性と子要素という2種類のメンバーがありますが、JSON形式のツリーにはメンバーの種類が1つしかないため、属性を区別できるように接頭辞を付けています。接頭辞がなければ、sku属性とsku子要素を両方持つ要素には片方しか表示されず、どちらなのか見分ける手段がなくなります。
ここでXMLを編集できますか？
テキストペインは編集でき、ツリーもそれに追従しますが、ツリー自体は読み取り専用です。読み取り専用に保っているからこそ、編集可能なツリーが苦戦するようなドキュメントでも高速を維持できます。編集可能なツリーは、キー入力のたびに2つの情報源を突き合わせて調整しなければならないためです。インデントの付け直しには、整形ビューか「XML整形」を使ってください。
ドキュメントが不正なのに、ツリーに何かが表示されるのはなぜですか？
最後にパースに成功した状態を表示しているためです。編集中の一打鍵で表示全体が空白にならないようにするための動作です。エラーバナーには、対応が取れていないタグまたは閉じられていないタグと、その行が示されます。ドキュメントが再びパースできるようになると、ツリーは更新されます。
整形ビューを適用するとドキュメントは変わりますか？
変わるのは要素間のホワイトスペースだけで、それ以外は何も変わりません。テキスト内容、CDATAセクション、コメント、処理命令、属性値はバイト単位でそのまま保たれます。ただし、要素間のホワイトスペースは厳密なXMLパーサーには意味を持つため、インデントを付け直した後のドキュメントは、機械にとっては元のドキュメントと常に交換できるとは限りません。交換できるのは人間にとってだけです。
XMLはアップロードされますか？
いいえ。トークン化も描画も、すでに開いているタブの中で行われます。DevToolsを開いてNetworkパネルを見ながら貼り付けてみてください。XMLは他の多くの形式以上にこの点が重要です。人が実際に読む必要があるのはSOAPの通信内容、SAMLアサーション、金融メッセージであり、開発者が扱う中でも最も機密性の高い情報の一部だからです。