.NET 10 の画面有りアーキテクチャの解説とサンプルコード

（2026年4月25日、Avalonia UI の解説とサンプルを追記しました）

Avalonia UI のライセンス規定を解説します

（2026年5月9日、Avalonia UI のライセンスの解説記事を公開しました）

サンプルプログラム公開の理由

この記事とサンプルコードを作成した理由としては、.NET はその内容をよく誤解されることが多く、誤解を解消する上で、分かりやすい解説と具体的なサンプルプログラムを見せる必要があると考えたからです。

「.NET の誤解」の例としては、以下の様な物があります。

「.NET は Windows でしか動かない」

「ASP.NET は一つの技術である」「ASP.NET が使える（開発経験がある）」

「C# は C/C++ 系の開発言語である」

等々は、代表的なものです。 「Java と javascript の違いが分からない」と同じようなものです。

ITシステム開発の現場には、ITエンジニアだけが携わっているわけではなく、業務担当者や営業担当などITエンジニアではない人々も多く関わっていますから、こういう誤解は無くなりません。

ただ、説明しなければ誤解も無くならないので、このネット記事のような媒体で地道に解説していくしかありません。

上記の誤解について簡単に解説すると以下のようになります。

誤解1「.NET は Windows でしか動かない」

.NET には 旧 .NET Framework と 最新の .NET(Core) の二種類があり、Windows でしか動作しないのは、旧 .NET Framework だけであり、最新の .NET(Core) は Windows だけではなく、macOS,Linux,iOS,Android で動作します。 .NET 10 は、.NET(Core) です。

誤解2「ASP.NET は一つの技術である」

.NET 系の求人には「ASP.NETの開発経験がある」という条件をよく見かけますし、IT人材系の営業職の人々も「ASP.NET は一つの技術である」「ASP.NETの開発経験があれば、ASP.NETは全て扱える」という認識の人々が圧倒的に多数派です。

この認識は、かなり大雑把すぎて、ほぼ間違っており、様々なトラブルの原因になっています。

この種類の誤解を解消したかったのも、サンプルプログラムと解説記事を公開した理由の一つです。

「.NET 10 の画面有りアーキテクチャの解説とサンプルコード」を読んで頂ければ分かりますが、ASP.NETとはMicrosoft が .NET技術で提供するWeb技術全般に付けているブランド名であり、ASP.NETブランドの中に様々な技術製品やアーキテクチャが提供されています。

つまり、「ASP.NET は一つの技術である」という認識は間違いであり、「ASP.NETの中に様々な技術製品が存在する」のが真実です。

ざっくりと例を挙げると、ASP.NET WebForms , ASP.NET Core MVC , ASP.NET Core Razor Pages , ASP.NET Core Web API , ASP.NET Core gRPC Service , ASP.NET Minimal API といった技術製品が提供されています。

これらの解説は、「.NET 10 の画面有りアーキテクチャの解説とサンプルコード」の中に書いているので、ここでは解説しません。

例えば、ASP.NET WebForms の開発経験のある人材は、ASP.NET Core MVC や ASP.NET Core Razor Pages を扱う事はできません。逆も同様です。 （ASP.NET WebForms は、旧.NET Framework の技術で既に廃止されております。Core と付く物は全て .NET (Core) の技術です）

ASP.NET Core Web API の開発経験のある人も ASP.NET Core gRPC Service は簡単には扱えないでしょう。

IT人材の募集を行う方は、ASP.NET の中のどの技術の開発経験を求めるのか、具体的に記載した方が良いですし、営業や管理職の方々も、そのぐらいの認識は持っておくべきだと思います。

この手の疑問は、生成AIに質問すれば分かる事なので、そろそろ調べておくべきでしょう。

様々なトラブルの原因は、技術を要求する側の雑な認識の方にあるケースが少なくないのです。

誤解3「C# は C/C++ 系の開発言語である」

これは「Java と javascript の違いが分からない」人々と同様の人々ですね。

C# は、CLR という .NET の仮想環境で動作するマネージドコードを主に開発するために作られた開発言語であり、その位置づけや機能特性は、Java に似た物になります。CLR は JavaVM に相当する VM（仮想マシン）です。

C言語やC++は、ネイティブコードを生成する開発言語なので、C#とは似ても似つかぬ言語です。

現代の開発言語は全て、C言語とC++を祖先として、言語の文法などを作成しているので、C#もC言語とC++を祖先としていますが、それならば Java も PHP も Go も Python もC言語とC++由来の言語と言えます。

「C#がC言語やC++系統の言語である」という認識に、正当性を見いだすのは難しいです。 無駄に誤解とトラブルを招くだけで、有害な認識だと思います。

他にも色々ある

ここでは .NET の話だけを挙げましたが、他の技術でも同様の誤解が蔓延していると思います。

いちいち例を挙げても切りが無いので挙げませんが、「Swift と SwiftUI を混同している」とか「Git と GitHub を混同している」とか「WSL と Git Bash を混同している」とか、たくさんあるでしょう。

最近広まりつつある Blazor では、Razorコンポーネントがありますが、これを ASP.NET の Razorページと混同する人もこれから増えていくでしょう。

これらの誤解は、誤解する方も悪いですが、説明しない方の責任もあるので、ブログ記事などで地道に解説記事を書いておくのが、誤解を払拭する最低限の努力と言えるでしょう。

解説がない状況では、誤解する者を批判することも、正当性の面で苦しくなります。

サンプルコードについて

サンプルコードの使い方は、「.NET 10 の画面有りアーキテクチャの解説とサンプルコード」の中で必要最小限書いてあります。

GitHub リポジトリのサンプルコードの README.md など、まだぜんぜん書いていませんが、これから少しずつ書いていくつもりです。

最小限、解説記事とサンプルコードだけ完成した時点で公開しています。今後も細部の修正は行いますので、ご了承ください。

リリースや配布の機能は作っていないので、現状では IDE でソリューションを開いて起動するしかありません。

ライセンスについて

GitHub リポジトリのサンプルコード IssueBoard にはライセンスの記載がありませんが、全て MITライセンス とお考えください。

詳細は、後日 README.md などに書いていくつもりです。

今は、この記事で暫定的に「IssueBoard は MITライセンスである」と宣言しておきます。

MITライセンスは、このプログラムを利用・再配布する場合、著作権表示とライセンス条文を、ソフトウェアの複製または実質的部分に含めることを義務づけるライセンスです。また、本ソフトウェアは無保証であり、利用者の自己責任で使用することに合意することが求められます。

この条件を受け入れることを要求するライセンス規定です。

これは、私だけでは無く、世界の MITライセンス 全てに当てはまる条件なので、覚えておいてください。

商用利用は制限されませんが、利用者の自己責任での利用が求められます。

以上、お知らせでした。

winget でのインストールが可能になりました

先日、Windows 版は winget によるリリースを開始し、Windows標準の winget install コマンドで、簡単に mfsr と mfprobe をインストールできるようになりました。

rmsmf と txprobe は、これまでと同じで .zip ファイルでのインストールする方式のままです。

私としては、.NET Framework 4.8 でビルドしている rmsmf と txprobe よりも、.NET10 でビルドしている mfsr と mfprobe を極力使用して頂きたいので、このようにしました。

macOS と Linux OS へ対応しました

元々、.NET10 で開発していますから、macOS と Linux OS でもリリースすれば動作するように開発しています。

しかし、これまでは Mac と Linux へのリリース手段を提供していませんでした。

リリースに時間がかかった理由として、macOS と Linux OS はCPUの種類やカーネルのバージョンなどの種類が多く、各種の環境に合わせたネイティブコードでのリリースが困難になるため、どのようなリリース方法が良いか判断に迷ったからです。

Windows版は、Native AOT によりネイティブコードでリリースしています。 winget でインストールする mfsr と mfprobe はネイティブコード版です。

今回、macOS と Linux OS に対しては、.NET10 のマネージドコードのアセンブリで提供することにしました。

マネージドコードの実行には .NET10 の Runtime（ランタイム） が必要になります。

しかし、.NET10 Runtime が、CPUの違いやカーネル・glibc などの違いを吸収してくれるので、OS に .NET10 Runtime さえインストールされていれば、どこの環境でも稼働するメリットがあります。

Mac には、インテルCPU版・Apple Silicon版・A18 Pro版と三種類のCPUがあり、macOSのバージョンも新旧でいくつか並行して提供されています。

Linuxはディストリビューションが多数ありカーネルやglibcのバージョンも多数並行して提供されています。

これら全てにネイティブコードを提供することは、難しいと思います。

これらの違いは、 .NET10 Runtime に吸収してもらい、mfsr と mfprobe は Runtime だけに合わせる形式での提供が、一番効率が良く信頼性も高いと考えました。

アセンブリは nuget.org で提供しています

Windows版のネイティブコードは、winget で提供していますが、macOS と Linux OS へのマネージドコードでの提供は、nuget.org で提供しています。

インストールには dotnet コマンドで dotnet tool install によってインストールします。

Windowsでは二つの提供がある

マネージドコードでの提供でお気づきの方もいると思いますが、nuget.org でのマネージドコードでの提供は、Windowsでもインストールすることが可能です。 つまり、Windowsでは winget 提供のネイティブコード版と、nuget.org 提供のマネージドコード版の二種類を提供していることになります。

私としては、Windows ではネイティブコード版を利用して欲しいと考えいますが、マネージドコード版もWindowsで同様に動作します。

正直なところ、どちらを使っても違いはほとんど無いです。

違いはマネージドコード版には .NET Runtime が必要なことぐらいです。 好きな方を利用してください。

なお、環境変数 Path の関係で両方使用することはできないと思います。

.zip のダウンロードは必要無い

winget install でも dotnet tool install でも、事前に mfsr と mfprobe の .zip ファイルのダウンロードは必要無いです。

それぞれのコマンドを実行すればインストールできます。

具体的なインストール方法については、以下のページで解説しています。

mfsr-mfprobe インストール解説

使い方の解説は、以前から紹介していますように、以下の二つのページで解説しています。

rmsmf-txprobe & mfsr-mfprobe 使い方の分かりやすい解説

PowerShellの文字エンコーディング問題に終止符を打つ：BOM・改行コードを自在に扱う方法

以上、「お知らせ」でした。

以前から解説していますように、PowerShell 及び cmd では、現状のテキストファイルの文字エンコーディング・BOMの有無・改行コードの種類を確認する機能は提供されていません。
PowerShellのスクリプトを作成すればある程度確認することはできますが、必要になる度にスクリプトを作成するのは、実用的ではありません。

この記事では、PowerShell 上での文字エンコーディング変換、BOMの変換、改行コードの変換方法の具体例を示しつつ、その問題を解説したいと思います。

コマンド操作例の中に登場する $PWD とは、PowerShell のカレントディレクトリを示す変数です。
コマンド操作例の中には、.NETクラスのメソッドを呼び出す物も含まれています。
PowerShellのカレントディレクトリと、.NETクラスのカレントディレクトリは異なるディレクトリである場合が多いので、コマンド中でカレントディレクトリを指定する場合は $PWD を使用するとどちらも同じディレクトリを指定できるので安全に操作できます。

コマンド操作例は、Windows PowerShell 5.1 でも PowerShell 7.x でも使い方に違いはありません。

文字エンコーディングの確認

PowerShell と cmd では、既存のテキストファイルの文字エンコーディングを確認する機能は提供されていません。
しかし、PowerShell スクリプトにより、テキストファイルの先頭を4バイト読み込み、BOMのバイナリパターンを読むことは可能です。

$bytes = [System.IO.File]::ReadAllBytes("$PWD\text1.txt")
$bytes[0..3] | ForEach-Object { "{0:X2}" -f $_ }

# 実行結果(UTF-8 BOMあり)
EF
BB
BF
E3

この方法だと、BOMのある Unicode テキストならば文字エンコーディングを判別することが可能ですが、UTF-8などBOMの無い Unicode テキストや SHIFT_JIS テキストの場合は、文字エンコーディングを判別できません。
Windows環境では、SHIFT_JIS、 UTF-8(BOM無し)、UTF-8(BOM有り)、UTF-16LE(BOM有り) が共存していますので、これでは実用になりません。

次は、文字エンコーディングの変換方法の実例です。

通常のコマンドレットを使用する

テキストファイルを入出力するコマンドレットには標準で -Encoding オプションが存在します。
-Encoding オプションにより、対象テキストファイルの文字エンコーディングを指定することができるので、複数のコマンドレットを組み合わせることで、文字エンコーディングの変換を行うことができます。
以下は、SHIFT_JIS から UTF-8 へ変換する実例です。
Get-Content で SHIFT_JIS テキストを読み込み、オブジェクトパイプラインで Set-Content に送り、Set-Content で UTF-8 の文字エンコーディングを指定して、新規テキストファイルに書き込みます。
UTF-8のBOM無しと、UTF-8のBOM有りの二例を示します。

# Shift_JIS -> UTF-8 (BOM 無し)
Get-Content -Encoding SJIS "$PWD\text1.txt" | Set-Content -Encoding UTF8 "$PWD\text1set.txt"

# Shift_JIS -> UTF-8 (BOM あり)
Get-Content -Encoding SJIS "$PWD\text1.txt" | Set-Content -Encoding UTF8BOM "$PWD\text1setb.txt"

このやり方は、あらかじめ読み取りテキストファイルの文字エンコーディングが分かっていないと使用できません。

また、対象テキストファイルに上書きすることは不可能です。
必ず別のテキストファイルに出力することになります。

そのため、ワイルドカードを使用して複数ファイルを一括で処理することもできません。
もし、複数ファイルを一括で処理する必要があるのなら、スクリプトを作成してループ処理を作成する必要があります。

手軽にできるものではありません。

.NETクラスを使用する

PowerShell は .NETクラスのメソッドを直接使用することができます。
ここでは、.NETクラスのメソッドを使用したやり方の実例を示します。

# Shift_JIS → UTF-8 (BOM なし)
$sjis    = [System.Text.Encoding]::GetEncoding("shift_jis")
$utf8nobom = New-Object System.Text.UTF8Encoding($false)
$content = [System.IO.File]::ReadAllText("$PWD\text3.txt", $sjis)
[System.IO.File]::WriteAllText("$PWD\output3.txt", $content, $utf8nobom)

# UTF-8 → Shift_JIS
$sjis = [System.Text.Encoding]::GetEncoding("shift_jis")
$utf8 = [System.Text.Encoding]::UTF8
$content = [System.IO.File]::ReadAllText("$PWD\text2.txt", $utf8)
[System.IO.File]::WriteAllText("$PWD\output2.txt", $content, $sjis)

# Shift_JIS → UTF-8 (BOM 有り)
$sjis    = [System.Text.Encoding]::GetEncoding("shift_jis")
$utf8bom = New-Object System.Text.UTF8Encoding($true)  # BOM あり
$content = [System.IO.File]::ReadAllText("$PWD\text3.txt", $sjis)
[System.IO.File]::WriteAllText("$PWD\output3b.txt", $content, $utf8bom)

スクリプトを作成する場合は、このやり方が参考になる場合もありますが、通常の使用では先のコマンドレットを使用したやり方の方が、手軽で良いでしょう。

BOMの確認方法

文字エンコーディングの確認機能は提供されていないので、BOMの確認機能も存在しません。
しかし、PowerShellはスクリプトから .NETクラスを直接使用できるので、BOMを確認するスクリプトを作成することはできます。

# BOM の確認
function Test-BOM {
    param([string]$Path)
    $bytes = [System.IO.File]::ReadAllBytes($Path)
    if ($bytes[0] -eq 0xEF -and $bytes[1] -eq 0xBB -and $bytes[2] -eq 0xBF) {
        return "UTF-8 with BOM"
    } elseif ($bytes[0] -eq 0xFF -and $bytes[1] -eq 0xFE) {
        return "UTF-16 LE with BOM"
    } elseif ($bytes[0] -eq 0xFE -and $bytes[1] -eq 0xFF) {
        return "UTF-16 BE with BOM"
    } else {
        return "BOM なし"
    }
}
Test-BOM "$PWD\text2.txt"

ご覧の通り、PowerShellスクリプトでBOMの確認は可能ですが、手軽とはいえません。

BOMを付ける

対象テキストの文字エンコーディングが分かっているのなら、BOMを付けるのは、コマンドレットで比較的簡単にできます。

Get-Content  -Encoding UTF8 "$PWD\text1.txt" | Set-Content -Encoding UTF8BOM "$PWD\text1set.txt"

以下は .NETクラスを直接使用した実例です。

# BOM を付ける（UTF-8 BOM なし → BOM あり）
$utf8nobom = New-Object System.Text.UTF8Encoding($false)
$utf8bom   = New-Object System.Text.UTF8Encoding($true)
$content   = [System.IO.File]::ReadAllText("$PWD\text2.txt", $utf8nobom)
[System.IO.File]::WriteAllText("$PWD\text2out.txt", $content, $utf8bom)

# UTF-16 LE（BOM あり）で保存
$utf16le = [System.Text.Encoding]::Unicode   # = UTF-16 LE with BOM
$content = [System.IO.File]::ReadAllText("$PWD\text1.txt", [System.Text.Encoding]::UTF8)
[System.IO.File]::WriteAllText("$PWD\text1out16.txt", $content, $utf16le)

BOMを削除する

BOMを付けるのも、BOMを削除するのも、コマンドレットの使い方は同じです。

Get-Content  -Encoding UTF8BOM "$PWD\text1.txt" | Set-Content -Encoding UTF8 "$PWD\text1set.txt"

.NETクラスを使用したやり方は、BOMのバイナリパターンを直接指定して削除し、BOMより後ろの全バイナリを、バイナリファイルとして書き込むやり方になります。

# BOM を除去（UTF-8 BOM あり → BOM なし）
$bytes = [System.IO.File]::ReadAllBytes("$PWD\text1.txt")
if ($bytes[0] -eq 0xEF -and $bytes[1] -eq 0xBB -and $bytes[2] -eq 0xBF) {
    $bytes = $bytes[3..($bytes.Length - 1)]
}
[System.IO.File]::WriteAllBytes("$PWD\text1out.txt", $bytes)

ご覧の通り、.NETクラスではバイナリ操作が必要になり、手軽とはいえません。

改行コードの確認と変換

PowerShell と cmd は、改行コードについては、一貫して CR-LF を使用します。
よって、改行コードを確認したり変換する機能はどこにも存在しません。
.NETクラスを直接使用しスクリプトを作成して確認するしかありません。

# 改行コードの確認
$bytes = [System.IO.File]::ReadAllBytes("$PWD\text1.txt")
$hasCR = $bytes -contains 0x0D
$hasLF = $bytes -contains 0x0A

if ($hasCR -and $hasLF) { "CRLF (Windows)" 
} elseif ($hasCR)          { "CR のみ (Classic Mac)" 
} elseif ($hasLF)          { "LF のみ (Unix/Linux)" 
} else                     { "改行コードなし" }

改行コードの変換も、同様に.NETクラスを直接使用したスクリプトで行う必要があります。

# CRLF → LF
$enc     = [System.Text.Encoding]::UTF8
$content = [System.IO.File]::ReadAllText("$PWD\text1.txt", $enc)
$content = $content -replace "`r`n", "`n"
# WriteAllText は内部で環境依存の改行を追加しないよう、WriteAllBytes を使う
$outBytes = $enc.GetBytes($content)
[System.IO.File]::WriteAllBytes("$PWD\text1lf.txt", $outBytes)

# LF → CRLF
$enc     = [System.Text.Encoding]::UTF8
$content = [System.IO.File]::ReadAllText("$PWD\text1.txt", $enc)
# 既に CRLF の箇所を二重変換しないよう、まず LF のみを対象にする
$content = $content -replace "(?<!\r)`n", "`r`n"
$outBytes = $enc.GetBytes($content)
[System.IO.File]::WriteAllBytes("$PWD\text1crlf.txt", $outBytes)

PowerShell標準機能の問題

PowerShell と cmd の環境では、SHIFT_JIS・UTF-8のBOM無しとBOM有り・UTF-16LEのBOM有りの四種類の文字エンコーディングテキストが、共存しています。
UTF-8のBOM無しとBOM有りが両方存在しているため、BOMによる文字エンコーディングの識別が意味を持ちません。
よって、ユーザーはBOMに頼らない文字エンコーディングの識別機能を必要とするのですが、そのような機能は標準では提供されておりません。

文字エンコーディングとBOMの変換機能は、標準コマンドレットの -Encoding オプションによって提供されています。
しかし、テキストファイルの読み取りと、書き込みのコマンドが別々に提供されており、両者をパイプで繋いで利用する仕様なので、ワイルドカードなどによる複数一括処理ができません。
また、対象ファイルに上書きすることもできないので、一度別のテキストファイルに出力して、元ファイルと入れ替える手間が掛かります。

改行コードについては、一貫して CR-LF を使用しているため、変換機能は存在しません。
PowerShellスクリプトでバイナリレベルの操作編集を行う必要があります。

よって、PowerShellの標準機能だけでは、UNIX環境とWindows環境の間でのテキストファイルの交換に対応するのは、難しいのが実情です。

Windowsの文字エンコーディング問題の解説は、過去に書いておりますので、詳しく知りたい方は以下の記事をご覧下さい。

Windows 固有の文字エンコーディング問題

Windows 11 標準アプリ 文字エンコーディング対応状況まとめ

Windowsコンソールの文字エンコーディング対応状況を検証する

Windows 11 環境でのテキストファイル新規作成時のデフォルトエンコーディング検証の総まとめ

一般的な問題の対策

PowerShellの標準機能だけでは、対策として不十分なので、一般的にはUNIXツールをWindows環境に導入して、対策します。
UNIXツールについては、以下の記事で詳しく解説しています。

Windowsで文字エンコーディング・改行コードを扱う「UNIXツール」の現実と課題

mfsr と mfprobe による対策

私は、このような標準機能の限界を克服するため、文字エンコーディング・BOM・改行コードを一括で検知・変換できる mfsr と mfprobe という対のツールを提供しています。

そのマニュアルは以下になります。

rmsmf-txprobe & mfsr-mfprobe 使い方の分かりやすい解説

ここで、mfsr と mfprobe を使用した、文字エンコーディングの変換・BOMの追加と削除・改行コードの確認と変換の方法を、解説したいと思います。
mfsr と mfprobe は、Window PowerShell 5.1 でも PowerShell 7.x でも cmd でも、同じように使用できます。
PowerShell のオブジェクトパイプラインに依存しない仕様になっているので、PowerShell以外のシェルでも使用できます。

mfprobe による確認（文字エンコーディングとBOMと改行コード）

mfprobe は対象テキストファイルの文字エンコーディングとBOMの有無と改行コードの種類を探索して一度に表示します。
ファイル名にはワイルドカードが使用でき、複数テキストファイルの確認が一度にできます。
また、その結果をテキストファイルへ出力できます。
オブジェクトパイプラインを経由しないので、cmd や Git Bash などでも使用可能です。

# 通常の使い方
mfprobe text1.txt

# 複数ファイルの一括確認
mfprobe *.txt

# サブディレクトリ配下ファイルの一括確認
mfprobe -d *.txt

# 確認結果のファイルへの出力
mfprobe -d *.txt -o:result.txt

注意事項として、Git Bash などUNIXシェルで使用する場合は、ワイルドカードをダブルクォーテーションで囲んで、UNIXシェルがワイルドカード展開をしないようにする必要があります。
この点は mfprobe と mfsr で、同様です。

# bash で使用するとき
mfprobe "*.txt"

mfsr による文字エンコーディングの変換

文字エンコーディングを変換するときは、mfprobe ではなく mfsr を使用します。
mfprobe は読み取り専用コマンドであり、更新する機能は mfsr に集約しています。
テキストファイルの文字エンコーディングなどを確認するだけなら、誤って更新することを防ぐために、読み取り専用コマンドと更新コマンドを分けて開発しています。
書き込み先文字エンコーディングは /w: オプションを使用して変換先の文字エンコーディングを指定します。
オプションの頭文字は / (スラッシュ)でも - (ハイフン)でも、どちらでも良いです。
/w: の : (コロン)はオプションのパラメータの指定子です。: の前後にはスペースを空けないように注意してください。
: (コロン)は、= (イコール)でも代用できます。 オプションの位置はコマンド名より後ろであれば順番は自由です。

# 通常の使い方
mfsr text1.txt /w:utf-8

# 読み取り文字エンコーディングの指定もする場合
mfsr /c:shift_jis text1.txt /w:utf-8

# 複数ファイルを一括変換
mfsr *.txt /w:utf-8

# : は = でも代用可能
mfsr *.txt /w=utf-8

BOMの変換方法

BOMについても、確認は mfprobe を、変換更新は mfsr を使用します。

BOMの確認

mfprobe は、ファイル名と文字エンコーディング名と改行コードの種類とBOMの有無を一度に表示するので、それらの確認は全て以下の様に使用して確認します。

mfprobe text1.txt

mfprobe *.txt

BOMの追加

BOMの更新には、/b: オプションを使用します。
/b:true で「BOMを追加する」、/b:false で「BOMを削除する」と動作更新します。
/b: オプションが無ければ現状維持になります。

# text1.txt にBOMを追加する
mfsr text1.txt /b:true

# 複数ファイルに対して一括でBOMを追加する
mfsr *.txt /b:true

BOMの削除

BOMの削除も「BOMの追加」の説明の通りに使用します。

# text1.txt のBOMを削除する
mfsr text1.txt /b:false

# 複数ファイル一括でBOMを削除する
mfsr *.txt /b:false

BOMの操作は、Unicode に対してのみ有効な操作で、Shift_JIS などBOMが存在しない文字エンコーディングの場合は、/b: オプションが無視されます。

改行コードの変換方法

改行コードについても、確認は mfprobe を、変換更新は mfsr を使用します。

改行コードの確認

mfprobe は、ファイル名と文字エンコーディング名と改行コードの種類とBOMの有無を一度に表示するので、それらの確認は全て以下の様に使用して確認します。

# 改行コードなど確認する
mfprobe text1.txt 

# サブディレクトリ配下も含めて複数ファイルを一括で確認する
mfprobe *.txt /d

改行コードの変換

改行コードの変換更新には、/nl: オプションを使用します。
/nl:crlf で「Windows型改行コード」、/nl:lf で「UNIX型改行コード」に変換し更新します。
/nl: オプションが無ければ、改行コードを変更しません。

# UNIX改行形式に変換する
mfsr text1.txt /nl:lf

mfsr text1.txt /nl:unix

# Windows改行形式に変換する(複数一括変換)
mfsr *.txt /nl:crlf

mfsr *.txt /nl:win

「Windows型改行コード」は、/nl:crlf 以外にも /nl:win や /nl:w も使用できます。
「UNIX型改行コード」は、/nl:lf 以外にも /nl:unix や /nl:u も使用できます。

ちなみに /nl は New Line の略です。

文字エンコーディング問題は、まだまだ終わらない

古い文字エンコーディング問題は、Windowsだけの問題ではなく、日本社会全般に横たわる問題です。
特に歴史的経緯でWindowsに多くの問題が現れているだけであり、Windowsだけの問題ではないです。
この辺の話は、以下の記事で解説しました。

「文字化け」はなぜ終わらない？ 日本のITを縛る文字エンコーディングの深い闇

古い文字エンコーディング問題が一番大きな問題として現れているのは、Windowsよりも自治体情報システムの「外字」の問題でしょう。
他にも医療系システムや金融機関のレガシーシステムなども問題です。
いずれも、古いデータがペタバイト級のデータ量に及んでおり、コンバートもままならない状況と聞きます。

長期的には、UNIX標準に全てのテキスト規格が集約されていくことは、ほぼ確実の状勢なので、Windows環境の膨大なテキストのレガシーデータ問題は、これからも課題として存続し続けるでしょう。
今後は、新たに改行コードが問題として現れてきそうな気がしています。

「古い文字エンコーディングが少なくとも Shift_JIS, UTF-8,UTF-16LEの三つがあり確実に識別する手段は提供されていない」
「UTF-8を使用する場合、BOM付きとBOM無しの両方が共存しており、その識別はユーザーの自己責任になっている」
「WSLや Git などでUNIX環境とテキストファイルの相互交換する場合、CR・LF と LF の改行コード仕様の差異に手動で対処しなければならない」
「これらの問題を解決するのに良いツールとして file , iconv , nkf というコマンド製品がUNIX環境で提供されている」
「PowerShell や cmd では、文字エンコーディング・BOM・改行コードを確認する標準機能は提供されていない」

以上が、前回の記事で解説した内容の概要です。

この記事では、Windows 上で使用できる文字エンコーディングを確認したり、変換したりできる各種のツールについて、ここで解説したいと思います。
もちろん、BOMや改行コードの確認・変換も含めて解説します。

前回の記事　:　Windows 固有の文字エンコーディング問題

問題の概要

タイトルでは「Windows で使える…」と書いていますが、現実のところ文字エンコーディングとBOMと改行コードの確認と変換を行う標準的ツールは、UNIX環境で開発提供されており、それらをWindowsで使用するには、Windows環境にUNIXのシェルを導入しなければ使用する事ができません。
タイトルの「…その問題について」とは、UNIXシェルでしか標準的ツールが使用できないことを示しています。
PowerShell でも文字エンコーディングの変換とBOMの変換は可能ですが、改行コードの確認・変換や既存のテキストファイルの、文字エンコーディングとBOMの確認はできません。
前回の記事「Windows 固有の文字エンコーディング問題」でも解説したように、Windows環境におけるテキストファイルの主な問題は、「BOM付きUTF-8」と「BOM無しUTF-8」と「Shift_JIS」のテキストファイルが混在していて、BOMだけではそれらを識別できない点にあります。
そしてそれらを識別できるツールがUNIX環境でしか提供されていないのが、問題なのです。

この記事では、Windows環境で使用できる文字エンコーディング・BOM・改行コードの確認・変換ができる標準的ツール製品の紹介とその問題点を解説します。

PowerShellを説明すると長くなるので、別の記事で見送りたいと思います。

UNIX環境の主要コマンドツール

テキストファイルが使用している文字エンコーディングとBOMと改行コードの確認を行う標準的コマンドツールは以下の物になります。

nkf（Network Kanji Filter）は日本語処理のために日本で開発されたツールで、海外ではほとんど使われません。海外では iconv + dos2unix の組み合わせが標準です。

世界的な意味での標準コマンドは、iconv , file , dos2unix , unix2dos です。
nkf は日本で開発された日本語文字エンコーディングに特化したコマンドで、日本語以外では使用できません。その代わり日本語文字エンコーディングに関しては最も信頼できるツールと言えるでしょう。

世界的標準コマンドの iconv , file , dos2unix , unix2dos は、bash や zsh などのUNIXシェル環境でしか使用できません。
PowerShell や cmd などの Windowsシェル環境では使用できません。

nkfコマンドもオリジナルはUNIXシェル環境（bashやzsh）向けに開発されていますが、nkfに限りWindows環境に移植されたクローンが存在し、一応 Windowsシェル環境でも使用することができます。
しかし、nkf のオリジナルコマンドが UNIXシェル環境で開発されているため、その仕様は UNIXシェル環境の仕様に最適化しています。当然のことです。
よって、nkf を PowerShell や cmd などの Windows環境で使用すると、使えない機能がいくつかあり、現実的には nkf の真価を発揮できないのが現実です。
これは nkf コマンドが悪いわけではなく、「Windowsに最適化したコマンドが存在しない」事が問題なのです。

次に、詳細を説明します。

Windows環境にUNIXシェルを導入する

Windows環境でUNIXシェルを使用する方法は、いくつか存在します。

WSL（Windows Subsystem for Linux）

最も正攻法と言える使い方は、WSLを使用する方法です。
WSLとは、Windowsが内部的に持っている Hyper-V の機構を使用して、LinuxカーネルをWindows上でエミュレーション実行して、Linuxの機能を丸ごと使用できる機能です。
プログラマーが行うLinux上での開発作業のほとんどを、このWSLで実行可能です。
WSL では Ubuntu、Debian、Kaliなど、いくつかのLInuxディストリビューションがアプリとして用意されており、Microsoft Store などから導入できるようになっています。

具体的な機能と使い方は、Microsoft 公式サイトで確認する事をお勧めします。

Windows Subsystem for Linux のドキュメント

仮に WSL の Ubuntu を導入して、bash を使用した場合、そのストレージ領域は 仮想ディスク領域(VHD)が割り当てられますが、WSL・UbuntuからWindowsのストレージ領域にアクセスすることも可能です。
具体的には、/mnt/c/ ディレクトリが、Windowsでの C:\\ フォルダを意味します。
bash上で cd /mnt/c と実行すれば、Windowsの C:\\ フォルダの内容を閲覧・操作できます。
この仕組みにより、WSL・Ubuntuから全ての Windowsのストレージ領域にアクセスできます。
この bash から iconv , file , dos2unix , unix2dos コマンドを使用して、 Windowsのテキストファイルの文字エンコーディングやBOMや改行コードの確認・変換を行うことができます。

MSYS2

Windows環境でUNIXライクなシェルを提供する環境です。
Bashやcoreutils（ls, grep, sed, awkなど）を提供します。
Arch Linuxのpacmanパッケージマネージャーを採用しており、ツールのインストール・管理が容易にできます。
MinGW-w64ツールチェーン（GCC, Clangなど）を簡単に導入可能です。
MSYS2は、OS自体をUNIX化するものではありません。提供しているのはあくまでUNIXの『ツール群』と『シェル環境』であり、一部のPOSIX APIをエミュレーションしてWindows APIの呼び出しに変換します。
MinGWでビルドしたバイナリはWindows APIを直接呼び出すネイティブアプリになります。よって、MSYS2上からWindows用に作られたコマンドを呼び出すことも可能ですが、UNIXシェル環境に最適化していなければ正常に動作しません。
dir や find などは動作します。VS Code が Windowsにインストールされていれば、code と打ち込むと VS Code が起動します。

以下のサイトから配布されています。

https://www.msys2.org/

詳しい使い方は、ここでは省略します。

Git Bash

Git Bashは単独の製品ではなく、Git for Windowsに含まれるコンポーネントです。配布元は以下の2つです。
Git公式サイト: https://git-scm.com/install/windows
Git for Windowsプロジェクト: https://gitforwindows.org/
どちらからダウンロードしても同じインストーラーが取得できます。

Git for Windowsは、Git本体に加えて、コマンドラインで使うためのBASHエミュレーション（Git Bash）と、GUIツール（Git GUI）を提供します。

Git for Windowsは軽量なネイティブツールセットとして、GitのフルセットをWindows上で提供するものです。
内部的にはMSYS2のランタイムを使って、Bash、ls、grep、sedなどのUNIXコマンドをWindows上で動かしています。
つまりGit Bashは「MSYS2ベースのBash環境 ＋ Git」というパッケージです。

もし、WSL を使用しないのなら、Windows上でUNIXシェルを使用するのに、最も相応しいのはこの Git Bash でしょう。

https://git-scm.com/download/win にアクセスすると、自動的にダウンロードが開始されます。x64版とARM64版があるので、お使いの環境に合ったものを選びます（通常はx64）。

Cygwin

CygwinはRed Hat（現IBM）が中心となって開発してきたプロジェクトで、cygwin1.dllというPOSIX互換レイヤーを提供します。
POSIX APIをWindows API上にエミュレーションするため、UNIX向けソースコードをほぼそのままコンパイル・実行できます。
POSIX互換環境を構築しているので、Bash, X Window System, SSH, Python, Perl, gccなど非常に多くのパッケージが利用可能です。

ただし、Cygwin上でビルドしたバイナリはcygwin1.dllに依存するため、ネイティブWindowsアプリとしては配布しにくいです。

MSYS2では、ビルドしたアプリはWindowsアプリですが、CygwinではCygwinに依存したアプリになります。

UNIXエミュレーションの抽象化水準を比較すると、WSLが最も高く、次が Cygwin で、MSYS2 はシェルインターフェイスだけUNIXライクで中身はWindowsという抽象化水準になります。
（WSL は完全に GNU Linux そのものです）

Cygwin の公式サイトは https://cygwin.com/ です。ここからセットアッププログラムをダウンロードします。
公式サイトから setup-x86_64.exe をダウンロードして実行します。64bit版のWindowsであればこちらを使います。

詳しい使い方は、ここでは省略します。

WindowsのUNIXシェル補足

UNIXシェル環境は、PowerShell や cmd とは使い方が異なります。
簡単には説明できませんが、例えば ファイルパスの区切り文字は、PowerShell や cmd だとバックスラッシュですが、UNIXシェルではスラッシュです。
PowerShell はオブジェクトパイプラインを実装していますが、UNIXシェルのパイプラインはバイトスルーです。
ファイル一覧の取得や、検索、テキストファイルの表示など基本的なコマンドも異なります。
ワイルドカードの展開手順も異なり、シェルスクリプトは高度に発達していて、その為の仕様も複雑です。
環境変数・動作設定の仕様もWindowsとは大きく異なります。
使ったことの無い人が、いきなり使えるものではありません。

UNIXシェル環境はプログラマにとっては馴染み深いものですが、主にExcelやWord、ブラウザ、企業業務システムを利用しているような一般ユーザーには、お勧めできるものではありません。

しかし、どうしてもUNIXシェル環境を使用するなら、WSLをお勧めします。
これは Windows の標準機能であり、完全な GNU Linux なので信頼性で最も勝ります。
次にお勧めするのは、Git Bash です。これならデフォルトで iconv , file , dos2unix , unix2dos がインストールされているので導入が簡単です。
Git Bash は MSYS2 を内蔵しているので、MSYS2 をお勧めする意味はありません。
また、WSL が実現した現在では Cygwin を導入する意味も無いと思います。Cygwinもお勧めしません。

主要コマンドツールの使い方（世界標準）

テキストファイルの文字エンコーディング・BOM・改行コードの確認と変換を行う、世界標準のコマンドは以下のコマンドです。

iconv , file , dos2unix , unix2dos

これら四つのコマンドは全て先に紹介した UNIXシェル環境でしか使用できません。
PowerShell と cmd では、使用できません。

Git Bash の場合は、インストールした時点でこれらのコマンドが装備されています。
WSLでUbuntuをインストールした場合は、apt install コマンドでそれぞれのコマンドをインストールできます。
MSYS2やCygwinについては、説明を省略します。

コマンドの詳しい使い方は省略し、文字エンコーディング・BOM・改行コードの確認と変換のやり方だけ、簡単に説明します。
（ちなみに iconv,dos2unix,unix2dos のオプションによるエンコーディング指定は大文字小文字を区別しません）

文字エンコーディングの変換

エンコーディングの確認

# file コマンド（標準・国内外共通）
file -i input.txt          # Linux: MIMEタイプ形式で表示
file -I input.txt          # macOS: 同上

file input.txt		# 他の情報も表示されるが、オプション無しでも確認できる。

Shift_JIS → UTF-8

# iconv（国内外共通・推奨）
iconv -f SHIFT_JIS -t UTF-8 input.txt > output.txt

# 上書きしたい場合
iconv -f SHIFT_JIS -t UTF-8 input.txt --output=input.txt
# 上書きしたい場合（-oでも良い）
iconv -f SHIFT_JIS -t UTF-8 input.txt -oinput.txt

UTF-8 → Shift_JIS

# iconv
iconv -f UTF-8 -t SHIFT_JIS input.txt > output.txt

複数ファイルの一括変換（bash/zsh）

iconv は、上書きするとき –output オプションで「上書き対象ファイル名」を記入しなければならないため、複数ファイルを一括処理する場合は、シェルスクリプトの for 文でループ処理を書く必要があります。

# iconv で *.txt を一括変換
for fn in *.txt
do
  iconv -f shift_jis -t utf-8 "${fn}" --output="${fn}"
done

iconv の注意点：変換できない文字があるとエラーで止まります。-c オプションで変換不能文字をスキップできます（iconv -f SHIFT_JIS -t UTF-8 -c input.txt）。

BOM の付加・除去

BOM の確認

# 先頭バイトを16進で確認
head -c 4 input.txt | xxd
# UTF-8 BOM: ef bb bf
# UTF-16LE BOM: ff fe

# file コマンド
file input.txt   # "with BOM" と表示されることがある（環境依存）

UTF-8 BOM の除去

世界標準のUNIXコマンドでは「BOMだけを付加・除去」する機能はありません。
BOMだけを操作するならば、以下の様にBOMのバイナリを先頭に付加したり除去する操作を行うことになります。

# sed（Linux/macOS 共通）
sed -i 's/^\xEF\xBB\xBF//' input.txt        # Linux
sed -i '' 's/^\xEF\xBB\xBF//' input.txt     # macOS（-i の後に '' が必要）

# tail（安全な方法）
tail -c +4 input.txt > output.txt    # 先頭3バイトをスキップ

# Python（環境依存が少ない）
python3 -c "
import sys
data = open('input.txt','rb').read()
open('output.txt','wb').write(data.lstrip(b'\xef\xbb\xbf'))
"

UTF-8 BOM の付加

# printf で BOM を先頭に付加
printf '\xEF\xBB\xBF' | cat - input.txt > output.txt

UTF-16LE への変換（BOM付き）

iconv の -t UTF-16LE 指定の場合は、BOM無しになりますが、
-t UTF-16 指定の場合は、BOM付きになります。

# iconv
iconv -f UTF-8 -t UTF-16LE input.txt > output_nobom.txt
# BOM付き UTF-16LE
printf '\xff\xfe' | cat - <(iconv -f UTF-8 -t UTF-16LE input.txt) > output.txt


# iconv で UTF-16（自動でBOM付き）
iconv -f UTF-8 -t UTF-16 input.txt > output.txt   # BOM自動付加

UTF-16LE → UTF-8（BOM除去を含む）

# iconv（BOMがあっても自動処理される場合が多い）
iconv -f UTF-16LE -t UTF-8 input.txt > output.txt

# BOMありUTF-16の場合
iconv -f UTF-16 -t UTF-8 input.txt > output.txt   # BOM見て自動判別

UTF-16 の場合は、UTF-16LE と UTF-16 のエンコーディング指定を使い分けることで、BOMの有無を操作できますが、UTF-8 ではできません。
環境による違いもあると聞きますが未確認です。（自分の Ubuntu では BOM付きUTF-8 は扱えません）

改行コードの変換

改行コードの確認

# file コマンド
file input.txt     # "CRLF line terminators" などと表示

# cat -A（Linux）/ cat -e（macOS）
cat -A input.txt   # CR が ^M として表示される

# xxd で確認
xxd input.txt | grep -E "0d 0a|0a"

改行コードは、file コマンドで確認するのが良いでしょう。

CRLF → LF（dos2unix）

# dos2unix（国内外問わず最も一般的）
dos2unix input.txt                  # 上書き
dos2unix input.txt output.txt       # 別ファイルに出力
dos2unix *.txt                      # 一括処理

# sed（dos2unix が使えない環境）
sed -i 's/\r//' input.txt           # Linux
sed -i '' 's/\r//' input.txt        # macOS

# tr
tr -d '\r' < input.txt > output.txt

dos2unix , unix2dos コマンドには、BOMを制御するオプションがあります。
改行コードとBOMを一括で変換するなら、BOMの制御が可能です。

# dosテキストからUNIXテキストへ変換
dos2unix  --remove-bom input.txt                  # 上書き
dos2unix  --remove-bom input.txt output.txt       # 別ファイルに出力
dos2unix  --remove-bom *.txt                      # 一括処理

LF → CRLF（unix2dos）

# unix2dos
unix2dos input.txt
unix2dos input.txt output.txt

# sed
sed -i 's/$/\r/' input.txt          # Linux
sed -i '' 's/$/\r/' input.txt       # macOS

# awk
awk '{print $0"\r"}' input.txt > output.txt

改行コードとBOMを一括で変換するなら、BOMの制御が可能です。

# UNIXテキストからdosテキストへ変換
unix2dos  --add-bom input.txt
unix2dos  --add-bom input.txt output.txt

nkf コマンドの使い方（日本のみ）

日本語環境では、世界標準コマンドよりも使い勝手の良い「nkf」というコマンドが提供されています。
nkf コマンドは日本語の文字エンコーディングに特化した、文字エンコーディング・BOM・改行コードの確認と変換が可能なコマンドです。
日本国内では nkf が標準ツールと言って良いでしょう。
ただ、日本語文字エンコーディング専用なので海外では存在すら知られていません。
nkf も UNIXシェル環境で提供されています。

基本的な使い方を以下に解説します。

文字エンコーディングの変換

エンコーディングの確認

nkf --guess input.txt

Shift_JIS → UTF-8

nkf -w input.txt > output.txt        # -w = UTF-8出力
nkf -w --overwrite input.txt         # 上書き（nkf限定の便利オプション）

UTF-8 → Shift_JIS

nkf -s input.txt > output.txt        # -s = Shift_JIS出力
nkf -s --overwrite input.txt

複数ファイルの一括変換（bash/zsh）

# nkf --overwrite で一括上書き
nkf -w --overwrite *.txt

BOM の付加・除去

BOM の確認

nkf --guess input.txt	# BOMがあれば (BOM) と表示する、無ければ表示しない

UTF-8 BOM の除去

nkf -w80 --overwrite input.txt

UTF-8 BOM の付加

nkf -w8 --overwrite input.txt

UTF-16LE への変換（BOM付き）

nkf -w16L --overwrite input.txt

UTF-16LE → UTF-8（BOM除去を含む）

nkf -w80 --overwrite input.txt

BOMを除去するときは、オプション末尾に 0 を付けます。
末尾に 0 が無い場合はBOMを付加します。

# BOMを除去する
-w80  
-w16L0
-w16B0
# BOMを付加する
-w8
-w16L
-w16B

改行コードの変換

改行コードの確認

nkf --guess input.txt	# Windows型改行コードならば (CRLF) と表示する。

CRLF → LF（dos2unixと同様）

nkf -Lu --overwrite input.txt       # -Lu = LF（Unix）改行

LF → CRLF（unix2dosと同様）

nkf -Lw --overwrite input.txt       # -Lw = CRLF（Windows）改行

nkf 関連オプションまとめ

nkf は、文字エンコーディングを自動推定する機能を持ち、対象テキストファイルの文字エンコーディングを特に指定しなくても、自動で識別してくれますが、その自動推定機能は完璧ではありません。
そもそも「完璧な自動推定」など、どこにも存在しないので、100%自動推定機能に依存してはいけないのです。
nkf には入力テキストファイルの文字エンコーディングを指定するオプションもあるので、対象文字エンコーディングが分かっているならば、オプションでそれを指定するべきでしょう。
文字エンコーディングのオプションは以下のようになります。入力と出力は別々です。

大文字オプションは、入力テキストファイルの文字エンコーディングを指定し、
小文字オプションは、出力テキストファイルの文字エンコーディングを指定します。
文字エンコーディングの自動推定に任せるならば、入力テキストファイルの文字エンコーディングを指定する必要はありません。

文字エンコーディング・オプションの末尾に 0 を付けると『BOMを除去』することを意味します。末尾に 0 が無い場合は、BOMを付加します。（または「末尾に 0 が無い場合は、出力文字エンコーディングの標準設定に従います」）

# BOMを除去する場合のオプション
-w80
-w16L0
-w16B0
-w32L0
-w32B0

改行コードの変換は -L オプションで行います。
オプションの二文字目(u w m)で改行コードの種類を指定します。

コマンド操作まとめ

推奨コマンド早見表

日本国内と海外の最大の違いは nkf の有無です。
国内では nkf が「エンコード変換・BOM操作・改行変換」を1ツールで担える万能ツールとして浸透していますが、海外では存在自体が知られていないことがほとんどで、iconv + dos2unix の組み合わせが事実上の標準です。
macOS では Homebrew で両方インストールできます（brew install nkf dos2unix）。

日本語UNIXシェル環境ならば、nkf 一択と言えるでしょう。

Windows版の nkf コマンド

nkf は UNIXで提供されているコマンドですが、nkf に限り Windows版が提供されています。
Windows版 nkf は Vector から配布されています。

nkf.exe nkf32.dll Windows用 ダウンロード

圧縮ファイルを解凍し、exe を環境変数 PATH の通ったフォルダーにコピーすれば使用可能になります。

Windows版の nkf コマンドは Git Bash を使用するときに利用します。
WSL の場合は、apt install nkf 等で Linux にインストールした Linux版 nkf を使用することになります。
この点は、間違えないように注意してください。

Windows版 nkf の問題点

Windows版 nkf は PowerShell や cmd でも使用することができます。
しかし、その仕様には少し問題があります。

nkf は UNIXシェル（bash , zsh など）に合わせて開発されています。
Windowsの PowerShell や cmd の仕様に合わせていません。
nkf の場合は、二つの問題点があります。

問題の一つはワイルドカード展開です。
UNIXシェルでは、コマンドパラメータのファイル名指定で使用されるワイルドカード（* :アスタリスク）は、まずシェル側で展開されコマンドに対しては検索されたファイル名のリストで引き渡されます。
例えばカレントディレクトリに以下のファイルがあるとします。

$ ls *
text1.txt  text2.txt  text3.txt

この状況で、以下の様にコマンド com にワイルドカードを指定するとします。（com は仮のコマンドです）

com *

すると、UNIXシェルは * を検索してファイル名のリストにしてから、コマンドに引き渡します。

com text1.txt text2.txt text3.txt

つまり、UNIX環境では、シェル側がワイルドカードに該当するファイル名を検索してくれるので、コマンド側ではワイルドカードを展開する必要が無いのです。
UNIX系のコマンドにはワイルドカードを展開する機能が備わっていません。

nkf コマンドも同様で、Windows 環境で nkf * とワイルドカードを指定しても該当ファイルを検索することができません。
UNIXシェルで nkf を使用するとワイルドカード展開をしてくれますが、PowerShell と cmd ではワイルドカード展開をしてくれません。
これはUNIXとWindowsのシェル仕様の違いによるものです。

つまり、Windows環境（PowerShell と cmd）では nkf はワイルドカードを使用することができないのです。

PowerShell 固有の問題

nkf を含めて UNIX系コマンドは、出力結果を標準出力に出力する仕様のコマンドが多いです。
nkf もUNIX標準的な使い方では、以下の様に標準出力に出力します。対象ファイルに上書きしたりはしません。

# Shift_JIS から UTF-8のBOM付き で標準出力に出力する
nkf -S -w8 input.txt

対象ファイルに上書きするときは、–overwrite オプションを指定します。

nkf -S -w8 --overwrite input.txt

標準的使い方では、上書きしないで標準出力に出力するのは、UNIX文化では一つのコマンドはできるだけ単純な機能だけを提供し、複雑な処理をするときはパイプラインを使用して、別のコマンドと組み合わせて使用するのがUNIXの作法になっているからです。

上書きするときは、上書き用のオプションを指定することが多いです。

UNIXのパイプラインの仕様はバイト配列をそのまま送る仕様です。

ここで二つ目の問題があります。
PowerShellではパイプラインの機構にオブジェクトパイプラインという独自の実装があります。
PowerShellのコマンドレットでは、標準出力への出力文字列は .NET の System.String 型のコレクションにして出力されます。

PowerShell 上で、Windows版の nkf を使用して標準出力の結果を、パイプラインで別のコマンドの標準入力に繋いでも、テキストを正常に受け取れない場合があります。
ここで注意が必要なのは、PowerShell 7.4 以降はこのパイプラインの仕様に改善があり、nkf も正常に稼働することがあります。
PowerShell 7.3 以前や Windows PowerShell では、nkf のパイプライン出力は文字化けや、意図しない文字エンコーディングでの出力という、不本意な結果になる場合があります。
PowerShell は進化を続けていますが、パイプラインの問題が抜本的に解決したわけではありません。
PowerShell で nkf を使用する変換処理を行うときは、–overwrite オプションを使用するようにした方が堅実です。

WindowsではUNIX標準コマンドは使い難い

長々と解説してきましたが、これまでの説明を見て分かるように、Windows環境では「文字エンコーディングやBOMの有無・改行コードの確認」と、「それぞれの変換」操作は、いちいちUNIXシェルを導入して操作しなければならないので、非常に面倒です。
文字エンコーディングとBOM変換の方は、PowerShell のコマンドレットで操作できますが、現状の確認ができません。
文字エンコーディングの自動識別機能も存在しません。

私が、mfsr-mfprobe コマンドを作成したのも、この操作の面倒臭い問題を解消したかったからです。

rmsmf-txprobe & mfsr-mfprobe 使い方の分かりやすい解説

今回は、Windows 上に UNIXシェルを導入することにより、文字エンコーディングとBOMと改行コードの確認と変換を行う方法の解説をしました。

次回は、PowerShell による文字エンコーディングとBOMの操作方法を解説したいと思っています。
但し、既に解説したように、PowerShell には 文字エンコーディングとBOM を確認する機能はありません。その点は先に説明しておきます。

PowerShell の解説は、いつ投稿するか分かりませんが、ゆるゆると原稿を書いていきたいと思います。

では、また。

これまで、以下の二つの記事で「Windows環境におけるテキストファイルの文字エンコーディングとBOMの扱い」について、検証確認してきました。

Windows 11 標準アプリ 文字エンコーディング対応状況まとめ

Windowsコンソールの文字エンコーディング対応状況を検証する

前の記事は、メモ帳など主要アプリの対応状況を、 後の記事は、コンソールの対応状況を検証した結果報告です。

今回、これに加えて Visual Studio と SSMS(SQL Server Management Studio) についても検証しました。

この記事では、過去の検証結果と、Visual Studio と SSMS(SQL Server Management Studio) の「テキストファイルの新規作成」を行ったときの文字エンコーディングとBOMの有無の状態を、まとめました。

主に、それぞれのアプリやツールのデフォルト設定で新規作成した場合のレポートです。

ここから、Microsoftの意図と、Windows環境のテキスト問題が明確になってきます。

まず、検証結果のまとめを、ご覧下さい。

検証結果一覧

各ツールの詳細

メモ帳

• デフォルト: UTF-8（BOM無し）
• 保存ダイアログから他のエンコーディングも選択可能。以前のバージョンではUTF-8 BOM付きやANSI（Shift_JIS）がデフォルトだったが、現在のWindows 11ではBOM無しUTF-8に変更されている。

コマンドプロンプト（cmd）

echo "日本語です" > text.txt

• デフォルト: Shift_JIS
• システムロケールのコードページ（日本語環境では CP932 = Shift_JIS）に従う。

Windows PowerShell 5.1

# リダイレクト演算子
"日本語です" > text.txt        # → UTF-16LE（BOM付き）

# Set-Content
"日本語です" | Set-Content text.txt   # → Shift_JIS

• リダイレクト演算子（>）と Set-Content でエンコーディングが異なる点に注意。
• Set-Content は -Encoding パラメータで明示的に指定できる。

PowerShell 7.x

# リダイレクト演算子
"日本語です" > text.txt        # → UTF-8（BOM無し）

# Set-Content
"日本語です" | Set-Content text.txt   # → UTF-8（BOM無し）

• PowerShell 7.x ではどちらの方法でもUTF-8（BOM無し）に統一された。
• PowerShell 5.1 から移行する際は、エンコーディングの挙動変化に注意が必要。

VS Code

• デフォルト: UTF-8（BOM無し）
• ステータスバーからエンコーディングを変更可能。設定で files.encoding を変更すればデフォルトも変えられる。

Excel CSV保存

• 通常保存: Shift_JIS
• 「UTF-8（カンマ区切り）」で保存: UTF-8（BOM付き）
• UTF-8（BOM無し）で保存する選択肢は用意されていない。

Visual Studio 2026

注意: VB.NET の Program.vb だけが、なぜか UTF-8（BOM無し）で生成される。テンプレートの不整合またはバグの可能性がある。

SSMS（SQL Server Management Studio）

傾向の整理

検証結果から、以下の傾向が読み取れます。

モダンなツール → UTF-8（BOM無し）

メモ帳、PowerShell 7.x、VS Code など、比較的新しいツールはUTF-8（BOM無し）をデフォルトとしています。Web標準やLinux環境との親和性を重視した流れです。

レガシー系 → Shift_JIS / UTF-16LE

コマンドプロンプトや Windows PowerShell 5.1 は、従来のWindowsの文字コード体系を引き継いでいます。既存のバッチファイルやスクリプトとの互換性が理由と考えられます。

ソースコード（C#, VB.NET, C++）→ UTF-8 BOM付き

Visual Studio はコンパイラがソースファイルのエンコーディングを確実に認識できるよう、BOMを付与しています。

Web系ファイル（json, js, ts）→ UTF-8（BOM無し）

Web の世界ではBOM無しが標準のため、Visual Studio・SSMS ともにWeb系ファイルはBOM無しで生成されます。

XML → UTF-8 BOM付き

Visual Studio、SSMS のいずれにおいても XML は BOM付きです。XML宣言の encoding 属性との整合性を意識した実装と考えられます。

検証結果まとめ

Windows 11 環境でも、ツールやファイル形式によってデフォルトのエンコーディングはバラバラです。特に以下のポイントは押さえておきたいところです。

1. Windows PowerShell 5.1 のリダイレクト（>）は UTF-16LE（BOM付き） — 他のツールで開くと文字化けの原因になりやすい
2. PowerShell 5.1 では > と Set-Content でエンコーディングが異なる — 同じPowerShellでも出力方法で結果が変わる
3. Excel CSV は UTF-8（BOM無し）で保存できない — 他システム連携時に注意
4. Visual Studio のソースコードは BOM付き、Web系ファイルは BOM無し — 混在するプロジェクトでは意識が必要

チームでの開発では .editorconfig や各ツールの設定でエンコーディングを統一しておくと、トラブルを未然に防げます。

所感

以前書いた Windows 固有の文字エンコーディング問題 という記事の中で、私は「MicrosoftがUNIX標準に合わせるのは、時間の問題」と言いました。

今回、Windows環境の主要ソフトウェア全ての文字エンコーディングとBOMの有無を確認して、得られた認識は、「Microsoftは既にBOM無しUTF-8のテキストに軸足を移し始めている」ということです。

改行コードは、全てのツールとアプリにおいて CR-LF を堅持しています。

しかし、メモ帳・VS Code・PowerShell7.x・SSMS においては、既にBOM無しUTF-8が主流となっています。

それに対し、レガシーデータの多い Excel が 今でも Shift_JIS をメインとし、補助的に BOM付きUTF-8 を採用しているのは、理解できるとして、Visual Studio 2026 が今でも C#・C++ においても BOM付きUTF-8 を採用しているのは、やや意外でした。

開発環境は、全てBOM無しUTF-8になるのかと思いましたが、Visual Studio はExcel同様にレガシーデータが多いので、簡単にBOM無しUTF-8を採用できないのが、理解できます。

AI でも文字化けを解消できない

　Visual Studio 2026 に統合された GitHub Copilot Agent を使用して、AI Agent にコーディングをやらせてみると、「BOM無しUTF-8のソースファイルを作成しようとして、AIがMAUIコンパイラを呼び出すと、コンパイラが Shift_JIS と誤解してしまい、MAUI画面が文字化けする」という現象が頻繁に起きます。 例えば PowerShell 7.x のコマンドレットで新規ファイルを作成すると、「BOM無しUTF-8」のテキストファイルを作成しますが、Visual Studio 環境では「BOM無しはShift_JIS」「BOM付きはUTF-8」と解釈するので、PowerShellコマンドレットで「BOM無しUTF-8」を作成すると、Shift_JISと解釈されてその後の編集で文字化けするのです。PowerShell 7.x と Visual Studio の間で、UTF-8ファイルの解釈が統一されていないことで起きる不具合です。 なお、PowerShell 7.x のリダイレクト演算子（>）や単純な Out-File , Set-Content ではBOM付きUTF-8を作成できません。-Encoding 指定で Set-Content -Encoding utf8BOM ならば作成可能です。

この現象が起きると AIエージェントは、自力では文字化けを解消できません。何度も失敗して最後は人間に助けを求めます。(私の観測範囲ではMAUIコンパイラがBOM無しUTF-8に対応していません、他にもこのような問題があると思われます)

AIエージェント は素晴らしいコーディング能力を発揮しますが、独力では文字化け一つ解決できないのです。

世間ではあまり意識されませんが AIエージェント の内部では、コンパイラなど AI (LLM)ではない従来型のソフトウェアが呼び出されて使用されています。

AIエージェント は、LLMと従来型アルゴリズムの組み合わせでできているので、Windows 環境のように文字エンコーディング問題が、従来型アルゴリズムの段階で解決していないと、 AIエージェント でも問題を解決できません。

文字エンコーディング問題などは、現状では人間が手動で解決しなければならない問題の一つです。 AIエージェント が文字化けで停止することを回避するには、あらかじめ人間が文字化け問題を解決しておかなければならないのです。(ルンバも、部屋を片付けておかなければ掃除ができないのと同じです)

Visual Studio 2026 に統合された GitHub Copilot Agent が文字化けに悩み人間に助けを求める状況は、 AIエージェント の構造をよく表している現象だと思います。

文字化け問題は深刻化している

私は、2020年に rmsmf を作ったとき、「文字エンコーディング問題など、3年もすれば解消するだろう」と思っていました。だから rmsmf のアップデートは一時停滞していました。

しかし、現在のWindows環境を検証してみると、昔より文字エンコーディングとBOMのトラブルは多くなっているように見えます。

昔の文字エンコーディング問題は、「Shift_JIS か UTF-8 か UTF-16LE」の問題が主で、解決策も「ファイル先頭にBOMを付ける」ことで済んでいました。

しかし、MicrosoftがWSLを導入して以降、新たな問題が生じています。

それは「BOM無しUTF-8」の問題です。当初MicrosoftはUTF-8を「BOM付き」で導入することで、Shift_JISとの混在による混乱を回避していました。

しかし、WSLによりLinux環境とテキストファイルを共有するようになってから、「BOM無しUTF-8」のテキストをWindows環境に受け入れなければならなくなりました。

結果として、それまでテキストファイルの先頭のBOMだけ確認していれば、複数文字エンコーディングの共存ができていたのに、「BOM無しUTF-8」の存在により「BOMによる文字エンコーディングの判別」ができなくなってしまいました。

しかも、テキストファイルの文字エンコーディングを判定する手段は、Windowsユーザーには提供されていません。

メモ帳 や VS Code は一応、「BOM無しUTF-8」を自動判定してくれます。しかし、一般ユーザーはそれが「BOM付きUTF-8」なのか「BOM無しUTF-8」なのかを区別できません。

Visual Studio の検証結果を見れば分かるように、Windows環境の C# や C++ や VB.NET・XML などのソースファイルは、今でも「BOM付きUTF-8」が基本になっています。

Excel CSV や VBA なども Shift_JIS をデフォルトとしながら「BOM付きUTF-8」が基本になっています。

一方、メモ帳 と VS Code と PowerShell 7.x は、「BOM無しUTF-8」が基本になっており、PowerShell 7.x では単純なリダイレクトなどでは「BOM付きUTF-8」が作成できません。-Encoding utf8BOM 指定が必要です。

Windows PowerShell 5.1 もOSの深部との結びつきが強く、まだ現役で標準装備されています。 Windows PowerShell 5.1 は、「BOM付きUTF-16LE」テキストが標準の上に、コマンドレットによって「Shift_JIS」テキストと混在しており、日本語文字エンコーディングが統一されていません。

つまり、Windows環境では、テキストファイルの「Shift_JIS」「BOM付きUTF-8」「BOM無しUTF-8」「BOM付きUTF-16LE」が混在していながら、それぞれを区別する手段が提供されていないのです。

「どうして、いまさら文字エンコーディング対応など、調べているのか」と言えば、WSL導入以降のWindows環境において、BOMを中心とした文字エンコーディングの混乱が拡大しているからです。

改行コードの問題も無視できない

Microsoftは GitHubを買収し、積極的に Windows環境に GitHub のアプリケーションを受け入れています。

その最たるものが、GitHub Copilot Agent だと思います。

GitHub は Git をベースにした Linux と OSS 文化圏のサービスです。そのシステムは全て UNIX 標準で統一されています。

Linux OS と UNIXのmacOS のテキスト改行コードは LF で統一されていますが、Windows のテキスト改行コードは、CR-LF で統一されており、GitHub へソースを Commit-Push するとき変換する必要があります。

今のWindowsテキストの改行コードは CR-LF のまま変更される様子は無いですが、これまでの文字エンコーディング対応の変化を見る限り、改行コードが CR-LF から LF へ変更される可能性を否定できません。

現状で CR-LF の CR に存在価値があるとは思えないからです。

残りの牙城の寿命は少ない

UNIX標準テキストが、「BOM無しUTF-8」ならば、古いテキスト「Shift_JIS」「BOM付きUTF-8」「BOM付きUTF-16LE」を支えるアプリケーションとレガシーデータの牙城は、Excel, Visual Studio, Windows PowerShell 5.1 ということになります。

Visual Studio は、過去に Shift_JIS を標準としていた時代があり、現在の「BOM付きUTF-8」標準を廃して「BOM無しUTF-8」を標準とするのも時間の問題でしょう。

PowerShell は 7.x で既に「BOM無しUTF-8」を標準としており、Windowsのシステムも Windows PowerShell 5.1への依存部分を徐々に PowerShell 7.x へ移行していて、旧 5.1 が廃止されることは約束された未来です。

レガシーデータの牙城として唯一終わりが見えないのは、Excel CSV と VBA です。

Microsoft は Word においては、テキストインポートのときに、ユーザーに文字エンコーディングを選択させる形で、複数文字エンコーディングに対応しています。

しかし、何故か Excel では依然として文字エンコーディングの判別を、テキスト先頭の BOM に依存しています。 また、デフォルトでの CSVファイルへの保存も Shift_JIS のままです。

Excel 以外の全てのアプリとツールは、明らかに「BOM無しUTF-8」への移行に向かっているのですが、Excel だけはその兆候が見えません。

BOMが消えるのはいつなのか

Windows環境において、そのテキストファイルの規格が「BOM無しUTF-8」へ完全に切り替わるまで、まだまだ時間がかかると思われます。

Visual Studio が、そのソースファイルを全て「BOM無しUTF-8」へ完全に切り替えるのは、あと二・三世代ぐらい後のバージョンになると思っています。少なくとも現在の 2026 ではオプション設定などで「BOM無しUTF-8」を標準とする機能がやっと追加された段階です。

Windows PowerShell 5.1 が完全に廃止され、PowerShell 7 以降に統合されるのは、10年は先の話になると思います。(関係ないけどコントロールパネルはいつ無くなるのでしょうね？)

Excel CSV と VBA については、先が全く見えません。Excel による CSV出力や、CSV の Excel による閲覧は、本当に一般ユーザーの中でよく使用される機能です。 Excel VBA も利用している人々が多すぎて、消滅することが想像し難い状況です。(モダンExcelはどこへ行った？)

Excel 自身が Shift_JIS の CSV を今でも量産して、文字エンコーディング問題を拡大しています。

将来の Windows環境が「BOM無しUTF-8」へ切り替わることは、ほぼ確実なのですが、今後10年以上は Windows環境の文字エンコーディングとBOMの問題に、付き合わなければならないと思われます。

また、先に説明した改行コードの問題も未解決であることもお忘れなく。

まだまだ終わらない文字エンコーディング問題の後始末

これまで報告してきたように、Windows環境では2000年代に一度、Shift_JISからUTF-16LEへ移行し、その後さらにBOM付きUTF-8へ移行したことがあります。

その後、2010年代後期に一部の機能が「BOM付きUTF-8」から「BOM無しUTF-8」へ移行しています。この移行はこれまで報告してきたように、まだ「移行途中」であり、古いShift_JIS・BOM付きUTF-8とUTF-16LEが一部のアプリで併存している状況です。

結果として、Windows環境には Shift_JIS・BOM付きUTF-16LE・BOM付きUTF-8・BOM無しUTF-8 のテキストが混在する状況になっています。

BOM付きUTF-8・BOM無しUTF-8 が混在しているので、BOMによる識別もできません。

Shift_JISとBOM付きUTFだけが混在していた昔より、文字エンコーディングの識別が困難になっています。

しかも、文字エンコーディングの識別はユーザーの自己責任です。

このような文字エンコーディング周りの状況が悪化しているのを受けて、最近私は mfprobe-mfsr というツールを開発してリリースしました。

これは、2020年に開発して公開していた rmsmf という .NET Framework 4.8用の ツールを改良し .NET10 Native AOT で再構築して提供したものです。 元々は、文字列置換ツールだったのですが、Windows環境特有の文字エンコーディング問題を無視しては置換処理すらできないことから、文字エンコーディング判別変換機能とBOM確認追加削除機能と改行コードの変換機能を有しています。

Windows環境で、手軽に複数ファイルを対象に文字エンコーディングやBOMの有無や改行コードの種類を確認・変換できるツールが見当たらなかったので、自分で開発したツールです。

もし良ければ、文字エンコーディング問題への対処にご利用ください。

以下のページで公開しています。

rmsmf-txprobe & mfsr-mfprobe 使い方の分かりやすい解説

MITライセンスで公開しています。オープンソースのフリーソフトです。

検証環境

• OS: Windows 11 Pro 25H2
• PowerShell: Windows PowerShell 5.1 / PowerShell 7.5.4
• Visual Studio: Visual Studio 2026
• VS Code: 1.109.4
• SSMS: SQL Server Management Studio 22.3
• Excel: Microsoft Office 2024

最終更新: 2026年2月

Windowsには複数のコンソール環境が存在し、それぞれ文字エンコーディングの扱いが異なります。特に日本語環境では、Shift_JIS（cp932）、UTF-8、UTF-16 など複数のエンコーディングが混在するため、ファイルの読み書き時に文字化けが発生するケースが少なくありません。

本記事では、以下の3つのコンソール環境について、各種文字エンコーディングのファイルを正しく読み書きできるかを検証しました。

• コマンドプロンプト（cmd.exe）
• Windows PowerShell 5.1
• PowerShell 7.5.4

検証は「デフォルト設定でのファイル読み込み・リダイレクト」と「エンコーディングを明示的に指定した場合の出力」の2つの観点で行っています。

検証環境

テストデータ

ASCII文字・カタカナ・漢字を含む複数行の日本語テキストファイル（text1.txt）を使用しました。

TESTストリングaaa日本語国債発行
TESTストリングbbb日本語
...（以下、同様の形式で計18行）

このテストファイルを13種類の文字エンコーディングで用意し、それぞれの読み込み・出力結果を確認しています。

検証1：デフォルト設定でのファイル読み込みとリダイレクト

各コンソールのデフォルト設定で、異なるエンコーディングのテキストファイルをリダイレクトし、出力ファイルが正しく読めるかを検証しました。

検証コマンド

cmd.exe：

type text1.txt > workc.txt

Windows PowerShell 5.1 / PowerShell 7.5.4：

Get-Content -Path "text1.txt" > work.txt
Get-Content -Path "text1.txt" | Set-Content set.txt
Get-Content -Path "text1.txt" | Out-File out.txt

PowerShell では >（Out-File 相当）と Set-Content で出力エンコーディングの挙動が異なるため、両方を検証しています。

結果サマリー

リダイレクトや出力結果の表示は以下の様です。

• ✅ 可能: 日本語テキストが正常に表示される
• ❌ 不可: 文字化け、表示エラー

cmd.exe（chcp 932）

cmd.exe の type コマンドとリダイレクトは、ファイルの中身をバイト列としてそのまま読み出し、そのまま書き出します。エンコーディングの解釈や変換を行わないため、ほぼすべてのエンコーディングで正常にコピーされます。

唯一 UTF-32LE（BOM付き）だけが文字化けしました。UTF-32LE の BOM は FF FE 00 00 の4バイトですが、先頭の FF FE は UTF-16LE の BOM と同一です。type コマンドが BOM を検出した際に UTF-16LE と誤認し、以降のバイト列の解釈が崩れたものと考えられます。

Windows PowerShell 5.1

Windows PowerShell 5.1 では明確なパターンが確認できます。BOM付きファイルはすべて正常に読み込めるが、BOMなしファイルは Shift_JIS 以外すべて文字化けします。 これは PowerShell 5.1 が BOM でエンコーディングを判定し、BOM がない場合はシステムデフォルトの Shift_JIS（cp932）として扱う仕様に起因します。

ISO-2022-JP は Set-Content 経由のみ正常でした。Set-Content は > や Out-File と異なり、バイト列をより素直に書き出す傾向があるためです。

なお、出力エンコーディングについても注目すべき挙動があります。> および Out-File は入力のエンコーディングに関わらず常に UTF-16LE（BOM付き） で出力します。一方、Set-Content は Shift_JIS で出力します。これは PowerShell 5.1 の仕様であり、出力エンコーディングを変更するには -Encoding パラメータの明示的な指定が必要です。

PowerShell 7.5.4

PowerShell 7.5.4 では、デフォルトエンコーディングが UTF-8（BOMなし） に変更されました。そのため、5.1 とは逆に Shift_JIS が文字化けし、UTF-8（BOMなし）が正常に処理されます。

BOM付きファイルの扱いは 5.1 と同様で、BOM によるエンコーディング判定が健在です。BOMなしのファイルはデフォルトの UTF-8 として解釈されるため、UTF-8 以外のBOMなしエンコーディングは文字化けします。

また、5.1 では > / Out-File と Set-Content で出力エンコーディングが異なりましたが、7.5.4 ではすべてのコマンドで統一的に UTF-8（BOMなし） で出力されます。

ISO-2022-JP が正常に処理されるのは、Get-Content がバイト列をそのまま通過させた結果と考えられます。

検証2：エンコーディングを明示的に指定した場合の出力

各コンソールでエンコーディングを指定し、日本語テキストをファイルに出力した結果です。

cmd.exe

検証コマンドの例:

chcp 65001
echo "日本語です" > echo_utf-8.txt

cmd.exe では chcp コマンドでコードページを切り替えます。

cmd.exe はシングルバイトおよびダブルバイト系のエンコーディング（Shift_JIS、UTF-8、ISO-2022-JP、EUC-JP）に対応しています。UTF-16 や UTF-32 のようなマルチバイト固定長エンコーディングはコードページとして無効であり、コンソールでは使用できません。

Windows PowerShell 5.1

検証コマンドの例:

[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
[Console]::InputEncoding  = [System.Text.Encoding]::UTF8
$OutputEncoding = [System.Text.Encoding]::UTF8

"日本語です" > test_utf-8.txt
"日本語です" | Set-Content test_utf-8_set.txt

PowerShell では [Console]::OutputEncoding、[Console]::InputEncoding、$OutputEncoding の3つの変数でエンコーディングを設定します。出力は >（Out-File 相当）と Set-Content の2種類で検証しました。

注目すべき点として、エンコーディングを設定しても > の出力は常に UTF-16LE（BOM付き） 、Set-Content の出力は常に Shift_JIS になります。コンソールのエンコーディング設定はファイル出力のエンコーディングには影響しません。ファイルの出力エンコーディングを変更するには、Out-File -Encoding や Set-Content -Encoding のようにコマンドレットの -Encoding パラメータを使用する必要があります。

PowerShell 7.5.4

検証コマンドは Windows PowerShell 5.1 と同様です。

PowerShell 7.5.4 でも 5.1 と同様に UTF-16BE、UTF-32、EUC-JP はコンソールエンコーディングとして使用できません。

5.1 との大きな違いとして、> も Set-Content もすべて UTF-8（BOMなし） で出力されます。5.1 と同様、コンソールのエンコーディング設定はファイル出力のエンコーディングには反映されません。

また、ISO-2022-JP を使用する場合は [System.Text.Encoding]::RegisterProvider([System.Text.CodePagesEncodingProvider]::Instance) による登録が事前に必要です。これは PowerShell 7 が .NET（Core）ベースであり、レガシーエンコーディングがデフォルトでは利用できないためです。

まとめ

デフォルト設定での読み込み

3つのコンソール環境のデフォルト設定における読み込み挙動を整理すると、以下のようになります。

cmd.exe はエンコーディング変換を行わないバイトスルー方式のため、ほぼすべてのファイルをそのまま通過させます。PowerShell は読み込み時にエンコーディングを解釈するため、BOMなしファイルでデフォルトと異なるエンコーディングは文字化けします。

デフォルト設定での出力エンコーディング

実務上の指針

cmd.exe はエンコーディング変換を行わないため、ファイルのコピーやリダイレクトでは最も安全です。ただし UTF-32LE（BOM付き）は BOM の誤認により文字化けするので注意が必要です。

Windows PowerShell 5.1 を使用する場合、BOMなしの UTF-8 ファイルを扱うには -Encoding UTF8 を明示する必要があります。また、> の出力が UTF-16LE（BOM付き）になることを認識しておくべきです。

PowerShell 7.5.4 はデフォルトが UTF-8 に統一されており、現代の開発環境では最も扱いやすい選択です。ただし、レガシーな Shift_JIS ファイルを扱う場合は -Encoding パラメータでの明示的な指定が必要になります。

BOMなしのファイルを確実に扱うには、どのコンソール環境でも -Encoding パラメータなどでエンコーディングを明示的に指定することが推奨されます。

Windows 11 上で利用できる主要なアプリケーションが、どの文字エンコーディングに対応しているのかを実際に検証しました。

テキストファイルや CSV を扱う際に「文字化け」に遭遇した経験は、多くの方にあると思います。特に日本語環境では、Shift_JIS と UTF-8 の混在が長年の課題となっています。しかし、実際にどのアプリがどのエンコーディングに対応しているのかを体系的にまとめた情報は意外と少ないのが現状です。

本記事では、メモ帳・VS Code・Excel・Edge・Chrome・エクスプローラー プレビューを対象に、各種エンコーディングのファイルを実際に開いて閲覧・保存できるかを検証した結果をまとめます。

補足: cmd・Windows PowerShell・PowerShell・Visual Studio については、別の記事で検証結果をまとめる予定です。

検証環境

検証方法

各エンコーディングでテキストファイルを作成し、対象アプリで開いた際の挙動を確認しました。

• 閲覧: ファイルを開いて日本語テキストが正常に表示されるかを確認
• 保存: アプリからファイルを保存する際に選択できるエンコーディングを確認

判定基準は以下の通りです。

• ✅ 可能: 日本語テキストが正常に表示される
• ❌ 不可: 文字化け、表示エラー、またはファイルを開けない

検証結果

閲覧対応

保存対応

Edge・Chrome・エクスプローラー プレビューはビューア専用のため、保存機能の検証対象外としています。

保存時の補足事項

メモ帳: 保存ダイアログからエンコーディングを選択できます。デフォルトは UTF-8（BOM無し）です。

VS Code: 保存時にエンコーディングを指定する標準UIはありません。デフォルトの UTF-8（BOM無し）で保存されます。

Excel CSV: 「名前を付けて保存」でファイル形式に「CSV UTF-8」を選択した場合のみ UTF-8（BOM付き）で保存されます。それ以外のファイル形式（CSV、txt、prn、htm）では、すべて Shift_JIS で保存されます。

考察

BOMの有無がもたらす影響

検証結果から最も顕著に読み取れるのは、BOM（Byte Order Mark）の有無がファイルの閲覧可否に大きく影響するという点です。

UTF-16 では、BOM付きであればほとんどのアプリで正常に表示できますが、BOM無しの場合はメモ帳以外のすべてのアプリで文字化けが発生しました。メモ帳が BOM無しの UTF-16 を読める唯一のアプリである点は注目に値します。

UTF-8 については、BOM無しでも大半のアプリが対応しています。唯一の例外が Excel CSV で、UTF-8（BOM無し）のファイルは文字化けします。これは長年知られている問題であり、Excel で UTF-8 の CSV を扱う場合は BOM付きが事実上の必須条件です。

UTF-32 は BOM の有無に関わらず、ほぼすべてのアプリで非対応でした。Excel CSV とエクスプローラー プレビューが UTF-32LE（BOM付き）のみ表示できるという結果は意外でしたが、実用上 UTF-32 を使う場面はほとんどないでしょう。

アプリごとの対応傾向

メモ帳 は閲覧においてはもっとも幅広いエンコーディングに対応しています。UTF-16 の BOM無しを唯一読めるアプリであり、保存時も5種類のエンコーディングを選択できます。ただし、UTF-32 やレガシーな日本語エンコーディング（ISO-2022-JP、EUC-JP）には対応していません。

VS Code はテキストエディタとしては標準的な対応範囲ですが、いくつか注意点があります。ISO-2022-JP を UTF-8 と誤認識して文字化けする、UTF-32LE（BOM付き）を UTF-16LE と誤認識するなど、自動検出の誤りが見られました。一方で EUC-JP には対応しており、レガシーファイルの取り扱いでは部分的に役立ちます。

Excel CSV は BOM への依存度がもっとも高いアプリです。Shift_JIS と BOM付きエンコーディング以外はほぼ文字化けします。保存時のデフォルトが Shift_JIS である点も、UTF-8 が主流となった現在では注意が必要です。

Edge / Chrome は閲覧対応がまったく同じ結果でした。ISO-2022-JP と EUC-JP に対応している唯一のアプリ群であり、レガシーな日本語 HTML ファイルの表示には依然としてブラウザが最適です。

エクスプローラー プレビュー は UTF-16BE（BOM付き）が表示できない（「表示できない」旨のメッセージが出る）一方で、UTF-32LE（BOM付き）は表示できるという独特な挙動を示しました。

Excel VBA のエンコーディング制約

Excel VBA でファイルの読み書きを行う際のエンコーディング対応は、他のアプリと比べて大きな制約があります。

VBA の String 型は内部的に UTF-16LE で文字列を保持しています。このため、ファイル I/O でもUTF-16LE が基本となります。

Open 文 / FileSystemObject では、Shift_JIS、UTF-16LE（BOM付き）、UTF-16LE（BOM無し）の 3 種類のみ対応しています。UTF-8 を指定する選択肢自体が存在しません。

ADODB.Stream を使えば UTF-8 の読み書きが可能になりますが、標準で安定して動作するのは BOM付きの UTF-8 と UTF-16LE のみです。BOM無し UTF-8 を扱うには、BOM の読み飛ばし処理を VBA コード側で実装する必要があり、標準機能だけでは対応できません。

UTF-8 の CSV ファイルを VBA で処理したいという需要は多いにもかかわらず、VBA 単体での UTF-8 対応は限定的です。ADODB.Stream を使った BOM付き UTF-8 の読み書きが、現時点でのもっとも現実的な選択肢となります。

レガシーエンコーディングの対応状況

ISO-2022-JP と EUC-JP に対応しているのは、ブラウザ（Edge / Chrome）と VS Code（EUC-JP のみ）だけでした。

かつて日本語 Web サイトやメールで広く使われたこれらのエンコーディングは、テキストエディタ系のアプリではもはや自動認識の対象外となりつつあります。古い日本語ファイルを扱う必要がある場合は、ブラウザで開くか、nkf などの変換ツールで事前に UTF-8 へ変換しておくのが安全です。

実務での推奨

検証結果を踏まえた、用途別のエンコーディング推奨は以下の通りです。

テキストファイル全般: UTF-8（BOM無し）がもっとも広く対応されており、第一選択として推奨します。

Excel で扱う CSV: UTF-8（BOM付き）を使用してください。BOM無しでは Excel で文字化けします。

VBA でのファイル入出力: ADODB.Stream を使用し、UTF-8（BOM付き）で読み書きするのが現実的です。Open 文や FileSystemObject では UTF-8 を扱えません。

HTML ファイル: UTF-8 で作成し、<meta charset="UTF-8"> を記述してください。ブラウザはレガシーエンコーディングにも対応していますが、新規作成するファイルで使う理由はありません。

他のアプリとの互換性を最大化したい場合: UTF-8（BOM付き）がもっとも安全です。すべてのアプリで閲覧可能であり、Excel CSV の文字化けも回避できます。ただし、プログラムやスクリプトから読み込む際に BOM が問題になるケースがある点には注意してください。

「文字化け」はなぜ終わらない？ 日本のITを縛る文字エンコーディングの深い闇

今回は、Windowsユーザーの視点で、この日本語文字エンコーディングの新旧混在問題について、解説したいと思います。

現代、Web界隈では完全に UTF-8 がテキストデータを支配しており、若い人を始め、十数年前から IT機器を使い始めたユーザーには、「なぜ、文字エンコーディングが問題になるのか」が理解できない人が増えていると感じます。
そもそも「なぜ、BOM付きUTF-8などという物が存在するのか」が分からない若者も多いのではないでしょうか。

「BOM付きUTF-8」は完全にWindows固有の問題であり、そして同時に無くては困るものでもあります。
また、これに関連してWindowsワールドでは古い文字エンコーディングに付随する形で、テキストの扱いが難しくなっている問題があります。
Linux や Mac OS には存在しない Windows 固有のテキスト問題を、ここに纏めておきたいと思います。

PC三大勢力

昔からPC規格には、今と同じ三大勢力が存在していました。
UNIX勢力、Apple勢力、Microsoft勢力です。
今は、それぞれ Linux OS、Mac OS、Windows に収まっていますが、少し昔は UNIX規格には様々なOSが存在し、Apple PC の OSは現在の Mac OS とは規格の異なるOSを採用していました。
Windowsが登場する前は、MS-DOS が Microsoftの主力OSでした。
それぞれの勢力の日本語対応もバラバラで、日本語圏においては、今より互い勢力圏の間でのテキスト交換が困難な状況でした。

昔の三大勢力のテキスト規格

1990年代から2005年頃までのPC三大勢力のテキスト規格

Unicode 規格が普及し始めたのは、2000年代中盤頃からなので、この時代に UTF-8 も UTF-16 もPCでは使用されていません。
1990年前後から2005年までで15年です。その前後5年ぐらいを加えて25年ぐらいの期間は、この古いテキスト規格で、企業や官公庁でテキストデータが作成されてきたということです。
そのデータ蓄積の大きさを想像してみてください。

2000年代のテキスト規格の革新

2000年代は、三大勢力全般にOS全般の革新が起こり、同時にテキスト規格も様変わりしました。

OS 規格の革新

UNIX勢力の中に Linux OS が台頭し始め、Web Server を中心に急激に普及しました。
これにより、他のUNIX系OSは存在感を急速に失い、UNIX系の規格を採用したOSとしては、Linux OS がデファクトスタンダードのような存在になっていきました。
（ちなみに Linux は正式な UNIX ではありませんが、ほぼ UNIX と考えて差し支え無い規格の OSカーネルです）

Apple は、当初からモトローラーのCPUを採用していましたが、その性能がインテルCPUに対して劣っていたため、Apple社は Mac のCPUをインテルCPUに変更し、それに伴って Mac の OS を、それまでの System 7 系統から UNIX規格の Mac OS に変更しました。
これに伴い、Mac の テキスト規格も UNIX規格に変更されました。

Microsoft は UNIX勢力や Apple より、PC市場では後発だったため、当初 MS-DOS を投入するとき、既に作られていた UNIXやApple旧OS のテキストデータを読み込める規格にする必要がありました。
米国では、テキストコードは ASCII で統一されているので、ここは問題ありませんが、改行コードは UNIX は LF、Apple旧OS は CR とバラバラだったので、どちらの改行にも対応できるように CR・LF を改行コードに定めました。
Microsoft は最初からインテルCPUを採用していたので、現在に至るまで OS 自体の規格変更は行っていません。WindowsはMS-DOSのテキスト規格を継承しています。

Unicode の台頭

2000年代は、米国以外の各国において文字エンコーディングが古いものから Unicode 規格の文字エンコーディングへ切り替わった時代でした。
当初、Unicode の文字エンコーディングは、UTF-16 が主流でしたが、その後 UTF-8 が登場して現代では、UTF-8 が世界標準の文字エンコーディングとなりました。
ちょうど、三大勢力のOS が、古いものから新しいものへと、切り替わるタイミングと一致した影響も大きいと思われます。

今の三大勢力のテキスト規格

Windows は、旧 Windows PowerShell など、一時 UTF-16LE を採用していた時期がありますが、最新の PowerShell7 などでは UTF-8 を採用しています。
また、OS や ファイルシステムや DBMS の内部では、UTF-16 が今でも活用されています。
.NET や JavaVM の内部も UTF-16 を使用しています。

現代では、ユーザーの目に触れる部分では、テキスト規格は UTF-8 にほぼ統一されています。

今では Windows 規格だけが孤立している

元々、Windows規格 は UNIX のテキストも Mac のテキストも読めるように作られた規格ですが、後の世でMacとLinuxの革新が、UTF-8とUNIXテキスト規格に統合された事により、Windowsだけが孤立したテキスト規格を採用している状態になってしまいました。

これは、Microsoft社が悪いわけではなく、「運が悪かった」としか言いようがありません。

Windows － 早く普及した弊害

プログラマーでもハッカー（コンピュータのヘビーユーザー）でもない、一般ユーザーに早く普及したOSは Windows です。
Windows 95 以降は、急激に「普通の人」がPCを利用するようになりました。
一方、この時代は、UNIXはまだ高価なワークステーションでしか利用できない状態で、Linuxはカーネルの初期バージョンが登場したばかりで、本格的ディストリビューションの普及はまだまだ先の話でした。
Apple の Mac は Windows との競争に苦戦していた時期で、時々 iMac などヒット商品を出していましたが、Windows 95 以降の Microsoft の躍進に比べると、地味な存在で「一部のマニアの使うPC」という位置づけでした。
企業や公的機関で本格的に採用されていたのは、Microsoft Windows でした。

そのような背景があるため、社会で次々作成されるテキストデータは、大半が Windows 規格のテキストでした。文字エンコーディングが Shift_JIS で、改行コード CR・LF のデータが量産されていったのです。

Linuxが本格的に普及し始めたのは、2000年代で、既に Unicode の時代に変わっていました。
Apple Mac は 2000年代に、障害となっていた モトローラーCPU の性能問題を克服するためにインテルCPUへ切り替え、同時に UNIX OS に更新したため、同時に Unicode 規格に変更しました。
もともと企業や官公庁に大きく普及していたわけではないので、経路依存性の障害は小さく、過去のテキスト規格を事実上放棄して、UNIX 規格に全面切り替えました。

Microsoft Windows は企業や官公庁に広く普及しており、ユーザーのデータ資産を守る責任を無視できない立場にありました。
時代のテキスト規格が、Unicode に切り替わる局面において、最も経路依存性の障害が大きかったのは、Microsoft Windows と言えると思います。
Windows の普及が他のOSに比べて早かったことによる弊害と言えるでしょう。

過去データを捨てられない

Windows においては、古いテキスト規格のデータだけでなく、古いテキスト規格を使用する古いソフトウェアが大量に存在します。
これらのソフトウェアの Unicode 規格への更新は、日本社会においてはまだ完了していません。
古いソフトウェアは、今でも古いテキスト規格のデータを量産しています。

過去の古いデータの蓄積量も膨大で、全てのデータの Unicode への変換は不可能なケースも少なくないです。

また、Windows には短期間ではありますが、UTF-16LE を Unicode 標準として採用した時期があり、そのとき作られた UTF-16LE テキストも古いテキストデータとして残っています。
今でも Windows PowerShell の標準文字エンコーディングは UTF-16LE です。

Windows 環境では、しばらくの間は古いテキスト規格と、新しいテキスト規格を共存させる必要があります。
その新旧テキストの共存を実現するために必要になったのが「BOM付きUTF-8」です。

Windows の古いテキスト文字エンコーディングは、Shift_JIS です。
Shift_JIS のテキストと、UTF-8、 UTF-16LE のテキストを、各アプリケーションが識別できなければなりません。
しかし、Shift_JIS と UTF-8 と UTF-16LE を、予備情報無しで識別するのは難しく、完全な信頼性で識別するのは不可能と考えて良いです。
文字エンコーディングを識別するソフトウェアは、バイナリパターンから文字エンコーディングを高確率で「推測」しているだけで、100%確実な文字エンコーディング・バイナリパターン推測の方法は存在しないのです。

BOM問題

Microsoft も完全な識別を保証できない文字エンコーディング・バイナリパターン推測に依存するわけにはいきませんから、確実に Shift_JIS と UTF-8 と UTF-16LE を識別できる手段を採用しています。
その手段が BOM です。

BOM とは、Byte Order Mark の略で、テキストファイルの先頭に Unicode のエンコーディング種類を示すマークを付けて、そのテキストがどのUnicode文字エンコーディングかを識別する仕組みです。

Unicode には、５つの文字エンコーディングが存在し、Unicode 標準化委員会がそれぞれを区別するために定めた、Unicode の標準規格です。Microsoft の独自規格ではありません。
BOMは、文字として扱われない短いバイナリパターンです。
５つの文字エンコーディングとそれぞれのBOMのバイナリパターン（16進数の数値）は、以下の表のように対応しています。

Windows のテキストファイルでは、UTF-8 と UTF-16LE のテキストファイル先頭に、このBOMが付加されています。
Excelで、Unicode の CSV を保存すると、CSVファイルの先頭に ｛EF，BB，BF｝ のBOMが書き込まれます。
Excelでは「通常のCSVファイル保存」を行った場合は、今でも Shift_JIS で保存されます。当然 BOM は付きません。（Shift_JIS の BOM という規格は存在しません）

この仕様は、ユーザーにとって文字化けなど様々なトラブルの原因になっています。

ExcelのCSV保存は、典型的なWindows経路依存性問題の中心的存在です。

LE(Little Endian)・BE(Big Endian)とは

ちなみに、LE とか BE というのは、CPUがメモリから数値を読み込むときに、１バイトづつ読み込むわけですが、現代は64ビット（8バイト）CPUの時代なのでCPUの扱う整数値も64ビット（8バイト）になります。
バイト単位で数値を読み込むとき、8バイトの数値をメモリから読み込むことになりますが、このとき8バイトのCPUレジスタ（CPU内の記憶領域）へ、メモリの先頭からバイト単位でコピーすることになります。このコピーを8バイトのレジスタの「先頭から後ろのバイトへの順番」に書き込むのか、「後ろから前のバイトへの順番」に書き込むのか、CPUの仕様によって異なります。
前者をBE(Big Endian)、後者をLE(Little Endian)と呼びます。
文字エンコーディングのLEやBEとは、CPUのLEに合わせた文字エンコーディングです。
インテルやARMはLE、昔のモトローラーCPUやJavaVMはBEで作られています。
インターネットもBEを標準としています。
このLE(Little Endian),BE(Big Endian)については、深く理解する必要はありません。「文字エンコーディングの種類が違う」とだけ理解してください。

WSL採用の弊害

2010年代には、ソフトウェア開発者の多くが Linux ベースで開発を行うようになりました。
Docker、Node.js、Python、Rubyなど、モダンな開発ツールはLinux環境で最も快適に動作する上に、開発者がLinuxネイティブなコマンドラインツール（bash, grep, awkなど）を使えないと、Windowsから離れて、Linuxへ移ってしまうため、MicrosoftはWindows上でLinux開発環境を使える WSL (Windows Subsystem for Linux) を、2017年頃から導入しました。
WSLを使用すると、Windows上のファイルをLinuxで直接閲覧編集することができるようになります。

しかし、逆にWindows 上で Linux が使用できるようになったことにより、Windows上のPowerShellやエディタなどでも Linux の「BOM無しUTF-8」テキストファイルを扱う必要性が出てきました。
また、GitHUBを買収したことにより、オープンソース系のLinuxテキストファイルの読み書きも、できなければならなくなりました。こちらも「BOM無しUTF-8」テキストファイルを扱わなければならない要因です。

Microsoft社がLinuxを初めとしたOSS界を肯定したことにより、「BOM無しUTF-8テキスト」と「LFのみの改行コード」を無視できなくなったのです。

「メモ帳」が「BOMなしUTF-8」に対応

2019年5月のWindowsアップデートから、標準の「メモ帳」が「BOMなしUTF-8」のテキストファイルに対応しました。世界標準に合わせる為です。

これにより、LinuxやMac由来のUTF-8テキストファイルの文字化けは、格段に減少したそうですが、逆に古いShift_JISテキストは文字化けが、Windows環境で頻発するようになったようです。

当たり前です。

現在のWindows環境は、テキストファイルに関しては、BOMの有無だけでは、Shift_JISなのかUTF-8なのか明確にならない中途半端な状況になっており、レガシーなシステムを扱っている企業や自治体・官公庁、そして金融機関に医療機関などでは、メモ帳がアテにならない状態になっています。
メモ帳で、Shift_JISもUTF-8もUTF-8-BOMも全て開けますが、Excelは「BOM無しUTF-8」のCSVを開くと文字化けします。

むしろ、昔の秀丸やサクラエディタの方が日本語文字エンコーディング・改行コード・BOMの判別機能を持っているので、安全かも知れません。

現状のWindowsは、「Shift_JISとUTF-8テキストファイルの違いとBOMの有無・改行コード種類」の区別を、以前よりもユーザーが自己責任で識別しなければならない面倒な時代になっています。

Mac OS と Linux系OS には存在しない問題

既に解説していますが、Mac OS と Linux系OS には、この Shift_JIS と UTF-8 が混在する問題も、改行コードCR・LFとLFの混在問題も、「UTF-8のBOMの有無」問題も存在しません。
Mac OS と Linux系OS では、文字エンコーディングはUTF-8のBOM無し、改行コードはLFのみ、で統一されています。
過去の歴史的経緯から運悪く、Windows環境だけで面倒くさい状況になっているのです。

標準的な対策ツール

テキストファイルの文字エンコーディングと改行コードやBOMの有無を、調べたり変更したりするツールは、昔からいくつか存在します。
昔は、Windowsのシェアが圧倒的だったので、文字エンコーディングと改行コードやBOMの有無の問題に晒されるのは、UNIXやMacの側である事が多かったようです。
そのため、この問題の対策ツールも、主要なものはUNIX環境で開発されています。

代表的なツールは、file , iconv , nkf というコマンドツールです。
file と iconv は、UNIX系シェルでしか使用できません。PowerShell や cmd では使えません。
Windows環境で使用するならば、WSLでWindowsの領域を参照して、bashでfileとiconvを使用するか、Git Bash をインストールして、Bash上で fileとiconvを使用するのが、簡単確実な方法です。
ただし、iconv は日本語の推測精度があまり高くないようです。
fileは文字エンコーディングに対処するツールではなく、改行コードの確認と変換に使用できるツールです。

PowerShell でも文字エンコーディングの変換はできますが、文字エンコーディングの確認手段がありません。
また、多くの場合、PowerShell ではいちいちスクリプトを組まなければ、文字エンコーディングと改行コードやBOMの有無に対処することができないケースが多く、手軽さに欠けるのが現実です。

nkfコマンドは例外的に、PowerShell や cmd で使用できますが、nkfもUNIX標準で開発されているコマンドツールで、ワイルドカード展開はシェル任せで、Windows上では使用できません。
また、PowerShellのオブジェクトパイプラインに対応していませんから、nkfの特徴であるリダイレクトによる文字エンコーディングの変換機能などが使えません。
nkfの開発者は初めからUNIXに合わせて開発しているので、PowerShellに合わせる動機は無いでしょう。

つまり、残念ながらWindowsユーザーは、問題の震源地であるWindows環境では、問題を解決する多くのツールが使用できないという、非常に不幸な状況に陥っています。

Windows環境で、対象ファイルが一つ二つ程度ならば、昔から存在している秀丸エディタやサクラエディタが文字エンコーディング確認機能と、改行コード・BOMの確認機能を持っており、それぞれの変換も可能なので、便利だと思います。
UNIX環境ならnkfがワイルドカードで一括処理ができるので便利ですが、Windows環境のPowerShellとcmdでは、ワイルドカードが使えません。一つずつファイルを処理するなら、昔のエディタの方が良いでしょう。
Windowsならば、個人が開発しているシェアウェアに良いツールが沢山あると思います。

先日、私がリリースしたOSSツール（MITライセンス）も、この問題を解決するツールです。
PowerShellとcmdで動作します。
逆に、UNIX環境には合わせていません。
PowerShellとcmdの標準に合わせて開発しています。
複数ファイルを一括で処理できます。
文字エンコーディング確認機能と、改行コード・BOMの確認機能、それぞれの編集機能を持ちます。

rmsmf-txprobe & mfsr-mfprobe 使い方の分かりやすい解説

既存ツール類に満足できなければ、試してみてください。

将来予測

MicrosoftはWSL導入以降、テキストファイルの扱い方で迷走しているように見えます。

「メモ帳など一部だけBOM無しUTF-8に対応している」この状況は、主にLinux系開発環境を使用している開発者には、好ましいかも知れませんが、レガシーデータやレガシーシステムを扱っているエンジニアには、面倒な上に「どっちつかず」の中途半端で対処に困る状況ではないでしょうか。
現在の状況は、「テキスト文字エンコーディングの判別はユーザーの自己責任」という、かなり無責任な状況と言えます。

元々、Microsoftは、当初OSSに対して懐疑的な姿勢を示していましたが、2017年頃から戦略を大きく転換し、OSSへの対応を強化してきました。

メモ帳が「BOM無しUTF-8」に対応したこと、その理由は「世界標準に合わせるため」という、この状況から将来のMicrosoftの方針を予測すると、誰が予測しても「WindowsはUNIX標準テキストに合わせる」という将来が見えてきます。

UNIX標準テキストとは既に説明したように、「文字エンコーディングは UTF-8 、改行コードは LF のみ、UTF-8テキストの先頭にBOMは付けない」という仕様です。

もし、Windows標準テキストがUNIX標準に従うことになれば、現在のWindows標準である「BOM無しテキストはShift_JIS、BOM付きテキストはUnicodeエンコーディング、改行コードはCR・LF」というテキスト仕様は、丸ごと「古いレガシー」となってしまいます。

注意して欲しい点として、UNIX標準に合わせたところで、「古いレガシー」が消えてなくなるわけではないことです。
Windows環境では、今でもShift_JISのテキストが現役であり、大量のレガシーデータとして健在であるように、これまで20年近く作成されてきた「BOM付きUTF-8テキストとCRLF改行」は、丸ごと新たな「古いレガシー」として、全てのWindows環境に横たわります。
ITエンジニアは、「Shift_JISテキスト」「BOM付きUTF-16LEテキスト」に加えて「BOM付きUTF-8テキスト」と「CR・LFの改行」のお守りをしなければならなくなります。

現在でも、Excel が Shift_JISのCSV を吐き出し続けるように、UNIX標準をMicrosoftが採用したとしても、古いアプリや互換性を重視する多数のアプリや業務システムが、「BOM付きUTF-8テキスト」と「CR・LFの改行」を10年以上は吐き出し続けることになるでしょう。

Windowsユーザーの大多数は文字エンコーディングやBOMの問題など理解しようともしません。
Shift_JISからUTF-8-BOMへ、そしてUTF-8-BOM-CRLFからUTF-8-LFへ、と二段構えでのテキスト規格変更が行われれば、Windowsしか使わないユーザーの間でも、テキスト規格に関連するトラブルが続出することは避けられないと思われます。

現在のMicrosoftは、テキスト規格の方針を明確にしていません。
今の「BOM無しUTF-8テキストLF改行」の受け入れ方は、非常に中途半端な姿勢に見えます。
今は中途半端ですが、将来は十中八九でUNIX標準テキストが採用されると思います。
それがいつになるのかは、分かりませんが、十年もかからないでしょう。

CR改行の古いMacは、もう存在しません。
ITの合理性から考えて、現代のUTF-8テキストの「BOMとCR」は邪魔な代物なので、MicrosoftがUNIX標準に合わせるのは、時間の問題でしょう。

一応、将来のその事態に備えておいた方が良いかも知れません。

普通のPCユーザーでもExcelでCSVファイルを扱う時「文字化け」を経験したことがあると思います。
この「文字化け」は、Excelが古い文字コードと新しい文字コードを両方扱えるよう作られているが故に起きる不幸と言えます。
Mac や Linux が古い文字コード（レガシーデータ）を切り捨ててきたのに対し、互換性とユーザー資産の維持を重視するMicrosoft社は、古い文字コードを使える環境を温存したまま、新しい文字コードを導入しました。
そのため、Windowsユーザーは古い文字コードと、新しい文字コードを、間違えないように注意して使い分ける必要があるのです。

古い文字コードの問題は、Windows環境だけの問題ではありません。
政府や自治体には、膨大な量の「古い文字コードのデータ」が存在します。
日本中の病院など医療機関にも古くから存在する電子カルテなど「古い文字コードのデータ」が存在します。
これらは、データ量が膨大である上に、個人を特定する高い精度が求められるため、現実的な時間の中で「古い文字コードのデータ」を「新しい文字コード」へ変換できません。

また、組み込み機器に搭載される軽量級プロセッサやメモリの中では、メモリ効率の高い「古い文字コード」を使う方が、今でも合理的である側面があり、組み込みソフトウェアの世界では依然として「古い文字コード」が主流です。

これら「古い文字コード」は日本国内でしか使用できないため、グローバル化の障害になることにより、行政のデジタル化と民間のデジタル・トランスフォーメーション（DX）の足かせとなってしまいます。

日本語文字エンコーディングの簡単な解説

文字エンコーディングとは

「文字コード」という言葉を使用しましたが、情報技術の世界では「文字エンコーディング」という呼び方が正しい表現です。
本来、コンピュータは計算機であり、数値を扱う事を本分とする機械です。
文字を扱うには「文字を番号に置き換えて扱う」必要があります。
「文字を番号に置き換える」には、「文字の並び順」をまず定めて、その「並び順」を具体的にコンピュータが扱う「数値」に割り当てる必要があります。
「文字の並び順」を定めたものを「コードポイント」日本語では「(符号化) 文字集合」と呼び、その「コードポイント」を、具体的な「数値」に割り当てたものを、「文字エンコーディング」と呼び、日本語では「(文字) 符号化方式」と呼びます。

このコードポイントと文字エンコーディングの違いは、先の「新しい文字コード」にしか存在しません。
「古い文字コード」では、文字の並び順がそのまま具体的な文字番号に割り当てられています。
しかし、現代では「古い文字コード」も「文字エンコーディングの一種」として扱われます。

歴史的経緯

ASCIIコードとは

ASCII（American Standard Code for Information Interchange）は、1963年にアメリカで策定された文字コードです。7ビットで128文字を表現し、英数字、記号、制御文字を定義しています。

ASCIIの構成

0〜31番と127番は制御文字です。改行（LF: 10）、キャリッジリターン（CR: 13）、タブ（HT: 9）など、画面に表示されない制御用の文字が割り当てられています。

32番はスペース、33〜126番が印字可能文字です。48〜57に数字の0〜9、65〜90に大文字A〜Z、97〜122に小文字a〜zが配置されています。この配置には意味があり、大文字と小文字は32の差で対応しているため、ビット演算で大文字小文字変換ができます。

ASCIIの限界と拡張

7ビット128文字という設計は、英語圏では十分でしたが、それ以外の言語には全く足りませんでした。そこで8ビット目を使った拡張が各地で行われます。128〜255番の領域に、ヨーロッパではアクセント付き文字を、日本では半角カナを割り当てました。

日本語文字エンコーディングの開発

日本の文字エンコーディングの歴史は、コンピュータで日本語を扱うための試行錯誤の連続でした。

JISコードの登場（1978年）

最初の標準化は JIS C 6226（後のJIS X 0208）です。漢字約6,000字とひらがな・カタカナを定義しましたが、これは文字の「集合」を決めただけで、実際にバイト列としてどう表現するかは別問題でした。

三つ巴の時代（1980〜90年代）

ここから日本特有の混乱が始まります。

Shift_JIS は、マイクロソフトとアスキーが開発し、MS-DOSやWindowsで標準となりました。1バイトのASCII/半角カナと2バイトの漢字を混在できる設計が特徴です。

EUC-JP は、UNIX系システムで採用されました。Shift_JISとは互換性がなく、同じ「あ」でも全く違うバイト列になります。

ISO-2022-JP（通称JISコード）は、電子メールの標準として使われました。エスケープシーケンスで文字集合を切り替える方式です。

この時代、「文字化け」は日常茶飯事でした。Windowsで作ったファイルをUNIXで開くと化ける、メールの添付ファイルが読めない、といった問題が頻発しました。

Unicodeによる統一（2000年代〜）

UTF-8の普及により状況は大きく改善されました。Webでは2008年頃にUTF-8がShift_JISを逆転し、現在ではほぼ100%がUTF-8です。

ただし、日本のレガシーシステムには今もShift_JISが残っています。官公庁のシステムや古い業務アプリケーションでは、依然としてShift_JISが現役で、CSVファイルをExcelで開くためにあえてShift_JISで出力する、といった対応も珍しくありません。

米国と日本の文字エンコーディングの関係

ASCIIと日本語エンコーディングの関係

日本語の文字コードはすべてASCIIとの互換性を意識して設計されています。これは、既存の英語ベースのシステムやプロトコルとの共存が必須だったからです。

Shift_JISの設計思想

Shift_JISは、ASCIIの0〜127番をそのまま保持しています。2バイト文字の1バイト目には129〜159、224〜239という「ASCIIと重ならない」範囲を使いました。

ただし落とし穴があります。2バイト目には64〜126という範囲も使うため、バックスラッシュ（\、92番）やチルダ（~、126番）と衝突します。例えば、「表」「能」「ソ」などの漢字の2バイト目が、偶然にもバックスラッシュと同じ値（92）になってしまうケースがあり、これがファイルパスなどで予期せぬエラーを引き起こしました。

これらの文字がファイルパスやエスケープ処理で問題を起こしました。いわゆる「ダメ文字」問題です。

EUC-JPの設計思想

EUC-JPはより慎重な設計で、日本語文字はすべて128以上のバイトのみで構成されます。そのためASCII領域との衝突は起きませんが、半角カナの扱いが複雑になりました。

UTF-8の巧妙さ

UTF-8はASCII互換性を最優先に設計されています。ASCIIの128文字はそのまま1バイトで表現され、既存のASCIIテキストは一切変更なしにUTF-8として有効です。

マルチバイト文字の先頭バイトは必ず192以上、継続バイトは128〜191という規則があり、どのバイトを見ても「ASCII」「先頭」「継続」が判別できます。これによりShift_JISのような「ダメ文字」問題は原理的に発生しません。

新旧文字エンコーディングとは

先の解説にある「古い文字コード」とは、主に Shift_JIS を意味します。
広義には、EUC-JP と JISコード も「古い文字コード」に含まれますが、現在ではほとんど消滅しています。
Shift_JIS だけが現在でも使用される「古い文字コード」に該当します。
「新しい文字コード」とは、Unicode (ユニコード) の事を示し、PC上では主に UTF-8 が使用されています。
また、ソフトウェアの内部では、UTF-16 が多く活用されています。
Windowsの内部ではUTF-16LEが使用され、Javaの内部やPDFではUTF-16BEが使用されます。

この場合、Unicode (ユニコード) が コードポイント(文字集合) を示し、
UTF-8 と UTF-16LE と UTF-16BE が 文字エンコーディング (符号化方式) を示します。

もう一つの類似問題：改行コードの違い

文字エンコーディングの問題とは次元の異なる問題ですが、
日本のITエンジニアが悩まされる類似問題に「Windows と LinuxOS & MacOS での改行コードの違い」があります。
これは文字エンコーディングとは異なり日本だけの問題では無く、世界的な問題であり、技術的には文字エンコーディング問題とは別次元で対策すべき課題です。

しかし、日本の実務の現場では文字エンコーディング問題と改行コード問題はセットで覚えるべき問題となります。

現在の文字エンコーディング利用状況

ネットワークトラフィックの90%が、UTF-8と言われています。
LinuxOS と Apple社製品、そして Android など Google製品は完全に UTF-8 で統一されています。
しかし、先に説明したように Microsoftの Windows は過去のユーザーのShift_JISデータ資産が膨大なため、今でもShift_JISを扱える機構を多数残しています。
特に Excel などMicrosoft Office データには、今からではUTF-8にコンバージョンすることが不可能なほど膨大なShift_JISのデータ資産があり、Shift_JISを扱える機構を削除することは、不可能に近い状況と思われます。

PC環境だけではなく、銀行や政府や自治体の扱う古いデータ資産も気が遠くなるほど膨大なShift_JISデータを抱えています。
病院など医療機関も同様で、さらに電子カルテなどの情報は、個々人を取り違えると患者の命に関わるため、個人情報の正確さが強く求められる分野です。
ここで Shift_JIS から UTF-8 への文字エンコーディング変換で、一部でも「文字化け」する事が許されない分野です。

これらは、現実的には Shift_JIS から UTF-8 への文字エンコーディング変換を現実的な時間の内には、実現できないと考えるのが妥当です。

家電などの組み込みソフトウェアの分野でも、全ての文字が2バイト以内で済むメモリ効率の良さから、 Shift_JIS が積極的に選択されています。

Shift-JISの障害と優位性と必然性

Shift_JIS の障害と限界

Shift_JIS は先頭から全て評価しなければ、正しく日本語文字を判別できない欠点があります。
データ通信などで、文字列が分断されて送信されたとき、Shift_JIS ではバラバラのパケットを全て受け取って結合した上で、先頭からバイト列を読み取らなければ、文字コードを読み取れません。

UTF-8 や UTF-16 は、その部分が良く考えて設計されており、分断された文字列も、文字列の途中から正しく文字コードを読み取れるように作られています。

Shift_JIS は扱える文字の種類にも制限が多く、全体で 11,391文字しか扱えません。
Unicode の UTF-8 や UTF-16 は、最大 1,112,064 文字が扱えます。世界中の文字を扱える設計なので、文字空間が広大になっています。バイト数が多いのもそのせいです。

Shift_JIS の優位性

Shift_JIS と EUC-JP は、英数字はASCIIコードと同じで1バイト、日本語でも全て2バイトで表せます。
この「古い文字コード」は非常にメモリ効率が良く、必ず1バイトか2バイト単位で検索できるので、検索効率も良いです。

UTF-8 では英数字は1バイト、日本語は多く場合 3バイト、サロゲートペアを含むと4バイトの文字も現れます。メモリ制約の大きい組み込みソフトウェアの世界では、UTF-8 のメモリ効率の悪さは無視できません。

UTF-16 においては、大半の文字は2バイトで表せますが、サロゲートペアを含むと4バイトの文字も現れます。
UTF-16 は必ず2バイトか4バイトのどちらかなので検索がやり易く、OSやデータベースやファイルシステムの内部実装には UTF-16 が採用されることが多いです。
しかし、やはり UTF-8 と同様に最大4バイトになる場合があり、全て2バイトに収まる Shift_JIS にはメモリ効率で劣ります。

UTF-8時代にも引きずるShift-JISの経路依存性

経路依存性（Path Dependence）とは、過去の歴史的経緯や初期の選択が、現在の状況や将来の選択肢に強い影響を与え続け、時に非効率な状態でもその慣習や仕組みから抜け出せなくなる現象です。
日本語の文字エンコーディングが、Shift-JIS が広く使われるようになってから、UTF-8 へ移り変わったことにより、さまざまな経路依存性の障害が残っています。

BOM付きUTF-8問題

Excel の CSVファイルの扱いが代表的ですが、Windows環境においてはユーザーが Shift_JIS データを大量にデータ資産として保有していることから、Microsoft社は過去のユーザー資産を守る観点から、Shift_JISデータとUTF-8データを共存できる環境を構築しています。
Shift_JISとUTF-8を共存する為には、両者を明確に区別できなければなりません。
Windowsでは、テキストファイルを扱う場合、UTF-8テキストの先頭には、BOM(Byte Order Mark)という3バイトの識別コードを付ける事を義務づけています。
先頭にBOMが無ければ、そのテキストファイルは Shift_JIS のテキストファイルと解釈されます。
もし、Excel で 先頭にBOMの付いていない UTF-8 の CSVファイルを読み込むと、Shift_JIS のCSVファイルと解釈され文字化けします。
公式の UTF-8 の仕様では、BOM は付けても付けなくても良く、LinuxOSやMacOS、スマホなどでは、BOMの無いUTF-8テキストが使用されています。
しかし、WindowsではUTF-8テキストファイルの先頭には必ずBOMを付ける必要があります。これは、WindowsとLinuxOSやMacOSとの間でテキストファイルを交換するとき、文字化けやデータ読み込み時のエラーなど、さまざまなシステム障害を起こす要因になっています。
Shift_JISとUTF-8を共存させるから、BOMが必要になるので、Shift_JISの経路依存性の問題なのです。

Shift-JISの膨大なレガシーデータ

Shift_JISは、Windows環境だけではなく、メインフレームや古い業務システムでも広範囲に使用されてきました。
そして、銀行や製造業や医療機関や政府・自治体が数十年に渡って扱っているShift_JISデータは、膨大な量になります。
それらのShift_JISデータを今から急にUTF-8に変換しようとしても、現実的な時間とコストの枠内では不可能なデータ量になります。
また、正確にShift_JISデータをUTF-8に変換するには、いくつか障害があり、正確な変換は難しいのが現状です。
この膨大なShift_JISデータを運用していくには、今のところ、古いデータはShift_JISのまま管理し、新しいデータだけUTF-8で扱う、二重構造のシステムにするしか術はないと考えられます。
古いデータは使う時だけUTF-8に変換して閲覧し、文字化けしたら変換前のデータを閲覧できるようにするのが堅実です。

Shift-JIS「外字」問題

Shift_JIS を UTF-8 へ変換することの最も大きな障害になっているのが、「外字」の存在です。

Shift_JIS が扱える文字数は、11,391文字だけです。
日本語の漢字は異体字も含めると 6万字以上あると言われ、戸籍謄本などさまざまな漢字が使用される行政の日本語環境では、Shift_JIS の扱える文字数では全く足りません。

「外字」とは、標準の文字集合に含まれていない文字を、ユーザーやベンダーが独自に追加したものです。Shift_JISでは、この外字のために特定のコード領域が予約されています。
Shift_JISでは、F040〜F9FC の領域がユーザー定義文字用として確保されています。ここには約1,880文字分の空きがあり、企業や自治体が独自の記号、旧字体、人名漢字などを登録して使っています。
典型的な用途は、戸籍システムにおける異体字、企業ロゴや社内記号、地方自治体の地名に使われる特殊な漢字などです。

外字は作成した環境でしか正しく表示できません。外字を含むデータを他のシステムに持っていくと、文字化けするか「〓」や空白になります。また、検索やソートも正しく機能しません。

日本政府が進める「自治体システム標準化」において、最大の障壁の一つとなっているのが、各自治体が独自に運用してきた「外字（Gaiji）」の処理です。日本の戸籍制度においては、氏名や地名にJIS規格（JIS X 0208/0213）に含まれない特殊な漢字が使用されることが許容されてきました。これに対応するため、各自治体ベンダーは、システムの空き領域（外字領域）に独自のビットマップフォントやコードを割り当てて運用してきました。この結果、A市のシステムで作られたデータがB市のシステムでは全く読めない、あるいは別の文字として表示されるという、深刻な相互運用性の欠如が生じています。

デジタル庁およびIPA（独立行政法人情報処理推進機構）は、各自治体ごとにバラバラの外字を「MJ文字情報基盤」として統一する作業を進めています。
しかし、統一できない文字が15文字にも及び、それらを「実際に戸籍で使用されている文字」などで絞り込みを行った結果、連携に必要な文字数は約6万文字、そのうち戸籍運用上必須な文字は約1万文字にまで圧縮されたそうです。
この絞り込みを経て、MJ文字を拡張した文字セット「MJ+」が策定されました。戸籍副本データ管理システムでは、この「MJ+」を用いることで情報連携を行う方針だそうです。
しかし、約6万文字もの巨大な文字セットを、現場の端末ですべて入力・表示・検索できるようにすることは容易ではないことです。

少し、整理すると、Shift_JIS のデータをUTF-8へ変換するには、まず「外字」をUTF-8で扱う規格を定めなければならず、UTF-8で扱えない「外字」に日本全国の自治体で統一された例外処理を開発して導入しなければなりません。
その上、Shift_JIS のデータは政府や自治体だけでも膨大で、その正確なUTF-8への変換には、人間による目視確認がどうしても必要になります。
今ならAIによる画像確認も可能かもしれませんが、単純なコンバージョン処理では済まない事は分かります。
医療機関のShift_JISデータも社会保険制度の関係から、自治体データと同根の問題があり、こちらも膨大な患者情報を有します。

Shift-JISの組み込みシステムでの優位性

AIの登場で、以前ほど話題に上らなくなった IoT ですが、AIとは次元の違う技術なので、依然として開発と進歩は進んでいます。
IoTと深く関わるのが、組み込みソフトウェアの分野です。
先に少し解説しましたが、組み込みソフトウェアでは、メモリ効率の良さから積極的に Shift_JIS を選択することが多いそうです。
日本語一文字あたり Shift_JIS は 2バイト、UTF-8 は多くの場合 3バイトを消費します。これは単純計算でUTF-8がShift_JISの1.5倍の記憶領域を消費することになります。
メモリ環境が乏しい組み込みソフトウェアの世界では、少しでもメモリ消費の少ない Shift_JIS を使うことも当然の選択と言えます。
また、ほぼ2バイト固定長に近い Shift_JIS の文字列は検索処理が単純になり、演算処理は軽量になるのに対し、UTF-8 はバイト数が可変長(一文字、1バイトから4バイトまで4種類の可変長)なので、演算処理が重くなり検索処理には向いていません。
Windowsでも内部処理は、UTF-16LE を使用しています。
組み込みの世界で将来、Unicodeを使用することになっても、エンコーディングは UTF-16 を使用するでしょう。

フォントレンダリングの問題もあります。
現在のPCやスマホ環境では、アウトラインフォントが主流であり、外字や異体字を扱うために必要な技術です。UTF-8 の採用はアウトラインフォントの利用を前提にすることになります。
しかし、組み込みソフトでは外字や異体字を扱う必然性はない。炊飯器や石油ストーブやPOS端末の液晶パネルに複雑な旧字や異体字を表示する必然性はありません。
つまり、アウトラインフォントを使う必然性がないのです。
むしろ演算処理が重くメモリ効率も最悪のアウトラインフォントなどは、無駄なコンピュータリソースの浪費でしかありません。
組み込みでは Shift_JIS の文字集合(並び順)に対応したビットマップフォントが主流であり、このリソース効率の良いビットマップフォントが使えるのも Shift_JIS の魅力の一つと言えます。

整理すると、組み込みや IoT の世界では、Shift_JIS は非常に優れたソリューションと言え、UTF-8 は将来 IoT 機器などがクラウドなどに直接アクセスするようにならない限り、現状では必然性のあるものではないと言えます。
また、全ての組み込み機器がネットワークやクラウドにアクセスするのか、と問われると、個人的には「繋がらない権利」も必要になる気がします。

将来を見ても IoT機器は、製品によっては、どんどん小さくなる方向へ発展する可能性のある製品群なので、メモリや演算リソースが乏しい条件は変わらない気がします。

Shift-JISは完全には放棄できない

Excel で扱うCSVファイルなど、Windows 環境における膨大な過去の Shift_JISデータの蓄積。
政府・自治体・医療機関の抱える膨大な過去の Shift_JISデータ。
組み込みソフトウェアや IoT機器の開発における Shift_JIS のコンピュータ・リソース節約の優位性。

これらを統合して考えた場合、全ての文字エンコーディングを Unicode (UTF-8, UTF-16) に置き換えるのは、ほぼ不可能に近いと思われます。

もちろん、可能な限りUnicode へ転換すべきなのは間違いありません。
例えば、政府や自治体はグローバル化への対応のために、Unicode 対応が必須です。
特定技能の外国人労働者などに住民票を発行する場合、その外国人の名前をデジタル登録できなければ、受け入れに支障を来します。
それは、Unicode を使用しなければ不可能です。
医療や介護の分野でも、外国人看護師や外国人介護士は絶対に必要です。
組み込みソフトウェアの分野でも、 IoT機器はネットワークに接続して、UTF-8 の REST-APIなどにアクセスする必要があります。
この場合は、IoT機器側で UTF-8 か UTF-16 のエンコード処理が必要になるかも知れません。

Unicode 対応が必要であることは、間違い無いのです。
しかし、現実には全ての文字エンコーディングを Unicode にする事は難しいことが、これまでの解説で理解できると思います。

「2025年の崖」と文字エンコーディング問題

2025年現在、日本国内におけるShift_JIS（以下SJIS）データは、ウェブの世界ではほぼ絶滅（シェア0.1%未満）している一方で、「企業の基幹システム」「金融・行政の内部データ」「Excel主体の現場」という3つの領域において、依然として膨大な量のレガシーデータが残存しています。
そのデータ量は、数ペタバイト級、あるいはそれ以上の規模で静かに眠り、また流通し続けています。

経産省のDXレポートでは、2025年を境にレガシーシステムが技術的負債として日本企業全体で12兆円の負担となり、AIなど新規の「攻めの投資」を毀損すると予言しましたが、ほぼ的中していると思います。
数ペタバイト級の膨大なSJISデータをUnicodeに変換するだけでも大変な労力とコストがかかります。
ここに42万人かそれ以上のITエンジニア不足が重なっています。これもDXレポートで予言されていた通りです。
そもそもシステム内部がブラックボックス化していてマイグレーションすらできなくなっています。
NTTデータやSCCKなどがAIを活用したレガシーシステムのマイグレーションサービスをこれから提供するという報道がありましたが、これからマイグレーションサービスを提供するということは、現時点でマイグレーションできていない証拠でもあります。

数ペタバイト級の膨大なSJISデータの存在は、「2025年の崖」を裏付ける「数ある原因の一つ」でもあります。

クラウドやWebの世界だけしか触れていないと、SJISデータの問題は体感できないと思いますが、日本社会のDX推進において、無視できない大きな障害の一つであることは、ITに関わる全ての人々が常識として認識しておくべき社会問題だと思います。

以上、日本特有のレガシーシステムと文字エンコーディングの問題についての解説でした。

関連資料

あなたのCSVが会社を潰す日 〜非エンジニアが知らずにやらかすWindowsの罠〜

地方公共団体情報システムデータ要件・連携要件標準仕様書

「DX動向2025」日米独比較で探る成果創出の方向性「内向き・部分最適」から「外向き・全体最適」へ

新規Webサイトの snow-stack.net を始めました。 このサイトは GitHub Pages で作成しています。

以前、GitHub Pages 以外のレンタルサーバーで Wordpress のWebサイトを運営していましたが、いろいろ事情がありまして、そのWebサイトは閉鎖しました。

そのWebサイトでは、技術記事や政治経済や業界評論などランダムなテーマの記事を書いていて、方向性や一貫性が定まらずバラバラな内容のサイトになってしまっていました。

Webサイトの内容をどう修正しても、収拾が付かない状況だったので、一度閉鎖することにしたのです。

理由は、他にもいろいろありますが、ここで説明する必要は無いと思っています。

ただ、そのWebサイトでは技術記事なども書いていまして、自分でも必要な覚え書きのような記事もありました。

正直、自分でもサイトを閉鎖した事で不便になってしまっている側面もありまして、その技術記事の部分だけ、こちらで復活しようと思っています。

また、GitHub で公開していた僅かなソースコードやツールなども、こちらで公開し直そうと思っています。

技術系の記事は、今後は全てこの snow-stack.net に書いて行くつもりです。

以前の経験から、技術系記事は商売や集客には向いていない事が分かっているので、商業目的では書きません。

商売は、別のWebサイトで始めようと思っています。ここでは行いません。

政治経済や業界評論なども別の場所で行おうと思っています。

衰退する技術知識系サイト

生成AIの台頭による stack overflow の急激な衰退に見られるように、技術系記事はネット上での存在価値を失いつつあります。 技術的に分からないことがあれば、生成AIに質問した方が早いからです。 私も分からないことがあれば、生成AIに質問します。いちいち検索しません。

よって、このサイトもほぼ検索される事を期待していません。

ただ、いまのところは、生成AIの回答は断片的な知識の提供には便利ですが、ある程度まとまった知識を獲得する手段としては、いちいちチャットと会話しなければならない点で、不便なところがあります。

ここでは、そういう「チャットと会話していると不便」なタイプの知識を、提供していきたいと思います。

自分でも、いちいちAIに質問するには、不便な知識というものがあるので、そういうものをここにメモして起きたいと思っています。

ネットに書いた知識は、どうせ生成AIの餌になってしまうので、集客などの商業目的での効果は期待していません。

「チャットと会話していると不便」なタイプの知識も、いずれ生成AIの進歩で、価値を失うときは来るでしょう。

そのときは、GitHub で広めたいツールなどを公開し、その解説などをここでやろうと思ってます。

ここは、完全に私の個人的な「庭」であり「遊び場」です。

ここを訪れる人は、そのように理解してください。