【VBScriptの深淵】FSOでUTF-16LEを完璧に操る：文字化け撲滅のための「Format引数」完全攻略
業務自動化の現場で、VBScriptは今なお強力な武器だ。しかし、多くのエンジニアが「文字化け」という見えない敵に屈し、ADODB.Streamへ逃げ出すか、力技の文字コード変換でコードを汚染している。
断言しよう。`Scripting.FileSystemObject (FSO)`の`OpenTextFile`メソッドは、仕様を正しく理解さえすれば、Unicode（UTF-16LE）を扱うのに最も軽量で高速な選択肢となる。
今日は、FSOの`Format`引数を掌握し、二度と文字化けで頭を抱えないための「堅牢な設計」を伝授する。
—
1. なぜ「OpenTextFile」は文字化けするのか
`OpenTextFile`のシグネチャを思い出してほしい。
Set objFile = objFSO.OpenTextFile(filename, iomode, create, format)
この最後の `format` 引数こそが、Unicodeの運命を握っている。多くのプログラマはここを省略する（デフォルト値 `TristateFalse`）が、これが悲劇の始まりだ。
- TristateFalse (-2): システムのデフォルト（通常はANSI/Shift-JIS）。Unicodeファイルを読み込むと、バイト順マーク（BOM）が制御文字として誤認され、先頭が化けるか、データそのものが破壊される。
- TristateTrue (-1): Unicode（UTF-16LE）として強制的に開く。 これこそが我々が求めている設定だ。
- TristateUseDefault (-2): システム依存。業務アプリでは論外である。
2. 現場で使える「堅牢な読み書き」設計
実務において、単純に開くだけでは不十分だ。「ファイルが存在しない場合」「ロックされている場合」「BOMの有無」を考慮したラッパー関数を設計せよ。
以下は、プロダクション環境でもそのまま使える、UTF-16LE対応のファイル操作パターンだ。
【実装コード例】Unicodeファイルを安全に操作するクラス設計
‘ FSOを利用した堅牢なUnicode操作ユーティリティ
Class FileHandler
Private fso
Private Sub Class_Initialize()
Set fso = CreateObject(“Scripting.FileSystemObject”)
End Sub
‘ UTF-16LEで書き込む
Public Sub WriteUnicodeFile(filePath, textContent)
Dim ts
‘ TristateTrueを指定することでUTF-16LEとして保存される
Set ts = fso.CreateTextFile(filePath, True, True)
ts.Write textContent
ts.Close
End Sub
‘ UTF-16LEとして読み込む
Public Function ReadUnicodeFile(filePath)
Dim ts
If Not fso.FileExists(filePath) Then
Err.Raise 53, , “ファイルが見つかりません: ” & filePath
End If
‘ 最後の引数に -1 (TristateTrue) を与えることが極意
Set ts = fso.OpenTextFile(filePath, 1, False, -1)
ReadUnicodeFile = ts.ReadAll
ts.Close
End Function
End Class
‘ — 利用例 —
Dim handler: Set handler = New FileHandler
Call handler.WriteUnicodeFile(“test.txt”, “VBScriptでUTF-16を制する”)
WScript.Echo handler.ReadUnicodeFile(“test.txt”)
3. なぜADODB.StreamではなくFSOなのか
「ADODB.Streamを使った方が文字コード指定が柔軟ではないか？」という意見があるだろう。確かに、UTF-8やShift-JISを細かく指定する場合はStreamが有利だ。
しかし、「Windows標準機能のみで完結する」「メモリ消費量が圧倒的に少ない」という観点では、FSOの`TristateTrue`に勝るものはない。特に大量のログファイル解析や、シンプルな設定ファイルの読み込みにおいて、オブジェクトのオーバーヘッドを最小化することは、スクリプトの実行速度に直結する。
4. 業務自動化エンジニアへの警告と提言
最後に、プロフェッショナルとして一つ釘を刺しておきたい。
1. UTF-8との混同を避けよ: `TristateTrue`はあくまで「UTF-16LE」である。現代のWebAPI連携などで主流の「UTF-8（BOMなし）」を読み込む場合、FSOでは文字化けする。その時は、素直に`ADODB.Stream`の`Charset = “UTF-8″`を使用せよ。使い分けこそがエンジニアの矜持だ。
2. エラーハンドリングを怠るな: `On Error Resume Next`をただ書くのはアマチュアの所業だ。ファイル操作は必ず失敗する前提で設計し、`Err.Number`をチェックする習慣をつけろ。
3. BOMの呪縛: UTF-16LEはBOMがあることが前提のフォーマットだ。もしBOMなしのUTF-16ファイルと遭遇したら、FSOではお手上げとなる。その場合はバイナリレベルでの処理が必要になることを忘れるな。
結論
FSOは古い技術ではない。正しく理解し、適材適所で使いこなすことで、今なお最も堅牢で高速な自動化基盤となる。`Format`引数の `-1`。この小さな定数が、君のスクリプトを「おもちゃ」から「プロダクションコード」へと進化させる鍵となるはずだ。
さあ、今すぐコードを書き換え、文字化けの呪縛からプロジェクトを解放せよ。
