はい、できます (私がほとんど知らない変な人が言うように)... はい、ActiveX を介してFSO/OpenTextFileを使用して、Internet Explorer で Javascript のバイナリ ファイルを読み書きできます。実際、私は Javascript " Fichier " (私はフランス人です) クラスを作成し、Internet Explorer が直接アクセス モードを含むさまざまなモードでローカル ファイルを開くことを可能にし、Seek(position)、Read(numberOfBytes)、Write(string) を提供します。 、およびオンデマンドで変更を保存します。
また、たとえば、ファイル全体を文字列にロードして Base-64 に変換することもできます。これにより、イメージ ファイルをローカル ディスクから直接ロードすることができ、Web サーバーによってイメージ ファイルをアップロードして、後でクライアントにダウンロードする必要がなくなります。 : ウェスト・ロンドンからセンター・ロンドンに行くには、まずウェスト・ロンドンからグラスゴーに行き、次にグラスゴーからセンター・ロンドンに戻らなければならないと考えるのは奇妙ではありませんか?
ポイントは、ちょっとした秘密を知っているだけで、すべてのバイトをディスクに書き込むことも、ロードしたファイルを Base-64 に変換することもできないということです。その秘密を次の 2 点を考慮してお伝えします。
. まず、n>1 の readAll() または read(n) ではなく、ファイルをバイトごとに読み取る必要があります。こうすることで、場合によってはブラウザが数バイトを関連付けるのを防ぐことができます。そのため、「objectFile.Read(1)」を内部に使用してループを作成します。
. 次に、ここに秘密があります: ASCII+ テーブルの 256 文字 (8 番目のビットまで拡張) のうち、27 文字が異常な動作をしており、これがバイナリ ファイルの操作を妨げる唯一のものです: これらの 27 文字は範囲内にあります。 2 つの「段落」、つまり 128 から 159 (80h から 9Fh) までの 32 バイトですが、そのうちの 5 つを除きます: 129,141,143,144,157 : これらの 5 つは正常に動作します。しかし、その 32 の範囲の他の 27 バイトについては、それらがディスクから読み取られるとすぐに、16 ビット値に変更されます。たとえば、ユーロ記号は UTF- 8、そして実際、それはあなたのファイルに書かれている値です。しかし、ブラウザのメモリでは、ディスクから 80h バイトを読み取るとすぐに、8364(20ACh) という 16 ビット値に変換されます。
これを理解するには、「D:\」ディレクトリに書き込むことができると仮定して、次のコードを試してください。それ以外の場合は、ブラウザが書き込みを許可されている別のディレクトリを指定するようにコードを変更してください。
<script type="text/javascript'>
fso = new ActiveXObject("Scripting.FileSystemObject");
oFich = fso.OpenTextFile("d:\\foo.txt", 2, true);
var c1 = String.fromCharCode(65); // 65 is the ASCII code for "A"
oFich.write(c1);
oFich.close();
</script>
そのコードを実行すると、ディスクに「foo.txt」ファイルが見つかります。テキストパッドで開くと、完璧な「A」が表示されます。
上記の Javascript コードの 3 行目で、値 "65" を他の値に置き換えることができます。たとえば、"66" は foo.txt ファイルに "B" を書き込み、"97" は "a" を書き込みます。 「55」は「7」などと書きます... しかし、今度は「128」という値で試してみてください。ブラウザに侮辱されているので、不快になります! このような：
"Incorrect argument or procedure call"
あなたが望んだのは、"€" 記号をファイルに書き込むことだけでした。どうしてできないの？値 128 は、FSO を介してそのまま書き込むことはできないためです。上記の 26 の他の値も同様です。ところで、128 は最初の 8 ビットの数値であるため、8 番目のビットが失敗の原因であると結論付けないでください。完璧に機能することがわかります。
だから、今これを試してください：
fso = new ActiveXObject("Scripting.FileSystemObject");
oFich = fso.OpenTextFile("d:\\foo.txt", 2, true);
var c1 = String.fromCharCode(8364); // 8364 (unicode for "€" symbol ?)
oFich.write(c1);
oFich.close();
実行後にエラー メッセージが表示されなくなったことに満足するでしょう。次に、「foo.txt」と入力すると、美しい「€」記号が表示されます。しかし、驚いたことに、そのファイルを 16 進数の「ダンパー」ツールにロードすると、コードが「AC 20」(8364) ではなく「80」(128) であることがわかります。
これを知っていれば、任意のバイト文字列を Base-64 に変換したり、任意のバイト文字列をファイルに書き込んだりできるようになりました。「128」バイトをディスクに書き込むことがわかったらすぐに、それを置き換える以外の手段はありません。 8364 (20ACh)までに。ちなみに、本当に 8364(20ACh) を書きたい場合は問題ありません。ただし、これは、ファイルが単純なバイト範囲ではなく、16 ビット値の組み合わせであることを意味します。したがって、その数値を組み合わせた 2 バイトを単純に書き込み、最初に下位バイトを書き込みます。
oFich.write(String.fromCharCode(172)); // 172 = ACh
oFich.write(String.fromCharCode(32)); // 32 = 20h
テキストのみを操作する限り、何もする必要はありません: "€" はブラウザのメモリとディスク上で同じように書き込まれるわけではありませんが、とにかく "€" のままなので透過的です。しかし、数値としてバイト 128 をロードすると、ファイルから読み取るすべての 128 ではなく 8364 が返されるため、問題が発生します。多くの人がエンコードに失敗するのはこのためです。 Javascript の base-64。
実際、数値を取得したい場合は、27 の破滅的な文字をフィルター処理するだけで済みます。これが、次の 2 つの関数を作成した理由です。これらの関数は、" Fichier " クラスの一部で必要に応じて使用し、クライアント ディスクから画像ファイルを直接ロードするときに Base-64 アルゴリズムで使用します。バイトを文字ではなく数値として操作する必要がある場合:
これらの 2 つの関数は、Javascript モデルの部分的な「倒錯」を相殺します。
`String.fromCharcode() and String.charCodeAt()`
それらは単にモデルをカプセル化するだけなので、私はそれらに古典的な Basic 名「asc」と「chr」を付けたので、理解しやすく、覚えやすくなっています。どうぞ：
function asc(c) //(string)->integer
{ // Objet : Renvoie le code ASCII du 1er caractère de la chaine "c"
var i = c.charCodeAt(0);
if (i < 256)
return i; // caractères ordinaires
// (plage 128-159 excepté les 5 caractères 129,141,143,144,157, qui fonctionnent normalement)
switch (i) {
case 8364: // "€"
return 128
case 8218:
return 130
case 402:
return 131
case 8222:
return 132
case 8230:
return 133
case 8224:
return 134
case 8225:
return 135
case 710:
return 136
case 8240:
return 137
case 352:
return 138
case 8249:
return 139
case 338:
return 140
case 381:
return 142
case 8216:
return 145
case 8217:
return 146
case 8220:
return 147
case 8221:
return 148
case 8226:
return 149
case 8211:
return 150
case 8212:
return 151
case 732:
return 152
case 8482:
return 153
case 353:
return 154
case 8250:
return 155
case 339:
return 156
case 382:
return 158
case 376:
return 159
default:
return -1 // provoquera une erreur, le cas ne devant pas se présenter
}
}
function chr(octet) //->(integer)->string
{ // Objet : renvoie le caractère d'un nombre 8 bits
// Entrée : "octet" est un nombre 8 bits non signé (entre 0 et 255)
// Sortie : le caractère correspondant est renvoyé, les codes échappés sont rattrapés par un switch
if (octet < 128) || (octet > 159))
return String.fromCharCode(octet); // caractères ordinaires, traités par String.fromCharCode
switch (octet) {
case 128:
return "€"
case 129:
return String.fromCharCode(129);
case 130:
return "‚"
case 131:
return "ƒ"
case 132:
return "„"
case 133:
return "…"
case 134:
return "†"
case 135:
return "‡"
case 136:
return "ˆ"
case 137:
return "‰"
case 138:
return "Š"
case 139:
return "‹"
case 140:
return "Œ"
case 141:
return String.fromCharCode(141);
case 142:
return "Ž"
case 143:
return String.fromCharCode(143);
case 144:
return String.fromCharCode(144);
case 145:
return "‘"
case 146:
return "’"
case 147:
return "“"
case 148:
return "”"
case 149:
return "•"
case 150:
return "–"
case 151:
return "—"
case 152:
return "˜"
case 153:
return "™"
case 154:
return "š"
case 155:
return "›"
case 156:
return "œ"
case 157:
return String.fromCharCode(157);
case 158:
return "ž"
case 159:
return "Ÿ"
default:
return String.fromCharCode(octet); // unicode 16 bits
}
}
これで、IE がファイルにアクセスできるディスクのすべてのゾーンで、ActiveX を使用して Internet Explorer であらゆる種類のファイルをバイナリで読み書きできるようになりました。
フランスの偉大なユーモリスト、ピエール・デプロージュがよく言ったように、「エトナン、ノン？」
BB。