サーバー側でメッセージフィルターモードを実行するために Aho-Corasick アルゴリズムを採用した私のプロジェクトでは、サーバーが取得したメッセージはマルチバイト文字の文字列です。しかし、いくつかのテストの後、ボトルネックはマルチバイト文字列とユニコード wstring の間の変換であることがわかりました。私が今使っているのは mbstowcs_s と wcstombs_s のペアで、モード全体の 95% 近くの時間コストがかかります。また、MultiByteToWideChar/WideCharToMultiByte を試してみましたが、同じ結果が得られました。だから、仕事をするためのもっと効率的な方法が他にあるのだろうか？私のプロジェクトは VS2005 でビルドされており、変換された文字列には中国語の文字が含まれます。どうもありがとう。
4 に答える
1
いくつかの可能性があります。
まず、「マルチバイト文字」とはどういう意味ですか? UTF8 または ISO DBCS システムのことですか?
UTF8 と UTF16 の定義を見ると、高度に最適化された変換を行う範囲があり、「x」ビットを切り取って再フォーマットします。たとえば、http: //www.faqs.org/rfcs/rfc2044.html UTF8<==>UTF32 についての説明を参照してください。UTF16 の調整は簡単です。
2 番目のオプションは、完全に UTF16 で動作することです。Web ページ (または UI ダイアログなど) を UTF16 でレンダリングし、その方法でユーザー入力を取得します。
他のすべてが失敗した場合、Aho-Corasick 以外の文字列アルゴリズムがあります。おそらく、元のエンコーディングで機能するアルゴリズムを探してください。
[2010 年 1 月 29 日追加] mbtowc() と wctomb の 2 つの C 実装を含む変換の詳細については、 http: //www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt を参照してください。 (). これらは、任意の大きな wchar_ts で動作するように設計されています。16 ビットの wchar_ts しかない場合は、大幅に簡素化できます。
これらは、標準ライブラリの一般的な (コード ページに依存する) バージョンよりもはるかに高速です。
于 2010-01-27T12:23:09.173 に答える
0
おそらく、MultiByteToWideChar への呼び出しの量を減らすことができますか?
于 2010-01-27T10:12:05.963 に答える
0
推奨されていませんが (私は信じています)、安全でないバージョン (mbstowcs と wcstombs) をいつでも使用できます。ただし、これが顕著な改善をもたらすかどうかはわかりません。または、文字セットが制限されている場合 (たとえば、a ～ z、0 ～ 9)、ルックアップ テーブルを使用して常に手動で行うことができます..?
于 2010-01-27T10:05:21.393 に答える
0
Aho-Corasick を採用して、マルチバイト文字列を直接処理することもできます。
于 2010-01-27T10:32:25.867 に答える