在我的项目中，我采用 Aho-Corasick 算法在服务器端做一些消息过滤模式，服务器得到的消息是多字节字符串。但经过几次测试，我发现瓶颈是多字节字符串和 unicode wstring 之间的转换。我现在用的是mbstowcs_s和wcstombs_s这对，占了整个模式将近95%的时间成本。另外，我尝试过 MultiByteToWideChar/WideCharToMultiByte，结果是一样的。所以我想知道是否有其他更有效的方法来完成这项工作？我的项目是用VS2005构建的，转换后的字符串会包含汉字。非常感谢。
问问题
705 次
4 回答
1
有多种可能性。
首先，“多字节字符”是什么意思？您是指 UTF8 还是 ISO DBCS 系统？
如果您查看 UTF8 和 UTF16 的定义，则可以进行高度优化的转换，去掉“x”位并重新格式化它们。参见例如http://www.faqs.org/rfcs/rfc2044.html谈论 UTF8<==>UTF32。调整 UTF16 会很简单。
第二种选择可能是完全在 UTF16 中工作。以 UTF16 呈现您的网页（或 UI 对话框或其他）并以这种方式获取用户输入。
如果一切都失败了，除了 Aho-Corasick 之外，还有其他字符串算法。可能寻找一种适用于您的原始编码的算法。
[2010 年 1 月 29 日添加] 有关转换的更多信息，请参见http://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt，包括 mbtowc() 和 wctomb 的两个 C 实现()。这些旨在与任意大的 wchar_ts 一起使用。如果您只有 16 位 wchar_ts，那么您可以简化很多。
这些将比标准库中的通用（代码页敏感）版本快得多。
于 2010-01-27T12:23:09.173 回答
0
您也可以采用 Aho-Corasick 直接处理多字节字符串。
于 2010-01-27T10:32:25.867 回答
0
已弃用（我相信），但您始终可以使用非安全版本（mbstowcs 和 wcstombs）。不确定这是否会有明显的改善。或者，如果您的字符集是有限的（例如 a - z，0 - 9），您总是可以使用查找表手动完成..？
于 2010-01-27T10:05:21.393 回答
0
也许您可以减少对 MultiByteToWideChar 的调用量？
于 2010-01-27T10:12:05.963 回答