セキュリティ対策のため、Windows Update自体は月例で実施されているのですが、先週(2019年02月13日)のアップデートで元号に関する不具合が発生する可能性があるようです。
元号に関する不具合の内容
2019年2月のセキュリティ更新プログラム(月例)の内容自体は下記ページのとおり不具合修正とかセキュリティ強化なのでそちらを参照してください。
https://blogs.technet.microsoft.com/jpsecurity/2019/02/13/201902-security-updates/
下記のレジストリキー
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras
の部分に西暦と和暦(元号)の対応表が入っているのですが、例えば平成の略称が以前は「平」だったのが「㍻」などのUnicode文字に変更されてしまっているんですね。
和暦のレジストリキーの正誤表
正)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras] "1868 01 01"="明治_明_Meiji_M" "1912 07 30"="大正_大_Taisho_T" "1926 12 25"="昭和_昭_Showa_S" "1989 01 08"="平成_平_Heisei_H"
誤)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras] "1868 01 01"="明治_㍾_Meiji_M" "1912 07 30"="大正_㍽_Taisho_T" "1926 12 25"="昭和_㍼_Showa_S" "1989 01 08"="平成_㍻_Heisei_H"
MSは次のアップデートで修正する予定とのことですが、急ぎで対応したい方は上記のように変更すればOKです。
影響範囲
但し、影響範囲はそれほど大きくないはずです。
というのもこのレジストリキーを参照しているのって .NET Framework 4以降のライブラリなのですが、わざわざ元号の表示、しかも略称に.NET Frameworkの関数を使うプログラマーは稀なハズだからです。
具体例を出すと、
"2012/02/20".ToString("ggyy年MM月DD日")
みたいな感じで西暦→和暦変換をするプログラマーは多いとは思います。ただ、この書式変換では「平成31年02月20日」といった変換は行えるものの、「平31年02月20日」といった略称への変換はできないんですね。………たぶん。…………少なくともぼくの知る限りはできないハズ(小声)
略称をOSから取得するためにはDateTimeFormat.CalenderのGetEraメソッドから和暦番号を取得し、DateTimeFormat.GetAbbreviatedEraNameメソッドを呼び出すという手順が必要で、いやいやそんなこと普通やらんやろ…とぼくは思います。
ニュースサイトなんかでは逆の和暦→西暦変換時に問題が発生する可能性がある的なことが書かれていたりしますが、それも滅多にないでしょう。
要は「平31年2月20日」と入力されたデータを西暦に変換する際に、ライブラリ側は「平」を認識しないから云々ってことですが、そんなコードを書くほうがおかしい。
厳密な入力を促すならプルダウンで選択するように実装するだろうし、過去データ(CSV等)の変換プログラムだとしたら、「平」どころかH31.2.20や、全角半角大文字小文字のチェック、日付として正しいかどうかの確認などもプログラム側で独自に実装するだろうと考えられます。
まさか元号の部分だけ.NET Frameworkを使うとか、ちょっとないでしょう。
というわけで、個人的な見解ですが、ほとんど影響を受けるプログラムはないはず。実際問題、一般の人が気になるのはExcelとか有名なアプリケーションで不具合が発生しないかってところでしょうけれど、元々和暦の、しかも略称からの西暦への変換とか対応しているアプリケーション自体が稀なので、トラブルを目にすることもないでしょう。
これが略称ではなく、正式名でのミスだったら痛恨でしたけどねー。「平成31年2月20日」といった入力を西暦変換する処理は普通にExcelあたりでも実装されていますので。
以上のことから、影響範囲は大して広くないと判断していますが、もしもこれに関連しそうなトラブルにあった方がいたら、先述のとおりレジストリキーを修正すると良いと思います。
下記のとおり変更するだけです。
㍾ | 明 |
㍽ | 大 |
㍼ | 昭 |
㍻ | 平 |
まとめ
- 2019年2月13日のWindows Updateで元号の略称に関する不具合が混入
- 影響は.NET Framework 4以降のメソッドGetAbbreviatedEraNameあたりに出るが、これでわざわざ元号の略称を取得するアプリ自体が少ないだろうと思われる
- 仮に影響が出たとしてもレジストリキーの一部を修正すればOK
- また、次回のアップデート時にこのレジストリキーは修正されるので急がないならほっといても良い
といったところでしょうか。
まぁ、MSは新元号への対応のために先述のレジストリキーに「??」という名称の元号を入れた前科があるため、今回の修正も各方面で叩かれていますが、個人的には和暦西暦変換をOSやライブラリに頼るのがおかしいと思います。
コメント