HTA バージョンの JSMin (一部の修飾子を省略) は、JavaScript 言語_JavaScript スキルに基づいて作成されています

以前に JSMin を使用したときは、http://fmarcia.info/jsmin/ から実行ページを開き、そこに独自のコードを貼り付け、重み付けされたコードをテキスト編集ツールにコピーして保存していました。

時間が経つにつれて、これは本当に面倒だと気づきました。私たちはプログラマーなのですから、自分たちで物事をもっとシンプルにしてみませんか？

そこで私は「フレンドリーな」JSMin の仕事を始めました。

「友好的な」作業の過程で、「当然のことながら」いくつかの予期せぬ問題に遭遇し、最終的にどのような問題が発生したか、そしてそれをどのように解決するかについてお話します。

でも、すべての問題が解決してから記事にしようと思ったので、今回は「写真なし、真実なし」ですみません。



説明を始める前に、この質問に関連する技術的な知識について説明します。Windows Script Host のプログラミング経験がある場合は、この部分をスキップしてください。 ASP の使用経験がある方は、このセクションにはすでにご存知の内容も含まれているかもしれません。

Windows スクリプト ホスト (WSH) は、いくつかの実行可能ファイル (wscript.exe および cscript.exe) として表示される Windows スクリプト ホストであり、インターネット セキュリティ ポリシーまたはタスクによって制限されずに JScript を実行することです。一部のシステム管理作業を実行するために VBScript で記述されたファイル。デフォルトでは、Windows では .js 拡張子を持つファイルは WSH ファイルとみなされます。.js ファイルをダブルクリックしようとすると、エラー メッセージが表示されたり、ウイルス対策ソフトウェアによって傍受される可能性があります。
HTML アプリケーションは、名前が示すように、「HTML アプリケーション」です。Windows スクリプト ホストとの違いは、HTML アプリケーションは、より良いグラフィカルインターフェイスを備えています。基本的に、HTA ファイルは実際には特別な拡張子が付いた HTM ファイルです。インターフェイスの作成にあまりエネルギーを費やしたくない場合、HTML と WSH の両方の経験がある場合は、HTML アプリケーションを使用して問題を解決します。問題はかなり悪い選択ではありません。 HTML アプリケーションは、多くの場合、WPF テクノロジの前身であると考えられていることに注意してください。ターゲット環境が WPF サポート (つまり、.NET Framework 3.0) を備えている場合は、WPF を使用する方が適している可能性があります。 HTA ファイルは簡単に作成できるため、かつてはトロイの木馬のダウンローダーとして使用されていましたが、現在でも一部のウイルス対策ソフトウェアは HTA ファイルをトロイの木馬のダウンローダーとして大まかに判断する場合があります。 .exe などのバイナリ実行可能ファイルと同様に、HTA ファイルが有害かどうかは、ファイルの種類ではなく、そのファイル自体の設計によって決まります。
FSO と呼ばれる FileSystemObject は、スクリプトによるファイル システム操作の実行を容易にするために Windows スクリプト テクノロジで提供されるコンポーネント オブジェクトです。これは、ASP プログラミングでも非常に一般的です。
WshShell は、スクリプトがシェル関連オブジェクトを操作するのを容易にするために、WSH 実行環境によって提供されるコンポーネント オブジェクトです。
ADODB.Stream (「ADO Stream」とも呼ばれる) は、バイナリ データ ストリームの操作を容易にするために ADO で提供されるコンポーネント オブジェクトですが、ファイル操作など、データベース以外の場所でもよく使用されます。


「ファイルアイコン上でマウスをクリックするだけ」などの機能は、「シェル関連付け」などと呼ばれ、多くの場合、シェル関連付けは「マウスと関連付けられる」と理解されています。クリック」とか。しかし、少し注意してみると、マウスの右ボタンをクリックしてポップアップするショートカット メニューには、デフォルトのコマンドに加えて、「編集」や「印刷」などのコマンドがあることがわかります。

今回行う必要があるのは、.js ファイルに「最小化」命令を追加することです。この命令をクリックすると、ECMAScript コードの軽量化のために JSMin が開始されます。

ここで最初の問題に遭遇しました。

.js ファイル (実際には WSH タスク ファイル) を作成し、それを使用してインストールを「自動化」しました。

Windows で .js ファイルにファイルの関連付けを追加するには、「JSFile」の下のシェル キーにサブキーを追加する必要があります。HKCR.js レジストリの「デフォルト」値に対応する HKCRJSFile キーです。キーと Command という名前の依存サブキー。

HKCRJSFileShell の下に Minimize 項目を追加し、Command サブキーに「My hta file path "%1"」値を設定した後、この Minimize コマンドを使用すると「正当な実行可能ファイルではありません」エラーが生成されることがわかりました。で、開始コマンドを前に追加すると、「プログラムから開く」ダイアログボックスが表示されます...

Shell項目の下ではあまりご都合主義はできないようなので、読むしかありませんでした最初に htafile ファイル タイプを設定し、次に新しく追加された Minimize 命令に設定します。 .js ファイルは次のように記述されます:

Copy code コードは次のとおりです:

view sourceprint?1 var asocCommand = wshShell.RegRead("HKEY_CLASSES_ROOT\htafile\Shell\Open\Command\").replace("%1 " , instPath "\" appExec).replace("%*", '"%1"');

シェル関連の問題は解決されたばかりですが、次にコマンド ライン パラメータの解析の問題があります。

当初、このガジェットのキャリアとして WSH タスク ファイルを使用する予定でしたが、すぐに使用できなくなりました。 WSH ファイルにはデフォルトで UI サポートがないことがわかりました。JScript で記述された WSH タスク ファイルには、VBScript の InputBox とプロンプトが存在しません。WSH を使用する場合は、Windows コンソールからのみユーザー入力を取得できます。そして、コンソールからユーザー入力を取得する場合、このツールの標準的な使用プロセスは、「マウスでファイルアイコンをクリック→ショートカットメニュー→最小化→キーボードで文字入力」という一連のマウス操作になります（もちろん、キーボード操作も可能です）を使用してから、突然キーボードに切り替えると、うまくいかないようです。

したがって、このツールを実装する方法として、リッチなインターフェイスを提供できるファイル タイプである HTA を使用することにしました。

HTA を選択すると、コマンド ライン パラメーターの解析に使用される "Arguments" オブジェクトがなくなるなど、WSH の "外部送信なし" 機能の一部も失われます。

私の考えでは、-level パラメータで JSMin のコード削減レベルを指定し、-silent パラメータでプロンプト情報をオフにできるはずです。これらのパラメータをコマンド ラインから解釈できない場合、これらの機能は実装されません。

そこで、2 つの関数を作成しました:

コードをコピーします コードは次のとおりです:

//========//========
// コマンドライン情報を解析
// HTA のコマンドラインから解釈します環境 実行される HTA の実際のパスと追加パラメータ
// コードのこの部分はもともと NanaLich によって作成されたもので、いかなる状況でも書面による許可なしで直接使用できます。あなたまたはあなたの所属機関が許可なくコードを作成したと主張してはなりません。また、許可なく NanaLich の名前で修正版を公開してはなりません。
//========//========
functionnamedOrNot(args) {
varnamed = {}, not = [], for(var i = 0; i c = args[i]
switch(c.charAt(0)) {
case "-":
case "/":
c = c.substring(1);
if(c.indexOf("=") > 0) {
c = c.split("=") ;
named[c.shift()] = c.join("=");
} else if(c.indexOf(":") > 0) {
c = c.split (":");
named[c.shift()] = c.join(":");
} else {
// 名前付きパラメータも受け入れるかどうかを判断することはできませんこれは未解決の問題です
//i;
named[c] = args[i 1];
default:
not.push( c);
break;
}
}
args.named = 名前付き;
}
関数 parseArgs(str) {
var a = [], q = false, c = "", $ = "";
関数 mit() {
if(c)
a.push(c); 🎜>for (var i = 0; i $ = str.charAt(i);
if($ == '"') {
q = ! q;
} else {
if($ == " " && !q) {
c = ""; else {
c = $ ;
}
}
mit();
namedOrNot(a);
}
//====== =// ========


このように、HTA:Application オブジェクトの commandLine 属性がこの関数に渡されている限り、解析後の名前付きパラメーターと名前なしパラメーターは次のようになります。が得られる。



コマンド ライン パラメーターの問題を解決したら、次のステップはファイルのエンコードです。

実際の Web 開発プロセスでは、さまざまな理由により、「Unicode 以外の地域エンコード」や「Unicode (UTF-16) エンコード」以外のエンコード形式を使用する場合があります。 ) ビッグエンディアン」および「UTF-8」エンコード方式。

既存のテキスト編集ツールを使用してコードをコピーして貼り付ける場合、ファイルを保存するときにエンコード タイプを選択するだけで済みますが、現在は「開いてコピーして貼り付け」の必要性を排除する方法を設計しています。 「コピー＆ペースト＆保存」は非常に面倒な操作手順を伴うツールです。このツールには、エンコードの種類に自動的に適応する機能を設計する必要があります。

残念ながら、私のテストでは、FSO も ADODB.Stream もテキスト エンコーディングを自動的に識別する機能がありません。他の方法を見つける必要があります。幸いなことに、VBScript は HTA でデフォルトでサポートされています。バイト グループを直接操作する関数ですが、VBScript の文字列としてバイト グループを操作しても、ある程度の要件を満たすことができます。

そこで、次の関数を書きました:




コードをコピーします


コードは次のとおりです:

Function vbDetectFileEncoding(fn)
Dim Stream、B3
Set Stream = CreateObject("ADODB.Stream")
Stream.Type = 1
Call Stream.Open()
Stream.LoadFromFile(fn) を呼び出す
B3 = CStr(Stream.Read(3))

Stream.Close() を呼び出す
Stream = Nothing を設定する

Dim L1
L1 = Left(B3, 1)
If (L1 = ChrW(&hFEFF)) then
vbDetectFileEncoding = "unicode"
終了関数
Elseif (L1 = ChrW(&hFFFE)) then
vbDetectFileEncoding = "unicodeFEFF"
終了関数
Elseif B3 = (ChrB(&hEF) & ChrB(&hBB) & ChrB(&hBF)) 次に
vbDetectFileEncoding = "utf-8"
終了関数
End If


vbDetectFileEncoding = defEncoding
End Function

この関数は、ファイル内に存在する可能性のある BOM に基づいて、テキスト ファイルで使用されているエンコーディングを推測します。

ここで注意すべき点が 1 つあります:

ADODB.Stream の関連ドキュメントには、許可される値は、インターネット文字セット名としてインターフェイス上で渡される一般的な文字列 (たとえば、「iso」) であると書かれています。 -8859 -1」、「Windows-1252」など)。システムで認識されている文字セット名のリストについては、Windows レジストリの HKEY_CLASSES_ROOTMIMEDatabaseCharset のサブキーと「Unicode Big Endian」(エンコーディング 1201) 対応する項目は「unicodeFFFE」です。この情報から、ADO Stream で「Unicode Big Endian」エンディアンを使用する場合は、Charset 属性を「unicodeFFFE」として指定する必要があると推測できます。混乱の実装は次のとおりです。BOM 文字の Unicode 番号は U FEFF で、「一般的な」「Unicode エンコーディング」は実際には「Unicode リトル エンディアン」です。BOM 文字は 2 つ付いた「FF FE」として書き込まれます。 「Unicode Big Endian」では「FE FF」と表記​​されます。

ここで問題が発生します。「unicodeFFFE」の反対が「unicodeFEFF」である場合、ここでの「FEFF」は BOM 文字の Unicode 番号であることがわかりますが、同時に、 「unicodeFFFE」の「FFFE」とは「Unicode Big Endian」の略でしょうか？明らかに、これは「Unicode 番号 U FFFE を持つ文字」を意味するものではありません。

実際には、Charset 属性に「unicode」または「unicodeFFFE」が設定されていても、出力ファイルは「Unicode (リトル エンディアン)」でエンコードされていることがわかりました。これは明らかに文書の意味です。一致しません。

さらに試してみたところ、「Unicode Big Endian」エンコードされたファイルを出力したい場合は、Charset プロパティを「unicodeFEFF」に設定する必要があることがわかりました。「FEFF」が正確に一致することが簡単にわかります。 BOM ファイル内の文字のバイト順序。Charset 属性に「unicodeFXFX」を設定することは、実際には「FXFX などのバイト順序によるエンコーディング」と同等であることがわかります。これは、特別な扱いを受けており、完全に一貫しているわけではありません。レジストリ。

これまで、ガジェットは「Unicode」、「Unicode Big Endian」、「UTF-8」、「Non-Unicode 地域エンコーディング」でファイルの読み書きができましたが、まだ考えていません書類や登録フォームに間違った情報やまったく役に立たない情報が含まれている理由を理解してください...



上記の問題を 1 つずつ解決すると、もう勉強する価値のある問題はなくなったようです。 。

しかし、JSMin を使用する過程で、別の問題を発見しました。

一部の人々 (私など) は、Windows のテキスト ファイルのデフォルトの行区切り文字が LF です。右。

JSMin はすべての CR を LF に置き換えるので、CR LF ペアは 2 つの LF からなる「LF LF」ペアになります。

JSMin の元の設計によれば、通常、制御文字の LF は削減されるため、2 つの連続した LF は問題になりませんが、jsmin.js には特定の特性を保持する新しい機能 (/*! ... */) であり、このような「重要なコメント」に CR LF のペアがあると、最終的には削除できない 2 つの LF 制御文字になってしまい、良くありません。

この問題を解決するために、jsmin.js にいくつかの変更を加えました...しかし、JSMin は私の理解を少し超えているため、CR をスペースに変更することしかできませんが、幸いなことに、これはWindows いくつかの利点があります (Windows のほとんどのバージョンでは、メモ帳プログラムでは LF 制御文字だけがほとんど見えず、LF 制御文字で区切られた 2 行のテキストがくっついているように見えます)。それだけです。それを使用するだけです...これらの変更を個別にリストすることはしません。



この記事で説明されているすべてのコードは、この圧縮パッケージに含まれています。

圧縮パッケージには 3 つのファイルが含まれています。install.js は登録ファイルに関連付けられた「インストール」スクリプト、jsmin.hta は「Minimize」コマンドを使用するときに実際に実行される「アプリケーション」、および jsmin.js後の jsmin.js を変更します。

3 つのファイルを同じフォルダーに解凍した後、install.js をダブルクリックしてこのツールをインストールします。オペレーティング システムを再インストールした場合は、個人フォルダーにツールがまだ残っている場合がありますが、個人フォルダーに残っている install.js をダブルクリックする限り、ツールを再度使用できます。

注: Windows XP 以降、新しいバージョンの Windows では、インターネットからダウンロードされたファイルにフラグが設定されるため、HTA ファイルが正常に実行されなくなる可能性があります。このような問題が発生した場合は、次のことを行ってください。このフラグを削除するには、ファイル プロパティ ダイアログ ボックスの [ロック解除] ボタンをクリックします。

更新: install.js を変更しました。 64 ビット Windows 7 に正しくインストールできるようになりました。インストール後に手動で「ロックを解除」する必要はありません。


秘密はここにあります:

コードをコピーします コードは次のとおりです:

var appsPath = wshShell.ExpandEnvironmentStrings(wshShell.RegRead(regUSF "Personal")) "\Scriptlet";

try{
fso.OpenTextFile(instPath "\" appExec ": Zone.Identifier", 1).Close();
fso.OpenTextFile(instPath "\" appExec ":Zone.Identifier", 2).Close();
}catch(ex){ }

File package download The file is attached with a renamed jse. It is convenient for friends who often develop js to avoid confusion.
Because many of my friends use win2003 for development, the .js file is opened with ordinary text. It is impossible to run it with js in the future. Just change it to install.jse and it will run. Haha.
Thanks to the author for publishing such good stuff. The author's blog address
http://www.cnblogs.com/NanaLich