Windowsのシステムロケール「日本語（日本）」はやっぱり特殊？：その知識、ホントに正しい？ Windowsにまつわる都市伝説（203）

本連載第189回では、日本語環境が生み出した「Windows Admin Center」のバグの謎について解説しました。今回も日本語環境が関係する謎を見つけたので紹介します。原因は謎のまま、日本語環境では回避できません（というか、MS-DOSや16bitアプリ向けの互換機能なので、実は何の悪影響もありません）。

[山市良，テクニカルライター]

Windowsにまつわる都市伝説

「©」はUnicodeなのにUnicodeではない？

• ［参考］真夏の怪異、ログオン中のユーザーが1人少ない！　それは「Shift-JIS」の呪い？（本連載 第189回）

　WindowsのNTFSファイルシステムは、MS-DOSや16bitアプリケーション向けに、「8.3（8dot3）」形式の短いファイル名を自動生成する互換機能を提供しています。とある、有名なWindowsの専門書籍（英語）には、その生成方法が説明されています。

　例えば、スペース（空白）やUnicode文字など、MS-DOSで使えない文字、前後のピリオド、最後のピリオドを除く埋め込まれたピリオドを削除するなどです（この後に3つの手順が続きます）。

　書籍に例示されているファイル名で実際にファイルを作成し、「DIR /X」コマンドで8.3形式の短いファイル名を確認してみたところ、3つの例外を除いて、書いてある通りに自動生成されました。

　3つの例外とは、Unicode文字を含む場合です（表1）。書籍には短いファイル名が自動生成されると書いてあるのですが、「©」は短いファイル名が自動生成されず、他の2つはUnicode文字が削除されず、一部がそのまま残ってしまいました（画面1）。

ファイル名	短いファイル名
©	6E2D~1
UnicodeName.φΔЛɅ	UNICOD~1
25¢.two characters	255440~1.TWO
表1　8.3形式の短いファイル名が自動生成されない例外

画面1　Unicode文字を含む3つのファイルが、想定した8.3形式の短いファイル名を自動生成しなかった

　短いファイル名を生成しなかった「©」を含む、書籍で例示されていたUnicode文字は、日本語版WindowsではUnicode文字としては認識されず、通常の文字（MS-DOSで使える文字、実際に使えるかどうかではありません）としてそのまま受け入れているように見えます。ただし、全てのUnicode文字で同様の問題が発生するというわけではなく、「™」や「℗」はUnicode文字として認識され、期待通りの短いファイル名を自動生成しました（画面2）。

画面2　画面2　「™」や「℗」はUnicode文字として認識され、期待通りの短いファイル名を自動生成した

　これはどういうことでしょうか？　この書籍は第7版まで出ている歴史の長い書籍であり、8.3形式の自動生成については、かなり古い版から存在する内容のようです。

　Windowsの新しいバージョンで仕様が変わったのか、それとも、そもそも記述に誤りがあったのかとしばらく悩みましたが、Azure仮想マシンの英語環境で同様の実験をしてみたところ、書籍に書いてある通りに短いファイル名が自動生成されました。どうやら、日本語環境、それもいろいろ試してみて分かったことは、システムロケールが「日本語（日本）」であることが原因のようなのです。

　日本語版Windowsの場合も、システムロケールを「日本語（日本）」から「英語（米国）」に変更し、システムを再起動してから、もう一度、問題のファイルを作成すると、期待通りの短いファイル名が自動生成されました（画面3、画面4）。なお、短いファイル名は、ファイルの作成時やファイル名変更時に自動生成されるものであり、システムロケールを変更しただけで既存のファイルに短いファイル名が再生成されることはありません。

画面3　日本語版Windowsでシステムロケールを「日本語（日本）」から「英語（米国）」に変更してみた

画面4　問題のUnicode文字が、ちゃんとUnicode文字として認識された

　8.3形式の短いファイル名を必要とするようなアプリケーションはもうないと思うので、この問題が重大な互換性問題に発展することはないと思います。

　実は、8.3形式の短いファイル名の自動生成は、「Windows 8.1」以降は起動可能ボリューム以外では既定で「無効」にされていました。「Windows 10」以降はどうなっているのかというと、何台かで確かめてみましたが、「1：システムのすべてのボリュームで 8dot3 名の作成を無効にする」で全て無効になっているPCと、「2：8dot3 名の作成をボリューム単位で設定する」で「C:で有効」（C:以外は無効）、「2：8dot3 名の作成をボリューム単位で設定する」で「C:で無効」（C:以外も無効）のいずれかでした。

　これまで特に設定を変更したことはないので、これらの設定の違いがどこから来たのかは不明です。また、1台だけある「Windows 11」プリインストールPCでは、「1：システムのすべてのボリュームで 8dot3 名の作成を無効にする」で全て無効になっていました。現在の設定は「fsutil 8dot8name query <ドライブ文字:>」コマンドで確認、「fsutil 8dot8name set <ドライブ文字:> <0〜3>」コマンドで変更できます（要管理者権限）。

筆者紹介

山市 良（やまいち りょう）

岩手県花巻市在住。Microsoft MVP 2009 to 2022（Cloud and Datacenter Management）。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。Microsoft製品、テクノロジーを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。近著は『Windows版Docker＆Windowsコンテナーテクノロジ入門』（日経BP社）、『ITプロフェッショナル向けWindowsトラブル解決 コマンド＆テクニック集』（日経BP社）。