Windows 10の令和対応パッチによる変更点を詳しく見る
Windowsの令和対応は、ギリギリ連休前に配布が開始されたが、ただしそれはWindows 7～Windows 10 Ver.1803（RS4）までだった。Windows 10の最新版であるVer.1809（RS5）については、連休中に持ち越され、結局始まったのは令和になってからだった。
さすがに1ヵ月前の発表でWindows 7から10まで、さらにはWindows Serverまでというのは厳しかったようだ。さらに、改元直前に連休開始というのもスケジュール的にキツい。なかには休日出勤を余儀なくされた方もいるかもしれない。昨今、政府関係者から「働き方改革」という言葉をよく聞くが、残業や休出を増やしてしまうようなやり方はなんとかならないものだろうか。
さて、その令和パッチだが、どのようになっているのか詳しく見ていこう。
現時点では、任意のアップデートとして提供されている
記事執筆時点では、令和パッチは自動でアップデートされるものではないようだ。配布日も「Bアップデート」（毎月第2火曜日の品質アップデート）ではないので、オプションという位置づけ。早ければ、次回、5月の第2火曜日（日本の水曜日未明）の品質アップデートに含まれるのではないかと思われる。
“自動”ではないので、ユーザーが、Microsoft Update Catalogから必要なアップデートをダウンロードしてインストールする必要がある。各バージョンのダウンロード先は、以下のリンクになっている。各パッチは、x86、x64、ARM64と複数のアーキテクチャに分かれているため、必要なアーキテクチャのものをダウンロードする。
インストールは簡単で、ダウンロードしたMicrosoft Update スタンドアローンパッケージ（.msu）をエクスプローラーからダブルクリックするだけだ。ただし、インストール後には再起動が必要である。また、このインストールは、他のWindows Updateが実行中だったり、パッケージの確認を行っている最中には、処理が進まないので注意が必要だ。
なお、Windowsの各バージョンごとに更新内容には違いがある。詳細情報はそれぞれにKB番号（Knowlege Base番号）があるので、それぞれを参照してほしい（カッコ内は更新後のBuild）。
また、混乱を避けるため、パッチを適用する前に、テストなどで変更したレジストリなどは削除しておくほうがいいだろう。このレジストリ設定は、アップデートが完了したという確認になる。
ここでは、最新版であるWindows 10 RS5で動作を検証した。RS5向けの令和対応パッチは「KB4501835」で、マイクロソフトによると元号関係では以下の変更点があるとのことだ。
1. CALDATETIME構造が4つ以上の日本の元号を処理できない問題を修正します。
2. 日本の新元号に対応するために、NLSレジストリを更新します。
3. 日本の日付形式で DateTimePicker が日付を正しく表示しない問題を修正します。
4. 日付と時刻の設定のコントロールが古い元号をキャッシュして、時刻が日本の新元号に切り替わる際にコントロールが更新されない問題を修正します。
5. 日本の新元号に対応するために、フォントを更新します。
6. 入力方式エディター(IME)が日本の新元号の文字に対応できない問題を修正します。
7. 時計とカレンダーのポップアップ コントロールが、日本の新元号の月の日付にマップされた週の曜日を正しく表示しない問題を修正します。
8. 日本の新元号のフォントの代替フォントを追加します。
9. 日本の新元号の文字に対応するために、音声合成(TTS)機能を有効にします。
個別の変更点を詳しく見ていく
まずは「1」だが、これはWin32のNLS（National Language Support）関連のAPIにおける問題点。ただし、この構造体や関連のAPIなどを使っていないアプリケーションは無関係である。構造体とは、APIなどに引き渡すデータ構造で、日時を表現したこの構造体を使って、ローカル時間などを得るために利用するが、これらはすべて廃止予定であり、かつWindows Vistaから実装されたAPIなので、あまり影響はないと思われる。ただしマイクロソフトのWindows関連のソフトウェアで使われている確率が高いと考えられる。
また「4つ以上の日本語の元号を処理できない」とは、マイクロソフトが以前言っていた「和暦 (われき) がハードコードされたモジュール」の部分だと考えられる（ほかにもあるかもだが）。この構造体では年号を数字で指定し、これをAPI側が解釈するのだが、API内部で元号はレジストリを読むのではなく、1～4の数字をそのまま明治、大正、昭和、平成と解釈するようになっていたのであろう。つまり、令和を表す5を指定しても、解釈できない作りになっていたのだと思われる。
「2」は、本連載でも以前紹介したレジストリキー「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras」のことである。
「3」は、アップデートをかける前にいろいろな条件で試してみたが、現象を発生させることができなかった。DateTimePickerは、XAMLコントロールの1つで、WPFやUWPで使われるGUI部品（コントロール）。カレンダーコントロールなどを使って、日時をユーザーに指定してもらうためのものだ。カレンダーコントロールの和暦対応がうまく動いていなかったのだと思われる。
「4」は、5月1日になって元号が切り替わる瞬間の動作の問題のようだ。Windowsの標準アプリを含め、一般にアプリケーションでは、起動時に読み込んだシステムの設定状態のうち、頻繁に変わりそうもないものについては、動作中の設定値の変化を調べないことが多い。元号に関しても、数十年に一回という頻度なので、普通は起動時に設定を読めば、問題ないはず。ただその数十年に一回で問題が発生するのかもしれない。次回の改元のときに正しく動作することを期待しよう。
「5」は、「令和」合字のフォントパターンである。ざっと、標準添付の日本語フォントで合字をだしてみたが、ちゃんと定義されているようだ。全部、代替フォントなのかとおもったら、一部はちゃんとデザインが違う。
「6」も合字関連で、MS-IMEが「れいわ」の読みで正しく合字を候補として表示するかどうか、IMEパッドの文字コード表で令和合字を表示できるといったことだ。なお、Windows付属の文字コード表でも正しく表示されていた。
「7」も、筆者の環境では現象を確認できなかった。しかし、ここも「カレンダーコントロール」を使っているようなので、「3」と同じ原因の問題であろう。
「8」の「代替フォント」（フォールバックフォント）とは、指定されたフォントに文字の形（グリフ）が定義されていない場合に、他のフォントファイルから持ってきて代用するグリフのことだ。Windowsのフォントファイルには、すべての文字のグリフが定義されているわけではなく、一部の文字のグリフしか含まれていない。
たとえば、絵文字はすべてのフォントファイルに含まれているわけではないが、Windowsでは、どのフォントを指定しても、絵文字を表示させることができる。これが「代替フォント」という機能だ。今回のパッチでは、令和合字を含まないフォントファイルのために、令和合字を代替フォントとして登録したのだと思われる。
「9」は、簡単にいうと「令和」を「れいわ」として読み上げることだ。パッチ適用前には「令和」は「よしかず」（誰かの名前？）と読み上げていた。パッチを適用するとちゃんと「れいわ」と読み上げてくれる。
このほか、ちょっと気になったのが、令和合字のUnicode正規化処理だ。令和パッチのあと検証してみたが、令和合字は正規化できなかった。
.NET Frameworkには、Unicode文字を正規化する関数として文字列オブジェクトに「Normalize」というメソッドがある。マイクロソフトのドキュメントによれば、「.NETは、Unicode規格で定義されている4つの正規化形式（C、D、KC、およびKD）をサポートしています（.NET supports the four normalization forms (C, D, KC, and KD) that are defined by the Unicode standard）」と以下のページに記載がある。
つまり、Normalizeメソッドは、Unicodeのルール通りに正規化するわけだ。しかし、今回の令和パッチでは、この動作を確認することはできなかった。これについてはマイクロソフトのサイトに以下の記述があった。
これをそのまま受け取るとすると、マイクロソフトは、令和合字を「令和」の2文字にする「正規化」をサポートしないことになる。実際の開発者に話を聞くに、そもそもNormalizeメソッドは以前から、Unicode正規化にちゃんと対応していないので信用してないとのこと。
となると、上記の説明は「WindowsはUnicode正規化にはもう対応しないよ」という、事実上の公式宣言なのか。だったら、ドキュメントを書き換えておいてほしかった（時間を無駄にしました）。
2019-05-04 20:43:45
