WindowsをUTF-8環境に切り替えてみた

今回は WIndows のシステムロケール設定で UTF-8 環境に変更した際の影響について気付きをまとめました。

Windows で UTF-8 生活

日本語版 Windows のシステムのテキストエンコードは シフトJIS です。これは Windows 11 になった今も変わりません。

とはいえ Windows も時流には逆らえなかったのか、最近では「システムロケール設定」でこれを UTF-8 （BOM なしの）に変更することができるようになっています。

Windows 自体が UTF-8 環境になれば、CSV データやテキストの交換で文字化けや文字コード変換に煩わされることも減り、Mac さんや業務システムとのやり取りもスムーズなるはずです。

ただし、この設定は「ベータ」、つまり「お試し版」であり、あくまで技術者の検証用に公開されてたものです。最新の Windows 11 になっても正式にはなりませんでした。

システムロケール設定の変更はシステム全体に影響するものなので、Windows の機能だけでなく、既存のアプリやデータに何か不具合や問題を引き起こす可能性があります。

この設定がベータではなく正式に有効になるのを待っていたのですが、Windows 11 になってもその気配がありません。

もう待っていられないのでこの機会に思いきってシステムロケール設定を UTF-8 環境に切り替えてみて、具体的にどのような影響があるのかを検証してみることにしました。

今時点までの UTF-8 生活で経験した主な気付きをとりあえずまとめると、以下のようになりました。

メモ帳
- シフト JIS のテキストが読めなくなる（文字化けする）
Excel/CSV
- BOM なし UTF-8 の CSV を開くと文字化けする（相変わらず）
  - シフト JIS なら今まで通り開ける
- CSV をシフト JIS で保存できなくなる
ZIP ファイル（圧縮フォルダ）
- Mac からの ZIP が文字化けしない
- 日本語ファイル名の長さ制限が短くなる
Windows 検索
- UTF-8 テキストファイルは検索できない（相変わらず）
プレビューウィンドウ
- 文字化けするかも
Power Automate
- ファイルアクションでシフト JIS のテキストや CSV が読み書きできなくなる
PowerShell
- コマンドレットでシフト JIS の読み書きができなくなる
- スクリプトファイル（PS1）のエンコードも UTF-8
コマンドプロンプト
- コードページが「65001」すなわち UTF-8 になる
  - chcp コマンドでシフト JIS (932) に変更可能
- バッチファイルのエンコードも UTF-8
一部アプリで UI が文字化けする

一言でいうと、UTF-8 環境化した Windows では基本的にシフト JIS のファイルが扱えなくなる、ということです。

それをどう評価するか。

もちろん、今後 UTF-8 のみでよくて、金輪際シフト JIS は使わない、というのであれば問題ありません。

まあ、どちらを取るかという話ですが、普通なら既存のシフト JISのテキストや CSV が読めなくなったり、使い慣れたアプリが文字化けして使えなくなるのは困るのではないかと思います。

また、普段使っているアプリでも UTF-8 環境に対応していない古いものではデータを破損する可能性さえあります。

結論として、システムロケール設定による UTF-8 環境への変更は、本ブログの想定する読者である一般のユーザには今のところお勧めしません（なのでその設定の詳細手順は紹介しません）。ベータ版から正式版になるまで様子見でいいでしょう。

UTF-8 環境の影響メモ

以下UTF-8 生活での気づきのメモを共有しますので、興味のある方はご参考まで。

メモ帳

いつのまにか「メモ帳」(notepad.exe) のエンコードが BOM なしの UTF-8 になっています（Windows 10 Version 1903 以降）。

メモ帳は複数のエンコードに対応し、しかもファイルを開くときに、テキスト内容からエンコードを自動判別します。

メモ帳が判定したエンコードは、ウィンドウの右下のステータスバーで確認できます。ここで「ANSI」と表示されているものが、日本語ではシフト JIS であることを示しています。

【Note】 「ANSI」とはアメリカの規格協会のことです。なぜそれで日本の規格（シフトJIS）になるのかには Windows と文字コードの技術的・歴史的経緯があるのですが、現在の一般ユーザには関係のない話です。分かり難いことこの上ありませんね。 WIndows さんには表示にもう少し気を使ってくれても良かったと思います。

ただし、メモ帳のエンコード自動判定は完璧ではありません。

「ファイル」⇒「開く」から UTF-8 の日本語テキストファイルを開くと、約２/３の確率でシフトJIS（ANSI）と誤判定されて、文字化けします。

そうなったら「開く」ダイアログの右下にある「エンコード」プルダウンで、「自動検出」をやめて「UTF-8」を指定してから開き直せば直ります。

一方なぜか、テキストファイルを直接ダブルクリックして開いた場合、正しく UTF-8 として判定され、文字化けすることはありません。

【Note】「ファイル」⇒「開く」での文字化けは、テキストファイルの先頭から 1024 バイト目の境界を日本語文字がまたいだときに発生するようです。

さて、問題はシステムロケールの設定で UTF-8 環境に切り替えた後です。

なんと、シフト JIS が文字化けします！

「開く」ダイアログで「エンコード」に「ANSI」を選択してもダメです。

試しに UTF-8 のテキストファイルを ANSI 指定で開くと文字化けなしで開きます。 ANSI 指定でも UTF-8 として読み込まれていることになります。

つまり、UTF-8 環境にすると、メモ帳ではシフト JIS ファイルを開くことも保存することも、かなわなくなります。

シフト JIS の既存のテキストファイルを扱えなくなるのは困りものです。他のフリー公開や市販されているテキストエディタを使えば問題ないのでしょうか。

メジャーなテキストエディタについても、現時点での UTF-8 環境の影響を調べてみました。以下にまとめます。間違いがあればご指摘ください。

エディター	シフトJIS	UTF-8	BOM付きUTF-8	手動選択	備考
メモ帳	×	〇	〇	△	ANSI = UTF-8
ワードパッド	〇	×	〇	×	保存はシフトJISのみ
サクラエディタ v2.4.2	〇	〇	〇	〇
秀丸 8.21	〇	〇	〇	〇
EmEditor 22.3.0 (portable)	△	〇	〇	〇	シフトJISは手動選択（少し古いバージョンだと自動判別される）
TaraPad 1.26	〇	×	×	×	UIが文字化けする。文字コード設定が効かない？

Excel で CSV ファイル

システムロケール設定で UTF-8 環境に変更すると、 Excel CSV ファイルの扱いにも影響が出ます。

まず、CVS ファイルを開く方は今まで通りです、残念ながら。

従来、CSV ファイルをダブルクリックしたり、「ファイル」⇒「開く」などして Excel で開いたとき、シフト JIS なら正常に開けますが、BOM なし UTF-8 では文字化けしていました。

UTF-8 環境にすると、シフト JIS はこれまで通り問題なく正常に開けます。そしてUTF-8 でも相変わらず文字化けします。

Excel にはシステムロケール設定の変更が効いていないようです。ちなみに UTF-8 でも BOM 付きなら文字化けしません。

一方、ワークシートを CSV ファイルとして「保存」する際は、BOM なしの UTF-8 として保存されるようになります。こちらはシステムエンコード設定に従っています。ややこしい。

つまりシフト JIS のCSVファイルを普通に Excel で開いて、編集後にそのままで上書き保存（Ctrl+S）すると、UTF-8 で上書きされてしまうので注意が必要になります（しかも次に開いたときに文字化けします）。

UTF-8 の CSV ファイルを文字化けなしで開く方なら、以下のような代替手段があります。

「データの取得と変換」⇒「テキストまたは CSV から」
「テキストファイルウィーザード」

しかし、シフト JIS で保存するほうは、手段がなくなります。

保存ダイアログの「ファイルの種類」で保存形式を選択できるのですが、「CSV (コンマ区切り) (.csv)」や「テキスト (タブ区切り区切り) (.txt)」を選択しても, 保存されるエンコードは BOM なしの UTF-8 になります。「CSV UTF-8 (コンマ区切り)」という選択項目もありますが、これは BOM 付きの UTF-8 として保存します。ややこしい。

UTF-8 環境に切り替えたあとでは、Excel でシフト JIS の CSV を保存することのない運用にするしかありません。

【Note】「テキストファイルウィザード」を使いたい
昔ながらの「テキストファイルウィザード」を使えば、エンコードを指定して CSV ファイルを取り込むことができます。
UTF-8 で読み込むには、「元のファイル」ドロップダウンで「65001 : Unicode (UTF-8)」を指定します（自動で選択されているはず）。

最新の Excel では外部データの取り込みが Power Query メインになってしまって、「テキストファイルウィザード」は非推奨なのか見つけにくくなっています。
「テキストファイルウィザード」を出すには以下の３つのような方法が残されています。
* CSVファイルの拡張子を *.txt などに変更して普通に Excel で開く
* クイックアクセスツールバーやリボンにボタンを登録する
　　⇒ 「ファイル」の「オプション」から「ツールバーのカスタマイズ」を開き「全てのコマンド」から「テキストファイル [テキストからデータを取得]」か「テキストファイル（レガシ）」を探して追加する
　　
　　
* 「データの取得」⇒「従来のウィザード」を復活させる
　　⇒ 「ファイル」の「オプション」から「データ」⇒「レガシデータインポートウィザードの表示」で「テキストから（レガシ）」にチェックを入れる
　　
　　

ZIP ファイル（圧縮フォルダ）

UTF-8 環境では、ZIP ファイルに格納されるファイル名が UTF-8 でエンコードされるようになります。

そのおかげで、Mac からもらった ZIP ファイルでも文字化けしなくなります。

一方その影響で、ZIP 圧縮・展開で以下のような問題が起きます。

既存の ZIP ファイルを展開すると、ファイル名の日本語が文字化けする
長い日本語ファイル名でエラーになる

一つ目のファイル名文字化け問題は、以前に圧縮した ZIP ファイル内のファイル名がシフト JIS で格納されているために起こります。

UTF-8 環境ではそれを UTF-8 として読み出してしまうため文字化けします。

逆に UTF-8 環境で圧縮した ZIP ファイルをシフト JIS 環境のままの Windows で展開するとそちらでも文字化けすることになります。（UTF-8 フラグを付けない）

【Note】 UTF-8 フラグ
ZIP ファイルの仕様ではファイル名のエンコードが UTF-8 であることを示すフラグ（印）を付けることができて、これがあればシフト JIS 環境の Windows で展開しても文字化けすることはありません。
なぜか Windows は UTF-8 環境になってもこの UTF-8 フラグを付けてくれていないのです。

この問題は 7-Zip のような高機能なアーカイバソフトを導入すれば対処できるようです。

ソフトのインストールを避けたいなら、標準機能の PowerShell でも以下のようなスクリプトで展開することができます。

# シフトJISのZIPファイルをフォルダに展開する
function unzip_sjis($sjiszip, $toDir) {
    Add-Type -AssemblyName System.IO.Compression.FileSystem
    $sjis = [Text.Encoding]::GetEncoding("shift_jis")
    [System.IO.Compression.ZipFile]::ExtractToDirectory($sjiszip, $toDir, $sjis)
}

二つ目の長いファイル名エラー問題は、ファイル名の長さが文字数ではなくエンコード後のバイト数で制限されているために起こります。

日本語1文字に使うバイト数はシフト JIS より UTF-8 の方が多いので、格納できる文字数（文字列長）としては UTF-8 のときのほうが少なく（短く）なります。したがって、それまで普通に圧縮できていたファイルやフォルダーでも、UTF-8 環境への移行後にエラーになる可能性があります。

これも出回っているアーカイバを使えば対処できるはずですが、その導入が難しければこれも PowerShell で何とかできます。

以下の記事に掲載されているバッチ（中身は PowerShell）を使うと、長めのファイル名でも圧縮・展開が可能です。またこの記事のバッチで圧縮した ZIP は、シフト JIS 環境の Windows でも文字化けしません（UTF-8 フラグを付ける）。

www.shegolab.jp

【Note】ZIP のファイル名長制限
Windows のエクスプローラーが扱えるファイル名やフォルダ名の文字数は、ファイル名が 255 文字まで、フォルダ名なら 244 文字まで、両方合わせたパス名としては 259 文字まで使用できます。
ところがエクスプローラーは、ZIPファイルを圧縮・展開するときに、この制限を文字数ではなく、エンコード後のバイト数で数えます。
日本語文字の１文字は、シフトJISで２バイト、UTF-8 で３バイトになるので、ファイル名の文字数としては単純計算して、シフト JIS では半分の 127 文字、 UTF-8 では３分の１の 85 文字が限界となり、UTF-8 のときのほうがだいぶ短くなってしまいます。
また、エクスプローラーのパス名長の制限は、ZIPファイルを圧縮・展開しているフォルダをふくむフルパス名に適用されるので、注意しないと場所によってはもっと短いファイル名でもエラーになりえます。

Windows 検索

システムコードページ（エンコード）を UTF-8 に変更しても、Windows デスクトップの検索には影響ありません。

残念ながら。

つまりその意味するところは、 Windows では UTF-8 で保存されたテキストファイルの中身を全文検索できない、ということです。

もともと Windows デスクトップ検索には、全文検索で BOM なしの UTF-8 がヒットしないという問題ありました（BOM付き UTF-8 ならヒットします）。

また、たとえファイル名や英単語でヒットしても検索結果のプレビューが文字化けして日本語の内容が確認できないという問題もあります。

これらは現代 OS の機能として結構深刻な問題だと思うのですが、 Windows 11 でも放置されています。

システムコードページを UTF-8 変更しても状況が変わらないということは、 Windows の検索エンジンがシステムコードページに関係なく、シフト JIS で日本語テキストを解析しているということで、打つ手ナシです。

しかも検索できないばかりか、大量の文字化けゴミデータをせっせとインデックス化していることにもなります。試しに文字化けした文字列のコピペで検索してみると、確かに文字化けのままヒットします。

さてどうしたものでしょう。

どうしても UTF-8 テキストファイルを全文検索したいというのなら、そしてもし文書を保存しているフォルダが「OneDrive」の同期対象になっているのなら、 Web 側から検索するという手段もあります。

ただし、今度はシフト JIS のほうが引っかからなくなりますが。

【Note】BOM なし UTF-8 を全文検索したい
OneDrive の Web ページにある検索窓なら BOM なし UTF-8 を検索できます。
自分の OneDrive の Web ブラウザで開くには、Windows タスクバーの右下にある OneDrive アイコン(☁)をクリックして開くパネルで、「オンラインで表示」を押します。

すると Web ブラウザで自分の OneDrive ページが開き、一番上には「すべて検索」ボックスがあり、これで全文検索ができます。

検索対象は同期フォルダ全体となり、特定のフォルダ配下のみを検索対象に絞ることはできないようです。
また、日本語の解析の問題で、単語によっては登録漏れでヒットしないこともあるようです。

プレビューウィンドウ

エクスプローラーの「プレビューウィンドウ（プレビューペイン）」も、システムコードページ（エンコード）の変更の影響を受ける可能性があります。プレビューウィンドウはアプリを立ち上げずにファイルの中身を確認できる機能です。あまり使われていないかもしれません。

もともと、プレビューウィンドウはテキストファイルを表示するときに、シフトJISでも BOM なしの UTF-8 でも正しく文字化けなしで表示されるようになっています。プレビュー表示用に独自の文字コードの判定が使われているようです。

ところが、筆者が常用している Windows 11 パソコンでシステムコードページを UTF-8 に設定すると、シフト JIS のプレビューで文字化けするようになってしまいました。 UTF-8 では大丈夫です。

そして不思議なことに、同じテキスト内容のシフトJISファイルでも、拡張子が「.txt」ではなく「.csv」だと文字化けが起こりません。

ファイルの種類によって挙動が異なるということは、何のソフト（アプリケーション）がシステムにインストールされているかも、プレビュー表示に関わっている可能性があります。

試しに、何もインストールしていない、すっぴんの Windows 11 で UTF-8 設定をしてみると、シフト JIS でも文字化けが起こりませんでした。

プレビューウィンドウに内容を表示する機能（プレビューハンドラ）は、そのファイルタイプ（TXTなど）を扱うアプリケーションによって置き換えられてしまうことがあるようです。

テキストエディターなどアプリのインストール状況によって、文字化けしたりしなかったりするのかもしれません。

プレビューウィンドウはファイルの整理をするときなどに重宝する便利な機能なのですが、文字化けがするようではちょっと使い物になりません。ただこればかりは Windows だけの責任とは言えないようです。

Power Automate

業務効率化で昨今注目されている Power Automate ですが、UTF-8 環境にするとファイルアクションでのシフト JIS ファイルの読み書きができなくなります。

Power Automate で用意されている TXT や CSV を読み書きするアクションでは、エンコードの選択もできるのですが、これの「システムの既定値」で指定したときのエンコードが UTF-8 になってしまうからです。

つまり Power Automate でもメモ帳のように、シフト JIS ファイルを指定する手段がなくなってしまうのです。

どうしてもシフト JIS のテキストファイルを扱う必要がある場合には、 PowerShell や Python を使ってエンコードの変換プログラムを自分で用意し、スクリプトアクションとして追加することになります。

もし読み込んだテキストを、直後のステップで Excel のアクションで取り込んでいるなら、最初から「Excel」⇒「Excel の起動」アクションで直接「.csv」や「.txt」ファイルを指定するという手もあります。 Excel はシフト JIS の CSV でも文字化けなしで開くことができます。 CSV 保存の方は Excel を使ってもシフト JIS には出来ません。

PowerShell

UTF-8 環境にすると PowerShell の Default エンコーディングが UTF-8 になります。

Get-Content や Set-Content といったファイルの読み書きができるコマンドレットで Encoding パラメータを省略、あるいは Default を指定した場合、BOM なしの UTF-8 として扱われるようになり、シフトJISでは文字化けします。

Out-File やリダイレクトのエンコードは UTF-16LE のままです。（Out-File でも　-Encoding Default をつければ UTF-8 にできます）

Encoding に UTF8 を指定すると、BOM 付き UTF-8 となるのは今まで通り。

PS1 ファイル自体も UTF-8 で読み込まれます、スクリプトがシフト JIS のままだと日本語文字列やコメントが壊れたりエラーの原因となったりします。

結局、PowerShell でも、既存のシフト JIS ファイルを読み書きする手段がなくなることになります。

.Net Framework の API を介せば読めないこともありませんが、メンテコストを考えると現実的ではありません。

$sjis = [Text.Encoding]::GetEncoding('shift_jis') # 932
$path = "～\～.txt"

# System.IO.File を使う
$lines = [IO.File]::ReadAllLines($path, $sjis)

# System.IO.FileReader を使う
# 本当は例外処理も必要
$stream = [IO.StreamReader]::new($path, $sjis)
while(!$stream.EndOfStream) {
    $line =  $stream.ReadLine()
    echo $line
}
$stream.close()

PowerShell ではスクリプトもデータも UTF-8 に変換・移行した方がいいでしょう。

PowerShell のエンコード設定は複雑で理解しきれていないのですが、関係する設定内容を確認すると以下のようになりましたので理解できる人のご参考まで。

コマンドプロンプト / バッチファイル

UTF-8 環境に変更後、コマンドプロンプトで chcp コマンドを確認すると、コードページに「65001」すなわち UTF-8 が反映されています。

当然、シフトJIS のテキストファイルを表示すると文字化けします。

バッチでも、既存のバッチファイルで文字列やコメントに日本語文字列が含まれているとエラーになります。（逆いいうと、日本語さえ使われていなければ（半角の英数記号文字だけなら）そのまま運用しても問題ないはずです）

対処としては、バッチファイルを UTF-8 に変換するか、あるいは実行直前に chcp 932 でコードページをシフト JIS に変更しておけば、問題なく稼働するはずです。

【note】 少し前まではコマンドプロンプトの「プロパティ」で、デフォルトのコードページを設定変更できたはずなのですが、最近の更新でプロンプトが「ターミナル」に統合されたためか、その設定項目にアクセスできなくなったようです。

以下その他の気付いた注意点です。

BOM 付きの UTF-8 のファイルをバッチやコマンドで読み込むと不具合が起こる可能性があります。バッチやコマンドは BOM に関知しないので、ファイル先頭の BOM 自体も取り込んでしまい、ゴミとして残るからです。
more コマンドで UTF-8 テキストファイルを開くと日本語の行をスキップする、という不具合があります。たぶん修正されることはないでしょう。

【Note】コードページとは
「コードページ（CP）」は Windows で定義されている特定のエンコードに対応した番号です。シフト JIS は 932、 UTF-8 なら65001になります。

まとめ

システムロケール設定でシステムコードページ（エンコード）を UTF-8 に変更したとき、普段使いにどのような影響がでるのか、気が付いた範囲でまとめました。

主な点としては、

既存のシフト JIS ファイルが扱えなくなる
UI表示の文字化け、既存データの破損が起こる可能性がある
UTF-8 に対応してほしかった機能が未対応
- Excel の CSV 読み込み、Windows 全文検索など

シフト JIS ファイルが扱えなくなる問題については、この際シフト JIS と決別することにして、既存ファイルを全て UTF-8 に変換することになるでしょう。ただし、全文検索はできなくなります。

Excel が UTF-8 の CSV ファイルを自動で開けないのは本当に残念なことです。 Excel は独自の言語設定を持っているのでシステムの影響を受けないのでしょう。そのうち対応されると信じています。

既存データの破損については、まだ確認できた現象はありませんでしたが、その潜在的リスクは残っていると思っています。

一方利便性としては、業務システムやツール、Mac ユーザなどとのデータのやり取りがスムーズになるのは確かです。特にプログラムや生データを扱う技術者にとっては快適になるでしょう。

何度か行っていますが結論としては、まだ一般のビジネスユーザーにはお勧めしません。今わけの分からない不具合に時間を取られるよりは、ベータが取れて正式に公開されてからでも遅くはないはずです。

個人的には、もうしばらくこの UTF-8 生活を続けてみようと思います。また何か問題が見つかったら本記事に追記します。もし読者で UTF-8 環境を試された方でも、何か気付いた点がありましたら教えてください。

www.shegolab.jp

参考資料

編集履歴

[2023/05/22] 公開
[2023/07/08] 文面、タイプミスの修正

シーゴの Excel 研究室

タイトル変更しました（旧称：今日を乗り切るExcel研究所）

最新の Windows UTF-8 事情

Windows で UTF-8 生活

UTF-8 環境の影響メモ