mfsr・mfprobe・rmsmf・txprobe 1.1.2 リリースのお知らせ
2026年10月2日に mfsr・mfprobe・rmsmf・txprobe のバージョン 1.1.2 のリリースを開始したことを、ご報告します。
先日の SnowStack.EncodingProbe 1.2.0 のリリース時に予告していた、クラスライブラリの入れ替えを行ったものです。
mfsr・mfprobeについては、wingetにて提供しています。
winget upgradeで更新可能なパッケージを確認し、winget upgrade --allでまとめて、または パッケージ ID を指定して個別に更新できます。
winget upgrade
winget upgrade --all
winget upgrade motoi.tsushima.mfprobe
winget upgrade motoi.tsushima.mfsr
新規にインストールする場合は、パッケージ ID を指定してインストールしてください。
winget install motoi.tsushima.mfprobe
winget install motoi.tsushima.mfsr
詳しいインストール方法の解説は以下のページで行っています。
rmsmf・txprobeは、業務上 .NET Framework 4.8しか使用することが許されない方々のために提供しており、wingetによる提供はしておりません。
インストール方法は、以下のページで解説しております。
使用説明書は、以下の固定ページで以前から解説しております。
rmsmf-txprobe & mfsr-mfprobe 使い方の分かりやすい解説
1.1.2 リリース内容
mfsr・mfprobe・rmsmf・txprobe は全て、SnowStack.EncodingProbeクラスライブラリを使用して文字エンコーディング解析を行っています。
先日、このクラスライブラリを1.2.0にアップデートしたので、こちらのコマンド群にも最新版クラスライブラリを導入してリリースしたものが、1.1.2になります。
mfsr・mfprobe・rmsmf・txprobe は全て、クラスライブラリを最新版にアップデートしただけで、基本機能や使い方に変更はありません。
変更点
mfsr・mfprobe・rmsmf・txprobe について、クラスライブラリのアップデートにより、変わった部分があります。
クラスライブラリの変更内容は、以下の固定ページで詳しく解説しています。
SnowStack.EncodingProbe 1.2.0 解説 — ファイル出力・変換コマンドと世界の言語への対応
リリースの告知は、SnowStack.EncodingProbe.PowerShell 1.2.0 リリースのお知らせの記事で行っています。
EncodingProbe（略称）では、文字エンコーディング解析にあたって、独自アルゴリズムと、サードパーティ製品（UTF.Unknown）のアルゴリズムの二つのアルゴリズムで、解析を行っています。
サードパーティ製品のアルゴリズムは、欧米など旧シングルバイト文字エンコーディングの解析には優れていますが、CJK圏など漢字文化圏の旧マルチバイト文字エンコーディングの解析では見劣りするため、CJK圏の文字エンコーディングだけを独自アルゴリズムで解析し、解析精度を補完しています。
旧バージョンでは、欧米など旧シングルバイト文字エンコーディングの解析はEncodingProbeの対応が不十分で、独自アルゴリズム側が旧シングルバイト文字エンコーディングを誤判定してしまう確率が高かったのです。
これまで正式に対応していた言語は、英語・日本語・韓国語・繁体字中国語・簡体字中国語だけで、香港にも未対応でした。
旧シングルバイト文字エンコーディングのファイルを、東アジアの言語環境でコマンドを実行して解析すると、状況によって不必要な独自アルゴリズムの方が稼働してしまい、サードパーティ製品（UTF.Unknown）のアルゴリズムに確実に解析処理を渡せない場合がありました。
今回、旧シングルバイト文字エンコーディングのテスト環境も作り、世界の多くの言語のテストを実施することで、東アジアの言語環境でも、旧シングルバイト文字エンコーディングの解析をサードパーティ製品（UTF.Unknown）に確実に渡せるようになりました。
EncodingProbe 1.2.0により、香港の Big5-HKSCS にも対応しております。（ただし、コマンドの表示メッセージなどは、これまでと同じで、香港向けの変更はしていません）
解析の限界について
旧シングルバイト文字エンコーディングの解析は、サードパーティ製品（UTF.Unknown）に任せているため、サードパーティ製品が誤判定する部分については、EncodingProbeでの対処はできないのが、現状です。
簡単なテストで明らかになっている問題点は、以下のようになります。
| 言語 | 文字エンコーディング | 問題の内容 |
|---|---|---|
| フランス語 | ISO-8859-15 | €（0xA4）を含む場合、€ が ¤ として読まれ、ISO-8859-1 と誤判定される。 |
| スペイン語 | windows-1252 | €（0x80）や —（0x97）を含む場合、これらが制御文字として読まれ、ISO-8859-1 と誤判定される。 |
| イタリア語 | ISO-8859-1 | 文字の一覧や記号の多いテキストなど、内容によっては判定不能になる。 |
| イタリア語 | windows-1252 | 文字の一覧や記号の多いテキストなど、内容によっては判定不能になる。 |
判定不能になる条件については、前述の固定ページの「シングルバイト系の判定は、長さよりも内容で成否が決まります」で詳しく解説しています。
これらの誤判定は、サードパーティ製品の誤判定なので、私には直接対処ができません。対処するとしたら文字エンコーディング解析方法の根本的な見直しが必要になります。現状では、これらの問題に短期間では対処できません。
正しく判定できない場合は、/c: オプションで文字エンコーディング（例: /c:1252）を明示してください。
mfprobe *.txt /c:1252
ユーザー定義領域（私用領域）を使った簡体字中国語のGBK(CP936)のファイルについては、文字エンコーディング自動判定でGB18030と誤判定する問題があります。
これは、独自アルゴリズムの問題なので、私が対処可能です。
これからゆっくり、総合的な対策を考えたいと思います。
世界の言語に対応するのは、テスト方法が複雑で、どうしても個人の力では限界があります。そもそもある程度の世界言語への対応が可能になったのも、生成AIが活用できるからに他なりません。
現状で、私が対処できるところまでは、完成させたと言わせてもらいます。
上記問題点を含め、これ以上の対処が、私の力でできるかどうかは、正直なところ分かりません。
できる範囲内で、対処していきたいと思います。
通常の利用であれば、現在のバージョンで充分に利用可能だと思います。
以上、リリースの報告でした。