Visual Studio 2022 C++ IMultiLanguage2のマルチスレッド化メモ
はじめに
BF(butterfly search)で必要な機能の一つに文字コード判定機能があります。
BFでは、IMultiLanguage2::DetectInputCodepageを使用しています。
リリース当時、判別方法はこれしかなかった記憶があります。文字コードの誤判定もかなりありますが仕方なくこれを採用。
近年のBF修正方針としては、CPUとメモリはあるだけ使用していく。18年前とは環境が違います。
マルチスレッド非対応
IMultiLanguage2はマルチスレッドに対応していないという問題があります。
BF動作中に確認してみると32中30スレッドがDetectInputCodepageで待ち合わせしていました。
これは許容できません。
代わりのマルチスレッドに対応したAPIを紹介して欲しいとチャッピーにお願いすると、
uchardet(https://github.com/BYVoid/uchardet)を紹介されました。
uchardetはもともとMozillaによって開発されたエンコード検出ライブラリで、「EmEditor」が従来備えていた処理よりも精度が改善されているということでよい事尽くしだと。
チャッピーまとめ
まとめるとチャッピーの回答は以下です。
・IMultiLanguage2::DetectInputCodepage → uchardet::uchardet_get_charset を使え。
・IMultiLanguage2::ConvertStringToUnicodeEx → MultiByteToWideChart を使え。
・読み込ませる範囲は先頭部分だけでよい。
最終的な修正
最終的な修正は下記になりました。
・IMultiLanguage2::DetectInputCodepage → 初めにuchardet::uchardet_get_charsetを使用し失敗した場合は、IMultiLanguage2::DetectInputCodepageを使う。
・IMultiLanguage2::ConvertStringToUnicodeEx →初めにMultiByteToWideChartを使いし失敗した場合は、IMultiLanguage2::ConvertStringToUnicodeExを使う。
・読み込ませる範囲は先頭部分だけではダメ。先頭128KBでは誤判定が増える。今は先頭3MBだが結局3MBのままに。
苦労した点
・誤判定多し
uchardet::uchardet_get_charsetの判定結果は海外寄り。漢字になるように文字コードを判定して欲しいのだけど。。。
→uchardetへの貢献が足りないので、変換も漢字の優先度が低いのか。なんとも悲しい。日本の弱さがこんなところにも。
→UTF8と判定されることが多いような。。。時代の流れなのか、UTF8を使用しない方が悪いという考えなのか。
pythonもnotepadの初期値もUTF8だしな。しょうがないのか。時代に取り残されているのか。
・uchardetのビルドが通らない
https://github.com/BYVoid/uchardetはgetopt.cがないとか言ってビルドが通らない。しょうがないので
https://github.com/takamin/win-c/tree/masterからgetopt.cを持ってきた。
・チャッピーが雑
チャッピーにコードを書いてもらうと、本当に人間が書いたような雑なコードになる。utf16がエラーになった。結局はほぼすべてを自分で調べて修正することに。
・チャッピーの余計なアドバイス
・MultiByteToWideChartの繊細さ
MultiByteToWideChartはすぐに変換を諦める。MB_ERR_INVALID_CHARSを外してもダメ。非常に繊細でIMultiLanguage2::ConvertStringToUnicodeExのようなタフさがない。誤った動作に関して厳しいのかもしれない。
知見
チャッピーに感謝しつつ疑う必要あり。
ちなみにこの文章はAI(チャッピー=chatGPT)に修正させていません。修正させたらAIぽくなってしまったので。
コメント
コメントを投稿