文字コード自動判別にwin10組み込みのICU4Cを使う

[berryzplus]

PR の目的

タイトル通りです。
#1104 のPRを改善して、ICU4Cの巨大なDLLを用意しなくても済むように改良します。

カテゴリ

• 仕様変更

PR の背景

#1783 の焼き直しです。

#1783 は、変更を最小限に抑えるために、
手元で作っていた仮対応からMInGW対応を考慮を除外していました。
（結果、ビルドが通らなかったので閉じてしまいましたが・・・）

妥協できるところまでの精査が終わったのでPRとする次第です。

PR のメリット

PR のデメリット (トレードオフとかあれば)

仕様・動作説明

変更前： ICU4C66があれば自動判別にICU4Cを使う。
変更後： Windows 10 1903以降なら自動判別にICU4Cを使う。

Windows 10のアップデートは、
端末のスペックが不十分である場合を除いて、
ユーザーが固定しない限りは「勝手にWindows 11に更新される」ようになっています。

修正により #1726 の機能が実質的に死にますが、
その点が「いいか悪いか」は一旦わきに置いておきたいです。

PR の影響範囲

文字コード自動判別に影響する変更です。

テスト内容

テスト1

手順

関連 issue, PR

• ICU4Cによる文字コード検出機能を追加する #1104
• uchardet.dll が存在したらそれを使って文字エンコーディングの検出が行われるように処理追加 #1726
• ICU4CをWindows10同梱のものに差し替える検討 #1783

参考資料

[AppVeyorBot]

❌ Build sakura 1.0.4015 failed (commit 300a2d9ae7 by @berryzplus)

[berryzplus]

テストが失敗している・・・

[sonarcloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

58.3% Coverage
0.0% Duplication

[beru]

Windows 8.1を使っているユーザーがビルドが出来ないという苦情が来ないか心配…は特にしていません。

NTDDI_VERSION についてのページ : https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN

Windows 10 Home and Pro の各リリースについて書かれているページ : https://docs.microsoft.com/en-us/lifecycle/products/windows-10-home-and-pro

古いバージョンでの確認はいつかはされなくなる運命にありますね。

[beru]

追加の情報

https://docs.microsoft.com/en-us/windows/win32/intl/international-components-for-unicode--icu-#history-of-changes-to-the-icu-library-in-windows

[beru]

修正により #1726 の機能が実質的に死にますが、
その点が「いいか悪いか」は一旦わきに置いておきたいです。

これは別に構わないと思います。uchardet対応を生かしたいと思った人がまた別のMRで共存する方法を考えれば良いかなと。

自分が思いつくのは設定でどちらを使うかを切り替えるとかですが、今の作りだと設定項目を増やして設定画面UI側でも新規項目に対応させるように改造するのが大変なので、もっと楽に設定項目を増やせる方式のUIに切り替えた後にした方が良いと思います。いつかはやりたいと思って放置している点の一つですね。

他に気になる点としては、CharsetDetector::Detect の実装で _icuin の場合は _uchardet と違って表引きしていないので対応する文字セットが限られている点です。でもuchardet対応自体が隠し機能みたいなものだし、後でまた別のPRとかで対応すればよいと思います。

[berryzplus]

自分が思いつくのは設定でどちらを使うかを切り替えるとかですが、今の作りだと設定項目を増やして設定画面UI側でも新規項目に対応させるように改造するのが大変なので、もっと楽に設定項目を増やせる方式のUIに切り替えた後にした方が良いと思います。いつかはやりたいと思って放置している点の一つですね。

設定による振る舞いの切替はやりたくないっす。

• 設定の読み込み処理に不安がある。
• 設定の書き込み処理に不安がある。
• 設定の変更管理方法に不安がある。
• 設定の同期方法に不安がある。
• 設定を保持する型の型名が誤っている（DLLじゃないのにDLLと付いている）

他に気になる点としては、CharsetDetector::Detect の実装で _icuin の場合は _uchardet と違って表引きしていないので対応する文字セットが限られている点です。

ここは改善できる部分だと思ってます。
文字セット変換器の生成に「名前」を指定できるようにしたらいいのかな、と。
現状は「独自の文字セット番号」か「Windowsのコードページ（番号）」を指定してます。
影響範囲広いし、めんどうなので対応進めていませんけれども。

[beru]

設定による振る舞いの切替はやりたくないっす。

• 設定の読み込み処理に不安がある。
• 設定の書き込み処理に不安がある。
• 設定の変更管理方法に不安がある。
• 設定の同期方法に不安がある。
• 設定を保持する型の型名が誤っている（DLLじゃないのにDLLと付いている）

これは特定の設定の事なのか、それとも設定全般の事なのか、、後者だとしたら全体的に不安定だという事になりますがまぁミッションクリティカルな用途に使える堅牢性がある実装でない事は確かですね。

ここは改善できる部分だと思ってます。 文字セット変換器の生成に「名前」を指定できるようにしたらいいのかな、と。 現状は「独自の文字セット番号」か「Windowsのコードページ（番号）」を指定してます。 影響範囲広いし、めんどうなので対応進めていませんけれども。

ICU4Cもuchardetも指定できる文字コードセットの名前って互換性が無かったですっけ？未調査ですが…。

[beru]

修正により #1726 の機能が実質的に死にますが、
その点が「いいか悪いか」は一旦わきに置いておきたいです。

思いついた解決策として、CharsetDetector::Detect メソッドで _icuin より先に _uchardet を使った記述を持ってくるように移動すれば良いような気がします。uchardetのDLLはデフォルトでは無いし殆どの環境で置かれていないので影響は少なく、DLLファイルを置いた人だけ使えます。ICU4CのDLLはWindows10の途中から同梱されるようになったという事なので殆どの動作環境で有効化されて使われると思います。

[berryzplus]

ICU4Cの機能は自動判別だけじゃないので、
「それ以外の機能」も使えるよう提案するのが良さそうに思えてきたので閉じます。

[berryzplus]

メモ（NGになったテストの詳細）：

これ。

sakura/tests/unittests/test-cconvert.cpp

Line 458 in e013bcd

ConvTestParamType{ F_CODECNV_AUTO2SJIS, L"化けラッタ!!", L"化けラッタ!!" },

1. L"化けラッタ!!" を SJIS に変換。
   バイナリデータ"化けラッタ!!"(SJIS) ができる。
2. バイナリデータの文字コードを自動判別する。
   ここで判別される文字コードが UTF-16BE(誤判定) になっている。
3. 判別された文字コードでUNICODEに戻す。

uchardetを使った場合には正しく判定できるので、
ICU4Cの単発文字コード判別は使い物にならない
という結論が出たと思っています。