- 投稿
以下のようなマクロを作りましたが、Shift_JISやBOMつきのUTF-8、UTF-16で保存すればちゃんと動きますが、BOMがないUTFではちゃんと動いてくれません。どうしてでしょうか？
//
// File Name: testCSVDB.jsee
//
var strDBFileName = “testHouName.csv”;
var strDBFolderPath = “C:Program FilesEmEditorMacrosPractice”;
var strDBDriver = “Driver={Microsoft Text Driver (*.txt; *.csv)};”;
var strDBQ = “DBQ=” + strDBFolderPath + “;”;
var strSQL;
var objADO;
var objRecordset;strSQL = “select * from ” + strDBFileName;
objADO = new ActiveXObject(“ADODB.Connection”);
objADO.Open(strDBDriver + strDBQ);
objRecordset = objADO.Execute(strSQL);while (!objRecordset.Eof) {
alert(“法令名：” + objRecordset.Fields(0));
objRecordset.MoveNext();
}objRecordset.Close();
objADO.Close();
objRecordset = null;
objADO = null;
// マクロは以上// testHouName.csvの内容
法令名,法令略語,法令ファイル名,法令ローマ字読み
会社計算規則（平成１８年２月７日法務省令第１３号）（平成１８年５月１日施行）,計規,KaishaKeisanK,KaishaKeisanKisoku
会社法（平成１７年７月２６日法律第８６号）（平成１８年５月１日施行）,会社,Kaisha,Kaishahou
会社法施行規則（平成１８年２月７日法務省令第１２号）（平成１８年５月１日施行）,会社規,KaishaSK,KaishahouShikouKisoku
なぜかは分かりませんが、相当昔にメールで聞いたことがありまして、
Unicodeで保存する時は、BOMは必須という回答でした。
Unicodeとシステム既定両対応なので、ファイルの解釈をするために、Bomで単純に判断するためと思います。あるいは、Windowsの仕様というか制限で、つけないとUnicodeと判断してくれないとか、そんな感じだと思います。 WindowsはUnicodeにはBomをつけるのが基本みたいなんで。perlerさま、さっそくのご教示ありがとうございます。
ただ、確かに、UTF-16の場合にはBOMによってLEかBEかを判断するので必要性は理解できるのですが、EmEditorはUTF-8の場合でもBOMを要求するみたいなので・・・ UTF-8では本来BOMは不必要なはず（わたしの誤解でしょうか？）で、BOMつきのUTF-8を扱わ[え]ないソフトもありますし、また、テキストファイルを連結したとき本来不必要なBOMが連結部分にひそかに居座るのも、ちょっと気味が悪いです。それに、EmEditorのマクロはいったんファイルに保存しないと実行できないので、保存時に指定された文字コードを参照すれば、たとえBOMなしのUTF-16でもマクロを実行させるのに差し支えはないと思うのですが、また、BOMが必須なら、保存時のダイアログボクス中の「Unicodeサイン(BOM)を付ける(G)」のチェックボクスは不要だと思うのですが…EmEditor のマクロは、[マクロ] メニューで [名前を付けて保存] を実行すれば、必ず UTF-16LE (BOM付き) で保存されます。そのため、UTF-16LE (BOM付き) だけを扱えばいいと思って設計されています。確かに、作成したコードを編集して、新規作成から保存するというやり方の場合は、UTF-16LE 以外でも保存できてしまうため、これでは不便ということで、システム既定エンコードでも動作するようになっていますが、UTF-8 は想定外でした。ライブラリで公開するときは、UTF-16LE に変換して公開していますし、以前のバージョンとの互換性のためにも、できるだけ UTF-16LE で統一していただけないでしょうか?
EmEditor のマクロは、[マクロ] メニューで [名前を付けて保存] を実行すれば、
必ず UTF-16LE (BOM付き) で保存されます。これはちょっと誤解するのではないでしょうか？
実際には、JavaScript for EmEditor の 設定依存だと思います。[プロパティ – 新規作成時(&F)] UTF-16LE BOMなし
[プロパティ – 保存時(&V)] 設定されたエンコードなら、マクロメニューの名前を付けて保存は、UTF-16LE BOMなしで保存します。
保存時(&V) に指定がある場合は、保存時(&V)の設定になります。実際私は、Bomは基本いらないと思い、全ての設定で[プロパティ – 新規作成時(&F)] の
Bomを解除した後マクロを作って、動かなくなって嵌ったのが問い合わせメールしたきっ
かけです。少し横道それますが、このあたりと関連して。
無題のファイルを作成[Alt+F+N]する時は、[プロパティ – 新規作成時(&F)] の設定を参
照しますが、[Ctrl+O]で開くダイアログから存在しないファイル名を指定して
「新規作成しますか？」ダイアログの場合は、エンコードは全部システム既定になってし
まいます。「新規作成しますか？」の時に、ステータスバーを見ると、
[プロパティ – 新規作成時(&F)] の設定が表示されていますが、その後新規作成したファ
イルを保存して開きなおしているために、結果的に「開く時のエンコード｣に設定される
ため、空ファイルなのでシステム既定になってしまっていると思います。可能なら、「新規作成しますか？」で新規作成した時は、
[プロパティ – 新規作成時(&F)] で設定されているエンコードを維持してもらうと、便利
だと思います。なぜかというと、私の場合、[Alt+F+N]で無題ファイルを作るより、
「新規作成しますか？」ダイアログを経由して、ファイル名を確定して開いてしまう事が
多いため、[プロパティ – 新規作成時(&F)] のエンコードを継承してもらった方がいいか
らです。変な表現ですが、[Alt+F+N] に加えて名前も付けておくようなイメージで使って
いるため。例えば、Perlの場合は、[プロパティ – 新規作成時(&F)] はEUCにしておくと便利なので
すが、「新規作成しますか？」から作成した場合は、Shift_JISになってしまうので、保
存する時に、EUCを指定し直す羽目になります。(保存時の設定をEUCにするとか、開くの
エンコードをEUC決め打ちにするとかは抜きにして)もう慣れちゃったので今のままでも良いのですが、今の動作は、
ユーザーが直感的求めるものと違う気がするだけです。ユニコード系周りのことはあまりよく分からないのですけど、おっしゃるとおりの理解で
あってるんじゃないでしょうかね。私もそう感じの理解です。UTF-8はBOMはいらないと思いますし、問題の諸悪になりやすいので、無しでいいと思いま
すけど、例えば、Windows付属のメモ帳なんかは、UTF-8で保存するとBomは強制付与です。
Wshなんか見てても、ファイルの入出力なんか見てると、Bomがつくのがデフォルトみたい
な感じに見えるんですよね。マクロでBomが無いと実行できないのは、開発者に利いたほうがいいとは思いますけど、
つまり、マクロファイルを解釈する時に、Bomがあるかないかで、システム既定とファイ
ルか、ユニコードファイルか、でその後の処理が違うために、UTF-8でBom無しだとシステ
ム既定と解釈した処理に入っちゃって、なんかおかしくなるってことじゃないですかね。
ユニコード系周りのことはあまりよく分からないのですけど、おっしゃるとおりの理解で
あってるんじゃないでしょうかね。私もそう感じの理解です。UTF-8はBOMはいらないと思いますし、問題の諸悪になりやすいので、無しでいいと思いま
すけど、例えば、Windows付属のメモ帳なんかは、UTF-8で保存するとBomは強制付与です。
Wshなんか見てても、ファイルの入出力なんか見てると、Bomがつくのがデフォルトみたい
な感じに見えるんですよね。マクロでBomが無いと実行できないのは、開発者に利いたほうがいいとは思いますけど、
つまり、マクロファイルを解釈する時に、Bomがあるかないかで、システム既定とファイ
ルか、ユニコードファイルか、でその後の処理が違うために、UTF-8でBom無しだとシステ
ム既定と解釈した処理に入っちゃって、なんかおかしくなるってことじゃないですかね。個人的には、Bomが必要ってのは分かったので、それ以来は、マクロファイルにユニコー
ド文字直書きする必要が無い場合は、全部システム既定をデフォルトにしちゃったので、
気にならなくなってます。EmEditorのBom(エンコード含め)の設定はあっちこっちにあって、頭が痛い話ではあります。どのコマンドがどの設定の影響を受けるとか,どのダイアログの初期値がどの設定影響を受けるとかが、ややこしいというか分かりにくい気がしますね。
もうちょっと分かりやすくなると嬉しいのですが、難しいのかなぁ。すいません。私の勘違い私が間違っていました。
EmEditor のマクロは、[マクロ] メニューで [名前を付けて保存] を実行すれば、
必ず UTF-16LE (BOM付き) で保存されます。これについて、それで正しかったです。
[マクロ] メニューの[名前を付けて保存]は、UTF-16LE BOM有り強制でした。[マクロ] メニューで ｢編集」に入ってからのことと勘違いしてました。
[マクロ] メニューの[名前を付けて保存]は使わず、一時マクロは常に一旦編集で開いて
いるで、混乱してしまいました。ついでなので、メニュー名について気になってたことを。
[マクロ] メニューの[名前を付けて保存]は、「(一時)マクロの保存」というメニュー名
にしたほうが分かりやすいと思います。[ファイル]メニューの[名前を付けて保存] = 現在開いているドキュメントへの操作
[マクロ] メニューの[名前を付けて保存] = 目に見えない一時マクロデータへの操作と、明らかに操作対象が違うのに同じ名前を付けてしまうと、[ファイル] メニューの[名
前を付けて保存]と混乱しやすいです。[編集]も、「(一時)マクロの編集」の方が分かり
やすくていいのですが。ダイアログ側のタイトルが 名前を付けて保存 なので、合わしていると思いますが、
その必要は無いのではないでしょうか？UTF-8 で BOM は必要ないかというと、実は、UTF-8 の BOM 無しが必ずしも正しく検出できるわけではないのです。例えば、UTF-8 ではアクセント付き欧文文字が、Shift-JIS だと日本語や記号として表現できる場合があります。そこで、EmEditor のマクロでは、そのようなあいまいさをなくすため、マクロの仕様として、UTF-16LE (BOM付き) を推奨していますが、便宜上 UTF-8 (BOM付き) やシステム既定エンコードでも可能になっています。UTF-8 (BOM無し) だと、他のエンコードと区別が付かないことがあるため、おすすめしません。
ファイルを開くで、既存のファイルが存在しない場合の動作についてですが、この場合は、該当する設定のプロパティの [ファイル] タブの設定になると思います 。こちらも確認してみてください。
管理人さま、perlerさま、どうもありがとうございました。
質問を投稿しておきながらその後すっかり忘れていました。５０の坂を越えてからこういうことがしばしばおこります（汗）。どうもすみません。UTF-8にもBOMが必要なことは管理人さまのご教示で理解できました。これからはご指導のとおりBOMつきUTF-16いっぽんでやっていきたいと思います。
ところで、質問とは無関係な話題で申し訳ありませんが、最近ようやくWZ EditorからEmEditorへのマクロの引っ越しがすべて終わりました。WZ EditorのマクロにはVZ Editorから引っ越したものもあります。VZ EditorからWZ Editorへの引っ越しはOSの交代によるものでしかたがなかったにしても、WZ EditorからEmEditorへの引っ越しは、はっきりいって前者のサポートに対する不安が原因です。EmEditorはマクロにRubyまで使えるとても楽しいエディタで、すごく満足していますが、長年慣れ親しんだエディタとの別れにはやはり一抹の寂しさを禁じえません… 管理人さまは、少なくともわたしより健康で長生きされ、せめてわたしが生きているあいだはEmEditorのサポートをしっかり続けてくださることを、せつに希望いたします。
なお、UTFのマクロにBOMがないときには、「BOMがありませんよ」メッセージを出してひとこと注意してもらえれば、初心者にも優しいエディタになるのではないでしょうか。
- このトピックに返信するにはログインしてください。