Corredor

ウェブ、プログラミングの勉強メモ。

JScript と WSH と JScript.NET と .NET Framework と

Windows で何かスクリプトを作るとなると、MS-DOS 上がりのコマンドプロンプトではイマイチ勝手が悪い時がある。PowerShell を使う手もあるが、実行するために環境設定が必要だったり、独特な言語仕様を勉強するコストが割とかかり、学ぶ気のない人には引き継げない。

そうなると、VBA や VB6 などの経験がある人は VBScript で、フロントエンドに明るいタイプの人には JavaScript によく似た言語仕様の JScript で、それぞれスクリプトを書くことになる。

んで、今回はそのうちの JScript について、最近 JScript.NET というものを知ったので、このあたりの内容をまとめてみる。

VBScript と JScript を動作させる環境が Windows Script Host

コマンドプロンプトよりちょっと高級なスクリプトが書ける、WSH って何だったのよ、という話。

Windows Script Host と呼ばれるものは、スクリプトの実行環境を指す。そして、どんな言語でスクリプトを書くか、というところで、標準サポートされているのが VBScript という言語と、JScript という言語、というワケ。両方とも Microsoft 製の言語なので、Windows OS 上、そして IE 上など、実行環境を意識することなく使えるような作りになっている、というワケだ。この「別け隔てない」感じが、混乱を招いているような気がする。

グラフィカルに動作するのが WScript (WScript.exe) で、コマンドライン上で動作するように最適化されているのが CScript.exe だ。例えば、以下のような VBScript (.vbs ファイル) があったとして、

' sample.vbs
WScript.Echo "ほげほげ"

これをコンソール上から

Wscript sample.vbs

と呼ぶと、画面上にダイアログボックスが表示されるが、

CScript sample.vbs

と呼ぶと、コンソール上にメッセージが表示される。

ただし、VBScript が持つ MsgBox 関数を使ったとしたら、これは CScript でもダイアログボックスが表示される。あくまで WSH が提供する機能の現れ方が、WScript と CScript で異なる、ということだ。

ちなみに、サードパーティ製だと、Perl が動作するようにする動作環境 (スクリプトエンジン) もあるみたい。

.NET Framework の登場と VB.NET・JScript.NET

Microsoft は共通言語基盤という考え方を進めていくため、.NET Framework という開発・実行環境を作った。あらゆる言語で作られた言語を共通中間言語にコンパイルすることで、コードが特定のプログラミング言語やプラットフォームに依存しないようにするという仕組みだ。WSH がやりたかったことを拡大解釈した機構、といったところか。

C#、PowerShell、VB.NET などが、.NET Framework を基盤として動作する言語としてよく知られているが、Java を .NET Framework 上で動作するように移植した J#、PHP が動作する Phalanger、Python が動作する IronPython、Ruby が動作する IronRuby などもある。これらは全て、それぞれの言語で書いた既存のコードはほぼそのまま動作する上に、.NET Framework が用意するクラスライブラリを使うことができるワケだ。

JScript.NET もその流れの1つである。Microsoft 製の JScript が .NET Framework 基盤に乗った仕様、ということだ。

WSH で動く JScript と、JScript.NET の違い

では、JScript と JScript.NET で何が違うか、というと、簡単にいえば、WSH が提供していた機能は使えなくなる。例えば先述の WScript.Echo("文字列"); は、JScript.NET では使えない。代わりに、import System; 文で System をインポートし、Console.WriteLine("文字列"); と書くことになる。ちなみに、print("文字列"); であれば、JScript の組み込みなので、JScript.NET に移植する際もそのまま使える。

WScript.sleep() なども同様だ。実行環境 (WSH か .NET か) が異なるので、実行環境に依存した構文はどうしても影響を受ける。WSH を使っていたが、.NET Framework は知らない、という人は移植のために勉強が必要になるだろう。

また、JScript.NET をどう実行できるようにするか、というところで、大きな違いがある。WSH 上の JScript の場合、.js ファイルを関連付けしておけば、ファイルのダブルクリックで実行可能であった。これに対し、JScript.NET は jsc でのコンパイルが必要なのだ。

Rem .NET Framework のフォルダにある jsc.exe を使用してコンパイルする
C:\Windows\Microsoft.NET\Framework\v4.0.30319\jsc.exe sample.js

こうすると、sample.js と同じ階層に sample.exe が出来上がるので、これを実行する。

ちなみに、JScript.NET をコンパイルする jsc.exe の他にも、VB.NET をコンパイルする vbc.exe、C# をコンパイルする csc.exe なども、.NET Framework のインストールフォルダ内に置いてある。言語が違うだけで使い方は同じなので、気になる人は調べてみるといい。

JScript.NET の認知度の低さ

さて、C#、VB.NET など、.NET Framework を基盤とする代表的な言語と比べて、Microsoft 製の言語なのになぜ JScript.NET の認知度が低いのか。

一つの原因は、JScript は Visual Studio (IDE) での開発に対応していないのだ。代表的な開発環境がなく、なぜか jsc.exe が放り込まれているだけなので、その存在もあまり知られていなかったりする。

もう一つは、ベースとなる JavaScript という言語の標準を策定しているのが、Ecma International という別の団体 だからであろう。Visual Basic も C# も Microsoft 製の言語だが、ECMAScript・JavaScript はそうではないため、あまり手厚く見てもらえていないのかもしれない。VB の元となっている BASIC や、C# の元となる C よりも歴史が浅く、ブラウザベースの言語として発展してきた経緯もあり、スクリプト言語としての利点がそんなにない気もするし。

そんなワケであまり陽の目を見ない JScript と JScript.NET だが、JavaScript から入った人間は VB 系の言語仕様にイマイチ慣れないこともあり、なんだかんだとこの陰キャラを愛している、のかもしれない。

参考

Windows自動処理のためのWSHプログラミングガイド

Windows自動処理のためのWSHプログラミングガイド