今回は文書に添付したファイルについて整理します。調査で使用するのは、リッチテキストにテキストファイル（Sample.txt）だけが添付されている単純な文書を使用します。
リッチテキストフィールドと添付ファイル
この文書を DXL に変換して、リッチテキストフィールドの中を確認すると、次のようになっていました。
最初に気がつくのは、attachmentref ノードです。name 属性に添付ファイル名がセットされているので、添付ファイルであることは間違いないですね。
attachmentref ノードの配下には picture ノードがあります。添付したファイルはテキストファイルなので変ですね。ただ、ノード全体を見ると気がつくことがあります。
赤枠で囲った部分は、前回紹介した画像を表す DXL となっていますね。
画像に添えられたテキストである caption ノードにファイル名が指定されていて、その上に画像データらしきものが存在します。逆にこれ以外のノードは存在しませんので、attachmentref ノード内には添付ファイルのアイコンの情報しかないということになります。
添付ファイルの実体
DXL 全体を見ると添付ファイルの実体を発見できます。リッチテキストフィールドを表す item ノードを省略表示するとその下にもう一つ item ノードが存在します。
フィールド名は "$FILE"。どこかで見たことがありますね。
これは添付ファイルのある文書をプロパティで参照した際に表示される特殊なフィールドです。文書のプロパティと同じ構造なので、これはこれでわかりやすいですね。
添付ファイルの実体は、filedata ノード配下にあります。画像データと同様で、ファイルの実体を Base64 でエンコードした文字列として出力されます。この文字列をデコード、バイナリデータとしてファイル保存すれば、添付ファイルのダウンロードができます。
まとめ
今回は添付ファイルの基本的な構造をまとめました。
リッチテキスト内には添付ファイルの実体ではなく、アイコン情報が入っています。添付ファイルの ”参照” となるので、ノード名は attachmentref ということなんですね。
また、添付ファイルのアイコンはインラインイメージで構成されていました。ファイル名は画像のプロパティの見出しを活用して表現されています。リッチテキスト内の要素をうまく部品化して再利用しているのが面白いですね。
| 前回 | DXL Step-by-Step |
0 件のコメント:
コメントを投稿