reg ファイルNo.07404
susan さん　05/04/17 03:19
　
regedit でエクスポートした *.reg を version5.00β17 で開くと、何らや間延びし
た感じに表示されてしまいます。同じファイルが NotePad では正常に表示されます。
β17 で一文字でも編集すると、NotePad で正常には読めなくなります。文字種をい
ろいろ変更してみても同じようなので、使い方が悪いのでもないようなのですが、こ
れは、バグでしょうか?
[ △ ]
RE:07404 reg ファイルNo.07405
でるもんた さん　05/04/17 03:29
　
こんにちは。いまだに 3.x をつかっているでるもんたです。

> regedit でエクスポートした *.reg を version5.00β17 で開くと、何らや間延びし
> た感じに表示されてしまいます。同じファイルが NotePad では正常に表示されます。
> β17 で一文字でも編集すると、NotePad で正常には読めなくなります。文字種をい
> ろいろ変更してみても同じようなので、使い方が悪いのでもないようなのですが、こ
> れは、バグでしょうか?

OS は Windows XP ですか？
間延びというのは、字間があいている？　行間があいている？
前者だとしたら、文字コード「Unicode (little-endian)」で読み込んでください。

後者だとしたら、バイナリモードで表示させてみて、改行の部分はどうなっています
か？
0D 0A なら正常。一部に 0D 0D 0A という内容が混じっている可能性があります。
[ △ ]
RE:07405 reg ファイルNo.07407
susan さん　05/04/17 03:49
　
 OS は Windows2000 です。
症状としては、一文字ごとにスペースが入るような表示になります。
こんな感じです。

W i n d o w s   R e g i s t r y   E d i t o r   V e r s i o n   5 . 0 0


エンコードの種類の自動判定の設定で、UTF-16 をチェックしてみたところ、
スペースは入らなくなりました。しかし、ファイルの先頭部分に ･ が
表示されます。こんな感じです。

･Windows Registry Editor Version 5.00

NotePad では点は出ません。また、最低一度は上記の点が消えた(正常風)
表示になったことを確認しています。いずれにしても、少し不安定な
ように思います。
 
 
[ △ ]
RE:07405 reg ファイルNo.07408
susan さん　05/04/17 03:55
　
エンコードの種類の自動判定の設定で、UnicodeのBOMを認識というところをチェック
したら、正常に読めるようでした。ウーム、使い方の問題なんでしょうか。自動判定
をどのように設定しておけばよいのか、分からないような...
[ △ ]
RE:07408 reg ファイルNo.07409
でるもんた さん　05/04/17 07:06
　
でるもんたです。

> エンコードの種類の自動判定の設定で、UnicodeのBOMを認識というところを
> チェックしたら、正常に読めるようでした。ウーム、使い方の問題なんでしょ
> うか。自動判定をどのように設定しておけばよいのか、分からないような...

その設定でビンゴでしたか。Unicodeでないファイルにこの「BOM」が混じることは
まずないので、そのままでいいと思います。

種明かしをすると、Windows のレジストリエディタは、「Windows」の7文字を、
1文字2バイトで、次のように保存します。UTF-16LE という方式です。

5700 6900 6E00 6400 6F00 7700 7300

ところが今までは、秀丸がこの「5700」を「57＝'W'、00＝制御文字」と誤認して
いたわけです。保存するとおそらく20（スペース）に置き換えられるのでしょう。
これが「間延び」と「一旦保存すると読めなくなる」の種明かしです。

ところで、世の中には、1文字2バイトのときに、次のような順序を好むマシンも
あります。この方式を UTF-16BE といいます。Mac がその典型です。

0057 0069 006E 0064 006F 0077 0073

そこで、UTF-16LE/BE を使うときは、先頭にBOM（byte order mark）という記号を
入れるようにしよう、ということになりました。UTF-16LE（Windows方式）の場合は
FEFF、UTF-16BE（Mac方式）の場合はFFFEを入れるのです。これを今まで秀丸が正し
く認識していなかったのが、根本的な原因です。
[ △ ]
RE:07409 reg ファイルNo.07411
susan さん　05/04/17 16:31
　
>そこで、UTF-16LE/BE を使うときは、先頭にBOM（byte order mark）という記号を
>入れるようにしよう、ということになりました。UTF-16LE（Windows方式）の場合は
>FEFF、UTF-16BE（Mac方式）の場合はFFFEを入れるのです。これを今まで秀丸が正し
>く認識していなかったのが、根本的な原因です。


  でるもんたさま

  造詣の深い、詳細なる解説ありがとうございました。これで regedit でエクス
ポートしたファイルとはうまく付き合っていけそうです。

  あれからまた、いろいろやってみたのですが、どうも、罠に引っかかった原因は、
メニューから、ファイル->エンコードの種類->(エンコードの種類を選択する) とい
う操作をしたときに、自動判定の設定ダイヤログボックスにはある「Unicode の BOM
 の認識」などのチェックが不可能であるために、正しいエンコードに簡単には到達
できなかった、ということがあるように思います。プレビューしながら、すべての設
定を試してみることができれば、便利かと思いました。または、エンコードに関する
完全な知識を持つか、ですが、これは私のような素人には無理かとも...
[ △ ]
RE:07411 reg ファイルNo.07438
秀丸担当 さん　05/04/18 16:55
　

>  あれからまた、いろいろやってみたのですが、どうも、罠に引っかかった原因は、
>メニューから、ファイル->エンコードの種類->(エンコードの種類を選択する) とい
>う操作をしたときに、自動判定の設定ダイヤログボックスにはある「Unicode の BOM
> の認識」などのチェックが不可能であるために、正しいエンコードに簡単には到達
>できなかった、ということがあるように思います。プレビューしながら、すべての設
>定を試してみることができれば、便利かと思いました。または、エンコードに関する
>完全な知識を持つか、ですが、これは私のような素人には無理かとも...

この件について確認してみたところ、「UnicodeのBOMを認識」が無効でも、「フ
ァイルの内容をを解析してエンコードの種類を自動認識する」によってUnicode
として認識した場合、BOMを飛ばさずに読み込んでいることが確認できました。
「UnicodeのBOMを認識」が無効でも、「開く」のダイアログより明示的に
「Unicode(UTF-16)」を指定した場合などは、BOMを飛ばして読み込むのが通常の
動作です。
このケースでBOMを飛ばさないのは不具合と考えてもらっていいと思います。修
正させていただきます。
[ △ ]