元からあった拡張子の関連付けが破壊されることがある

No.41316

fzok4234 さん　24/07/12 15:31　[ コメントを投稿する ]

毎度お世話になっております。Fzok4234 です。

さて、「動作環境」->「関連付け」->「関連付け可能な拡張子の登録」についてですが、ここで拡張子を
登録すると、ユーザーが Windows の設定の「アプリ」->「既定のアプリ」で明示的に設定を行っていない
場合に適用されるデフォルトの関連付けが勝手に上書きされてしまいます。

すなわち、全ユーザー用の
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.<拡張子>
の既定値およびカレントユーザー用の
HKEY_CURRENT_USER\Software\Classes\.<拡張子>
の既定値に元から登録されていた ProgID が、「関連付け可能な拡張子の登録」によって作成された
秀丸エディタ用の ProgID である
hidemaru.<拡張子>
に上書きされます。

さらに、「関連付け可能な拡張子の登録」から該当する拡張子を削除すると、この既定値は削除されるが、
以前の ProgID はこの既定値に復活しません。

このため、例えば拡張子 .js に対する Windows Script Host の ProgID である JSFile への関連付けなど、
HKEY_LOCAL_MACHINE\SOFTWARE\RegisteredApplications
に登録されていなくて
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.<拡張子>
の既定値だけが唯一の拡張子と ProgID のバインディングとなっている場合では、不用意に「関連付け可能な
拡張子の登録」を実行することでこの関連付けが破壊されて元に戻らなくなってしまいます。

特に、該当する拡張子のファイルを元の関連付けの状態で一度も起動していない場合など、
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.<拡張子>\OpenWithProgids
内の元の ProgID 名の REG_NONE 値が存在しない場合は、確実に元の ProgID との関連付けを失うことになります。

さすがにこれでは大変まずいので、「関連付け可能な拡張子の登録」からは
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.<拡張子>
と
HKEY_CURRENT_USER\Software\Classes\.<拡張子>
の既定値の変更は、少なくとも Windows 11 では行わないよう修正していただくよう、よろしくお願い申し
上げます。

環境は、
・秀丸エディタ: 9.35 x64 正式版
・OS: Windows 11 Pro x64
です。

[ △ ]

RE:41316 元からあった拡張子の関連付けが破壊されることがある

No.41318

秀丸担当 さん　24/07/12 17:23　[ コメントを投稿する ]

関連付け可能な拡張子の登録は、一応既に関連付けがある場合は上書きするメッセージを出していて、既定をいいえとしていて、不用意にはならないようにしているつもりでしたが、もうちょっと強めのメッセージにしたほうがいいかもしれません。
..jsなど、ある程度既知のものについては、削除で復活するようにしています。
未知のものは復活は難しいと思います。未知のもので上書きの警告で[はい]としたものは、元の該当アプリのほうで修復などしてもらうしかない場合も出てくると思います。そのあたりのこともメッセージとして出せたらいいと思います。
ご意見参考にさせていただきます。

[ △ ]

RE:41318 元からあった拡張子の関連付けが破壊されることがある

No.41323

fzok4234 さん　24/07/16 13:38　[ コメントを投稿する ]

回答ありがとうございます。

現状の対応についてですが、いくつか問題点があります。

1. 「上書きメッセージ」の内容が、具体的にどのレジストリキーを、どんな値で上書きするのかがわからない。

> 関連付け可能な拡張子の登録は、一応既に関連付けがある場合は上書きするメッセージを出していて、既定を
> いいえとしていて、不用意にはならないようにしているつもりでしたが、もうちょっと強めのメッセージに
> したほうがいいかもしれません。

とのことですが、一応、「上書きメッセージ」が出ることは当方では確認済みですが、具体的にどのレジストリキーを
上書きするのかが全く分からない状態です。

一口に「上書きする」ことを通知するといっても、それはコマンドを定義した ProgID の
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\hidemaru.<拡張子>
のことなのか、設定の「アプリ」->「既定のアプリ」で列挙される拡張子や URL プロトコルと ProgID との
組み合わせの根拠となる
HKEY_LOCAL_MACHINE\SOFTWARE\Hidemaruo\Hidemaru\Capabilities
および
HKEY_LOCAL_MACHINE\SOFTWARE\RegisteredApplications
のことなのか、あるいは「既定のアプリ」でユーザーが明示的に選択したときに初めて書き込まれる
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.<拡張子>
のことなのか、はたまた、かなり昔 ( Windows XP の頃 ? ) からあるデフォルトの拡張子と ProgID との
組み合わせである
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.<拡張子>
および
HKEY_CURRENT_USER\Software\Classes\.<拡張子>
のことなのかを明確に判別できるようにする必要があると思います。

当方においては、この「上書き」のこととはてっきり
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.<拡張子>
が「既定のアプリ」の操作で書き換えられることだと思い込み、実際にやってみたら
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.<拡張子>
と
HKEY_CURRENT_USER\Software\Classes\.<拡張子>
が書き換えられてデフォルトの関連付けができなくなって、後で手作業で元に戻す必要が生じたという
痛い目に遭ったというわけです。

このように、上書きするレジストリキーが明示されていないのは完全に「罠」となっていて、様々なトラブルの
温床になりえます。

よって、具体的に
・上書きする対象のレジストリキーのパス。
・その元の値およびこれから書き込む値の両方。
を一切隠すことなくメッセージで明示してもらえれば助かります。

2. 削除で復活する ProgID が間違っている。

> .jsなど、ある程度既知のものについては、削除で復活するようにしています。

とのことですが、実際に復活した内容が Windows のバージョンに応じたものではなく間違ったものになって
しまっています。

実際、当方の Windows 11 の環境下で拡張子 .txt に対する関連付けを行ってみました。

関連付けの登録前のレジストリ値は、
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.txt
の既定値はテキストファイルの ProgID である
txtfilelegacy
で、
HKEY_CURRENT_USER\Software\Classes\.txt
の既定値は初めから存在しない状態です。

関連付けの登録直後は、
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.txt
の既定値は変化なしで、
HKEY_CURRENT_USER\Software\Classes\.txt
の既定値には新たに作成された ProgID である
hidemaru.txt
が書き込まれました。

そして、この関連付けを削除したところ、
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.txt
の既定値は変化なしでしたが、
HKEY_CURRENT_USER\Software\Classes\.txt
の既定値には誤った ProgID である
txtfile
が書き込まれてしまいました。

ここで、テキストファイルの ProgID について説明すると、Windows 10 まではこの ProgID は
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\txtfile
となっていて、ここにはデスクトップアプリとしての notepad.exe のコマンドが登録されていました。
しかし、Windows 11 になってからは notepad.exe がストアアプリとなった関係で、この ProgID は
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\txtfilelegacy
という名前に変更されています。

従って、復活させる ProgID としての txtfile という値は、Windows 11 においてはもはや間違った値となる
わけです。

そもそも、当方の環境での元の
HKEY_CURRENT_USER\Software\Classes\.txt
の既定値は初めから存在しない状態であったため、関連付けの削除に伴う復活処理は、ここに書き込まれていた
既定値を削除するのが正しいのであって、元の ProgID を「推測」で書き込むこと自体が誤った処理です。

おそらく、拡張子と ProgID との関係のテーブルがハードコードされていて、このテーブル通りに馬鹿正直に
復活処理を行ったものとみられますが、実際の元の ProgID が何であったかが一切考慮されないため、このように
誤った処理がなされたと考えられます。

このため、復活処理を正しく行うためには、関連付けの登録の際には元の ProgID をどこかにバックアップし、
関連付けの削除の時にこれをリストアする、という機能を実装する必要があります。

3. 全ユーザーを対象にした処理なのに HKEY_CURRENT_USER 以下を書き換えている。

上記の .txt の関連付けの例では、新規作成された ProgID の名前自体は、全ユーザーを対象にした
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\hidemaru.txt
に書き込まれています。しかし、この ProgID と拡張子とのデフォルトの関連付けは、カレントユーザーを
対象にした
HKEY_CURRENT_USER\Software\Classes\.txt
の既定値に
hidemaru.txt
と書き込むことで行われています。

本来、「関連付け可能な拡張子の登録」の機能は管理者権限の下で「全ユーザー」を対象に関連付けを行う
もののはずです。つまり、ここから書き込みを行うレジストリキーは HKEY_LOCAL_MACHINE 以下に限定されて
カレントユーザーの領域である HKEY_CURRENT_USER 以下には書き込みを行うべきではありません。

もし、HKEY_CURRENT_USER 以下に何らかの設定を行ってしまうと、「関連付け可能な拡張子の登録」を実行した
ユーザーアカウント以外の別のユーザーアカウントからは、その設定の効果を得ることができなくなってしまいます。

したがって、
HKEY_CURRENT_USER\Software\Classes\.<拡張子>
の既定値に ProgID の名前を書き込むことは誤った処理であり、
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.<拡張子>
の既定値のほうを書き換えるのが正しい処理です。

4. そもそも最近の Windows で古い方式の関連付けを行ってしまっている。

そもそも、最近の Windows ( 主に 8.1 以降 ) では、拡張子や URL プロトコルの関連付けは
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\<ProgID>
キー以下にアイコンやコマンドなどの ProgID の動作を定義した後は、HKEY_LOCAL_MACHINE キー以下の
任意のサブキーに Capabilities キーを設けてここで拡張子や URL プロトコルと ProgID との紐づけを定義し、
この Capabilities キーのパスを
HKEY_LOCAL_MACHINE\SOFTWARE\RegisteredApplications
キーに登録して「既定のアプリ」で認識させるだけで済むはずです。

実際の関連付けの有効化は、各ユーザーが「既定のアプリ」で明示的に ProgID に対応するアプリを選択することで
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.<拡張子>\UserChoice
または
HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\<URLプロトコル>\UserChoice
キーに ProgID とそのハッシュ値が書き込まれることによってなされます。

したがって、Windows XP 時代のかなり昔に行われていた
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.<拡張子>
または
HKEY_CURRENT_USER\Software\Classes\.<拡張子>
キーに ProgID を書き込むことによる関連付けは、もはや行う必要のないものとなっています。

一応、これらのキーに ProgID を登録すると自動的に
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.<拡張子>\OpenWithProgids
キーにその ProgID が書き込まれることで関連付けが有効化されます。しかし、実際にその中身を覗いてみると、
デフォルトで登録されているのは、例えば拡張子 .exe に対応する ProgID の exefile というように、重要な
システムファイルまたはレガシーな標準アプリのファイルが確実に開けるようにしたものばかりです。

このことから、サードパーティーのアプリからこの古い方式での関連付けを行うのは危険を伴うことがよく
わかり、もはやみだりに行うべきではありません。

よって、「関連付け可能な拡張子の登録」では Windows のバージョンを判別して、少なくとも Windows 8.1
以降では
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.<拡張子>
および
HKEY_CURRENT_USER\Software\Classes\.<拡張子>
への書き込みを廃止するような対策をしたほうが良いと思われますが、いかがでしょうか ?

[ △ ]

RE:41323 元からあった拡張子の関連付けが破壊されることがある

No.41324

秀丸担当 さん　24/07/16 16:15　[ コメントを投稿する ]

ご意見ありがとうございます。
..txtのtxtfilelegacyというのは、確かにその通りでした。
少なくともここはなんとかしたほうがよさそうです。
ただtxtfileになっても、実際はメモ帳で動いているようでした。

ユーザーごとについては、もっというとProgram Filesではないユーザーごとのインストールとかにも対応したほうがいいのだと思います。
ご意見参考にさせていただきます。

[ △ ]

RE:41324 元からあった拡張子の関連付けが破壊されることがある

No.41330

fzok4234 さん　24/07/19 05:01　[ コメントを投稿する ]

> .txtのtxtfilelegacyというのは、確かにその通りでした。
> 少なくともここはなんとかしたほうがよさそうです。

当方の Windows 11 環境で .ini および .inf の関連付けを「関連付け可能な拡張子の登録」から削除したところ、
Windows 11 ではもはや廃止されて存在しない ProgID が復活してしまいました。

すなわち、.ini に関しては
HKEY_CURRENT_USER\Software\Classes\.ini
の既定値に
inifile
が、.inf に関しては
HKEY_CURRENT_USER\Software\Classes\.inf
の既定値に
inffile
が書き込まれます。

両者とも Windows 11 では
HKEY_LOCAL_MACHINE\SOFTWARE\Classes
および
HKEY_CURRENT_USER\Software\Classes
配下には存在しない ProgID であり、.ini と .inf のデフォルトの ProgID はそれぞれ「ストアアプリ」の
notepad.exe のものである AppX で始まるランダムな英数字となっております。

おそらくこの他にも既知のファイルの ProgID が notepad.exe のストアアプリ化で変更あるいは廃止となった
例は多数あると思われます。また、今後の Windows のアップデートでこのようなケースはどんどん増えてくる
とみられます。

このようなことから、拡張子と ProgID との関係のテーブルをハードコードしておいてこれに基づいて「推測」で
ProgID を復活させるという手法は、もはや通用しなくなってきております。

ユーザーに指摘された拡張子の ProgID の変更に一々対応するのは非現実的であり、抜本的な対策としては、
最近の Windows においては拡張子の登録と削除との両方において
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.<拡張子>
および
HKEY_CURRENT_USER\Software\Classes\.<拡張子>
の既定値は「決して変更しない」ようにするほかありません。

また、どうしてもこの既定値を変更する仕様に執着するのであれば、拡張子の登録の時に元の ProgID をどこかに
バックアップしておいて、削除の時にこれをリストアする、という機能を実装しなければなりません。

このように、「関連付け可能な拡張子の登録」の大幅な改修は、間近に Windows 10 のサポート終了が迫って
いることもあって「喫緊の課題」であります。現実を受け止めたうえでどうか真摯な対応よろしくお願い
申し上げます。

[ △ ]

RE:41330 元からあった拡張子の関連付けが破壊されることがある

No.41331

秀丸担当 さん　24/07/19 09:23　[ コメントを投稿する ]

情報ありがとうございます。
inifileやinffileはもはや存在しなかったのですね。
少なくとも無いものはやらないほうがようにしようと思います。

[ △ ]

RE:41331 元からあった拡張子の関連付けが破壊されることがある

No.41332

fzok4234 さん　24/07/19 13:00　[ コメントを投稿する ]

> 少なくとも無いものはやらないほうがようにしようと思います。

とりあえず、拡張子の関連付けの削除の際に復活させる ProgID の一覧を、次のβ版のヘルプなどに載せて
もらえないでしょうか。

当方で一々虱潰しに登録と削除を繰り返して無効な ProgID を洗い出すのは大変です。

[ △ ]

RE:41332 元からあった拡張子の関連付けが破壊されることがある

No.41333

秀丸担当 さん　24/07/19 17:11　[ コメントを投稿する ]

貴重なご意見を参考にさせていただきます。ただし、ご期待に添えない場合もございますので、ご了承いただければと思います。様々なご意見をいただく中で、すべてを即座に反映することは難しいですが、決して無視しているわけではありませんので、ご安心ください。

[ △ ]

[ 新規に投稿する ]