Excel(MS365): VBAコードはどう実装されているか

.xlsxと.xlsmのファイル上の違いは何か。

これは単純に、新規作成したファイルを.xlsxと.xlsmのそれぞれで連続新規保存して見比べてみればわかります。

別々に新規作成しちゃいけません。作成日時などの値が変わっちゃうので相違点が増え、見比べにくくなります。

保存した各ファイルの拡張子を.zipに変えて展開し、WinMergeなどのDiffアプリでフォルダごと見比べればいいんですね。

結果、\[Content_Types].xmlのひとつ目の<Override>タグ内のContentTypeアトリビュートが、

  • .xlsxでは "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet.main+xml"
  • .xlsmでは "application/vnd.ms-excel.sheet.macroEnabled.main+xml"

になっているだけですね。あとdocumentIdなんかも変わっていますが、こっちかまあ無視してもいいや。

openxmlformatsはISO/IEC 29500:2008で定義されているOfficeOpenXMLファイルフォーマットに基づいていますが、ms-excelはもう完全にExcelローカルだよーと宣言しちゃっているわけです。

まあVBAコードなんか含めちゃうとドキュメントの規格からは完全に外れちゃうので、宣言部分で「別もんだからねー」と言ってるってことなんでしょうね。

ーーー

で、VBAコードはどう格納されているかというと。

先ほど新規作成直後に保存した.xlsmファイルにちょっぴりVBAコードを記述して保存し直すと、xlフォルダ内が変化します。

まず、vbaProject.binファイルが増えます。ここに記述したVBAコードが格納されるんですね。

あと、同じxlフォルダ内のworkbook.xmlが変化します。<fileVersion>タグにcodeNameアトリビュートが追加され、GUID(UUID?)が振られます。

vbaProject.binの内容は、どのモジュールにどんなコードが記述されているかとか、参照しているライブラリは何かとかそんな感じで。

あと、コンパイルかけるとコンパイル後の中間コードも保存されるようです。

具体的に何がどう格納されているかについては、

[MS-OVBA]: Office VBA File Format Structure | Microsoft Docs

で提供されている[MS-OVBA].pdfで説明されていますね。

理屈で言えば、フォーマットがわかればVBAソースの復元→再度.xlsmへの格納が可能になるはずなので、Excel VBEを使わない開発環境の構築も可能なはずなんですが。
VBEを離れると動作確認(特にステップ実行やブレークポイント)やイミディエイトウィンドウでの単コマンド確認とかの実装が超難しいので、あまり現実的ではないかも。

外部開発環境からVBEを制御できればあるいは、とも思いますが。

0 件のコメント :

コメントを投稿