mfprobe・mfsr の Version 1.1.0.0 をリリースしました。
mfprobe・mfsr のリリース
先日、winget および dotnet tool (NuGet.org) の配布サイトから、mfprobe と mfsr の Version 1.1.0.0 をリリースしました。
dotnet tool からのリリースは、一足早く 2026年8月1日の夕方から公開していたのですが、winget のリリースはMicrosoftの承認を受けなければならないので、リリースに時間がかかってしまいました。
既に、GitHub Release の公開モジュールは、以下から提供済みです。(winget から提供しているモジュールもこのモジュールです)
コマンドの使い方解説は、以下にあります。
rmsmf-txprobe & mfsr-mfprobe 使い方の分かりやすい解説
変更点の解説
大きな外部仕様の変更や新機能追加はありません。
基本的な変更点は、内部構造の変更です。
ただし、mfprobe の検索オプションには、後述する小さな機能改良を加えています。
従来、mfprobe と mfsr は文字エンコーディング・改行コード・BOMの有無の解析を、独自に実装してコマンドモジュールに内蔵していました。
この内蔵モジュールを少し前にリリースした SnowStack.EncodingProbe に入れ替えました。
SnowStack.EncodingProbe NuGet Package 解説
Version 1.1.0.0 では、mfprobe と mfsr の文字エンコーディング解析モジュールは、SnowStack.EncodingProbe.PowerShell と同じモジュールを使用しています。
Resolve-Encoding コマンドレットと mfprobe の解析結果は、同じになります。
SnowStack.EncodingProbe.PowerShell 解説
機能面の微細な変更点
微細な機能変更はあります。
まず、韓国語・繁体字中国語・簡体字中国語の解析処理を厳格化しました。以前より解析精度は向上しているはずです。
また、日本語・韓国語・繁体字中国語・簡体字中国語の解析処理において、以下のロジックを適用しました。
日本語
バイナリパターン解析の結果、Shift_JIS と EUC-JP のどちらにも該当する結果が出た場合、以下の判定基準を適用します。
IF (テキスト内に改行が存在する) {
IF (改行がWindows型である) {
Shift_JIS と解釈する。
}
ELSE {
EUC-JP と解釈する。
}
}
ELSE {
IF (稼働OSがWindowsである) {
Shift_JIS と解釈する。
}
ELSE {
EUC-JP と解釈する。
}
}
韓国語
バイナリパターン解析の結果、EUC-KR と CP949 のどちらにも該当する結果が出た場合、CP949と解釈します。
CP949 は EUC-KR を包含します。Windowsユーザーのほとんどは、旧文字エンコーディングを使用する場合、CP949 を使用するはずなので、EUC-KR を返すとかえって利便性を損ないます。
よって、EUC-KR 値を返さない方がユーザーの利益になると判断しました。
EUC-KR に該当する場合は、CP949値を返します。
繁体字中国語（台湾華語）
バイナリパターン解析の結果、EUC-TW と Big5 のどちらにも該当する結果が出た場合、Big5 と解釈します。
文字集合としては、EUC-TW の基になっている CNS 11643 の方が、Big5 より広い範囲をカバーしています。しかし実運用上、Windowsユーザーの旧テキスト資産はほとんどが Big5 (CP950) であり、EUC-TW が使われている例は稀です。
よって、EUC-TW 値を返すよりも Big5 値を返す方が、ユーザーの利益になると判断しました。
EUC-TW に該当する場合は、Big5 値を返します。
台湾で策定された Big5 を元に Windowsで定義された文字エンコーディングが CP950 です。
WindowsとWebの世界では、Big5 と CP950 は同一の文字エンコーディングと解釈されます。
厳密には、両者は規格に少し異なる部分がありますが、Windows環境では CP950 を Big5 と解釈して一般的に運用されています。
SnowStack.EncodingProbe も同様の解釈を適用しています。
現在、Google Chrome や Firefox などのモダンブラウザで charset=big5 と指定した場合、ブラウザ内部では自動的に Windows CP950（またはその拡張版）として解釈されます。
そのため、Webの世界では「Big5 ≒ CP950」として扱われることがほとんどです。
なお、厳密には WHATWG Encoding Standard において、big5 ラベルは HKSCS の拡張分を含むインデックスにマップされます。SnowStack.EncodingProbe の解析処理は、この HKSCS 領域には現時点で未対応です。（後述）
繁体字中国語（香港広東語）
香港の広東語では、その昔 Big5の香港拡張が使用されていました。現在はUTF-8で統一されています。
SnowStack.EncodingProbe は、香港 Big5 には未対応です。
将来的には、対応するつもりでいます。
いつ対応するか、ハッキリとは宣言できません。
申し訳ありません。
簡体字中国語（大陸中国北京語）
中国では、漢字の簡略化が行われ、伝統的な漢字である繁体字とは異なる簡体字を公用文字として使用しています。
中国語の文字エンコーディングは古い順に、GB2312 → GBK (CP936) → GB18030 という種類が存在します。
これらの規格は、新しい方が古い規格を包含する規格になっており、原理的に「GB2312 は GBK にも GB18030 にも該当する」ことになります。
よって、GB2312 と GBK と GB18030 の全てに該当するテキストは存在し、それが三つのどれなのかはテキスト単体では区別できません。
Windows環境では、Unicode時代に入る前には GBK (CP936) を標準文字エンコーディングとして使用していたので、Windowsユーザーの古いテキスト資産は、ほとんど GBK (CP936) で書かれていることになります。
現在、中華人民共和国の民間人は、世界の人々と同様にほとんど UTF-8 を使用しています。
UTF-8 が普及する前は、GBK (CP936) を使用していました。
GB18030 は中華人民共和国の強制性国家標準であり、中国国内で販売される OS やソフトウェアには対応が義務付けられています。ただし、実際に GB18030 固有の領域まで使用するのは行政機関などが中心で、民間ユーザーが保存したテキストが GB18030 でしか解釈できないケースは稀です。
よって、SnowStack.EncodingProbe は、バイナリパターン解析の結果として、GB2312 と GBK (CP936) と GB18030 の何れにも該当する場合、GBK (CP936) と解釈します。
確率的に GBK (CP936) と解釈するのが、一番ユーザーの利益になると思われるためです。
なお、GB18030 としか解釈できないテキストが存在すれば、GB18030 と結果を返します。
GB2312 という解析結果が返ることはありません。
文字エンコーディングの解析処理まとめ
Unicode (UTF-8) がWindows環境の標準になる以前は、日本では Shift_JIS (CP932) が、韓国では CP949 が、台湾では Big5 (CP950) が、中国では GBK (CP936) が、Windowsの標準文字エンコーディングでした。
よく問題になる Excel で CSVファイルを読み込んだときに文字化けする問題も、日本・韓国・台湾・中国で同じような問題を抱えています。
日本では、Windows環境のCSVの標準は Shift_JIS (CP932) であり、UTF-8ならBOMが付いていなければなりません。
韓国では、Windows環境のCSVの標準は CP949 であり、UTF-8ならBOMが付いていなければなりません。
台湾では、Windows環境のCSVの標準は Big5 (CP950) であり、UTF-8ならBOMが付いていなければなりません。
中国では、Windows環境のCSVの標準は GBK (CP936) であり、UTF-8ならBOMが付いていなければなりません。
（Microsoft 365 版の Excel では、BOM の無い UTF-8 の CSV を正しく読み込める場合もありますが、環境やバージョンに依存するため、確実性を求めるなら BOM を付けるのが無難です）
つまり、東アジア漢字文化圏では、文字エンコーディングの実装方法が似通っており、同じような文字化け問題を抱えていることになります。
旧文字エンコーディングでマルチバイト文字エンコーディングを使用していたのも、東アジア漢字文化圏特有の仕様であり、Unicode以前は、他の国々はシングルバイト文字エンコーディングを使用していました。
（ベトナムは漢字を廃してラテン文字表記に移行したため、Unicode 以前の文字エンコーディングも TCVN3 や VISCII などのシングルバイト系が中心でした。IT化の開始が他国より遅く、早い段階から Unicode に移行したこともあり、CJK のような古い文字コード問題はあまり抱えていません）
よって、文字エンコーディングのバイナリ解析処理も、東アジア漢字文化圏で必要になる解析処理と、シングルバイト文字エンコーディングを解析する処理とでは、異なってきます。
東アジア漢字文化圏の旧文字エンコーディング解析処理を、SnowStack.EncodingProbe で独自実装して、シングルバイト文字エンコーディングの解析処理を海外製の UTF.Unknown に任せているのも、このような東アジア漢字文化圏特有の事情に対応するためです。
検索処理の微細な機能修正
文字エンコーディングの解析処理以外に、mfprobe の文字列検索処理に少し機能修正を行いました。
mfprobe の /s オプションで検索キーワードを記述した検索文字列リストを指定して、複数文字列の一括検索ができます。
mfprobe /s:slist.txt *.txt
この検索文字列リストの中には、これまで一行ごとに検索文字列一つを記述することしかできませんでした。
一方、mfsr では /r オプションで、置換単語リストCSVを指定して、複数文字列の一括置換を実行できました。
mfsr /r:rlist.txt *.txt
元々、mfprobe コマンドは、mfsr で置換する前に、置換対象となるテキストファイルがどれなのか確認する為に作成したコマンドです。
/r:rlist.txt で指定した置換単語リストCSVの左端カラムで指定した文字列と、同じ文字列を/s:slist.txt で指定することになります。
実作業としては、置換単語リストCSVの左端カラムだけを、別の slist.txt にコピーして検索文字列リストを別途作成しなければなりません。
これは単純に無駄な二度手間なので、/r:rlist.txt で指定する予定の置換単語リストCSVを、そのまま/s:rlist.txt という風に指定できるように、mfprobe を改造しました。
mfprobe /s:rlist.txt *.txt
mfsr /r:rlist.txt *.txt
これで、rlist.txt を、mfprobe の /s オプションと、mfsr の /r オプションの両方で共用できます。
mfprobe 側では、rlist.txt の中にカンマが存在する場合は、左端のカラムだけを読み込み検索するように作っています。
従来と同じ使い方も可能です。
mfprobe の不具合修正
mfprobe 1.0.5.0 には、/s オプションを使用した検索処理に、一部の検索ができない不具合がありました。
この不具合は、1.1.0.0 で解消しました。
気がつかなくて申し訳ないです。
（後述の txprobe 1.0.5.0 には、この不具合は存在しません）
txprobe・rmsmf のリリース
mfprobe・mfsr Version 1.1.0.0 と同様の改造を行った、txprobe・rmsmf の Version 1.1.0.0 も以下のサイトからリリースしています。
こちらは、rmsmf-suite-v1.1.0.0.zip をダウンロードして、ZIPファイルを解凍し、その中のファイル全てを、環境変数 PATH の通ったフォルダーにコピーしてください。
.NET Framework 4.8 のある環境なら、これで起動します。
txprobe・rmsmf は、winget や dotnet tool では、提供していません。
ご了承ください。
最後に
これまで、mfprobe・mfsr・txprobe・rmsmf のどれも日本以外の東アジア漢字文化圏の文字エンコーディングの解析処理が不完全な状態で提供していました。
韓国、台湾、中国の旧文字エンコーディングの解析処理のことです。
これらの国の文字エンコーディングの解析処理は、一応可能ではあったのですが、先に解説した「二つの文字エンコーディングの両方に該当する」パターンへの対処方法が定まっておらず、韓国・台湾・中国のテストコードは保留のままスキップして提供していました。
何度も解説していますように、文字エンコーディングの解析処理を、完璧に行うことは不可能です。
日本語でも Shift_JIS と EUC-JP の両方に該当するバイナリパターンは存在するので、この場合はバイナリパターン解析だけで文字エンコーディングを識別することは、できません。
よって、カルチャーやOSの種類など、文字エンコーディング以外の要素も判断材料として活用して、どうしても識別できないバイナリパターンの場合は、使用されている確率の高い文字エンコーディングを選択する仕様にしました。
これ以上の精度で文字エンコーディングの解析処理をするのは、私には難しいと思います。
最初に、mfprobe・mfsr をリリースしてから、約半年も経ちましたが、ここまで来るのに地味に苦労しました。
文字エンコーディングの解析処理と、それらをNuGetパッケージにして共有できるようにすること、PowerShellコマンドレットで提供すること、CJK圏のどこでも使用できるようにすること、どれも結構難しかったです。
開発自体は、GitHub Copilot や Claude Code が使用できるようになったので、後になるほど楽になってきましたが、NuGet パッケージやPowerShellコマンドレットに関しては、仕様策定に苦労しました。テストもAI任せではどうしても抜け漏れが生じてしまい、 自分で確認しなければならない部分も少なくないのが、AIを使用した開発の現実でした。
ようやく、目指していた水準の機能と品質に到達したので、これから提供記事などに、もっと力を入れていきたいと思います。
多言語対応について
ちなみに、これらのコマンドは、ヘルプメッセージこそ英語・日本語・韓国語・繁体字中国語・簡体字中国語でしか表示していませんが、文字エンコーディングの解析処理には独自実装だけでなく、UTF.Unknown を使用しているので、UTF.Unknown が対応している全ての国々で使用できます。
日本・韓国・繁体字中国語圏・簡体字中国語圏以外のカルチャーの場合は、全てのメッセージが英語になります。
OSのカルチャーで自動的に表示言語を切り替えているのです。
このブログは日本語でしか書いていませんが、是非他の国々の方々も、ご利用ください。
MITライセンスなので、保証はありませんが、商用・非商用どちらでも無料です。