副标题#e#
初志——我想说的
各人好！
我所知道的正则表达式库有：boost的，GNU的，VC7带的ATL中的和微软宣布的greta。我利用事后三种，greta利用时间最短（才两天）。
此刻我来说说我的感觉
GNU的正则表达式基础就不支持多字节码，配置连UNICODE都不支持，在parse阶段就会犯科操纵。在软件全球化的本日，实在不是一个好现象。利益是支持的语法完备。
ATL中的正则表达式不完全支持多字节码，可以完善的支持UNICODE。不外，此正则表达式书写很是清晰，没有用到STL内里任何高妙的对象，也没有用到模板中出格高妙的对象(我认为这才是C++的成长之道，究竟，智慧人是少数——大部门是平庸的人，曲高寡合，总有一天会被大大都措施员丢弃,剩下一帮好手顾影自怜），所以，通过很是微小和容易的变动就可以完善支持多字节码。缺点是不支持{n,m}语法，不支持递归语法，如："([^\\"]*(\\.)*[^\\"]*)*"。最后一个*是不被支持的。
greta能完善的支持单字节码和UNICODE，语法也完善，并且听说普遍环境下速度也快，不外，把部门实现放cpp里导致不能同时利用单字节码和UNICODE编码，posix和perl语法，办理步伐还算简朴：把cpp更名为inl，在.h里include这个inl，再修改一点此外对象就可。问题是，它没有支持多字节码的实现，我仔细看看了，好像通过本身写一个多字节码的迭代子，可以办理这个问题，因为他支持basic_string。
接下来的问题是：STL如何支持多字节码的？我没有在SGI-STL，STLPort453中找到关于多字节码的对象。basic_string默认只实现了char,wchar_t的base_string。而要本身实现一个迭代子，我又不知道如何下手。
我此刻的需求是
需要正则表达式支持雷同这样的语法：
“/汉字[ ]+[^ ， ,]+[ ]*[，,][ ]*[^ ， ,]+”
以匹配“／汉字 兰征鹏 ，正则表达式”。
利用STL举办字符串搜索都有问题，好比在一篇文章中搜索“正则”，很大概就把三个汉字的中间四个字节匹配上了。呈现这样的环境，让人啼笑皆非。
有这方面履历的或对STL较量熟悉的同仁，请勿吝啬指导
致
礼！
lanzhengpeng
2004-06-02
_______________________________________________
Cpp mailing list
在C/C++中假如想要利用与Perl兼容的regexp库，一个选择是Boost，另一个选择是PCRE库。Boost中的regex算法最近做了改近，平均效率比以前的版本提高了10倍，不外用起来大概较量贫苦。PCRE已经很成熟了，Apache/Postfix/PHP/Python都用它。我认为应该优先思量。不外我本身没有在Windows下编译过，不是很有掌握。
See www.pcre.org
#p#副标题#e#
我小我私家很喜欢Ruby中的正则表达式成果，成果强，速度也很不错。因为Ruby是日本人发现的，处理惩罚东亚大字符集没有任何问题。Ruby与C/C++接口很容易，可是为了这个小成果插手Ruby，好像有点小题大做了。Perl我不熟悉。Lua独创了一套模式匹配语法，并且Lua天生就是要嵌入到C/C++中去的，机能比Perl/Ruby/Python都快的多。Lua的模式匹配语法有点怪，办理lanzhengpeng的问题仿佛是足够的，不外跟尺度regex语法完全差异。
我小我私家的感受，不如静下心来写一个iterator，应该是很容易的。不外我也好久没干过这种工作了，也就平常的说说算了。
孟岩
_______________________________________________
Cpp mailing list
发件人: kyo
发送时间: 2004年6月2日 11:19
收件人: ”C++ Discuss Group”
主题: RE: [cpp]正则表达式和多字节码的问题
兰兄的经验我很有履历，以前也曾经尽力寻找一套好用的正则表达式的C++库，然而用过今后都不太满足。正则表达式中公认的perl是做的最好的（此刻许多库都声称可以支持perl的正则表达式），好比懒惰匹配就很有用。
假如兰兄不是必需用C++ 做的话，可以用内嵌python引擎，然后用python里的正则表达式module re按你的要求的话，需要利用python 2.4以上版本，因为中文的unicode在2.4才支持（2.4还没有release。）
关于C++汉字查找的问题最近假话西游也碰着，因为要限制经济频道里的措辞必需包括“卖”。要准确判定的话，需要先把char*或string的字符串先用MultiByteToWideChar转为 WCHAR或wstring, 然后再查找。
但愿对你有用。
_______________________________________________
Cpp mailing list
孟岩,您好！
See www.pcre.org
多谢！
我小我私家的感受，不如静下心来写一个iterator，应该是很容易的。不外我也好久没干过这种工作了，也就平常的说说算了。
#p#分页标题#e#
我着手写了一下，好像我写一个iterator不起浸染，需要把base_string也一起写了。并且有个很大的问题：++操纵跟–操纵纷歧致。++的时候我可以很容易判定当前字节是否是多字节吗，从而地点+1照旧+2。可是，–的时候就不是那么好做了（思量到支持如GIB5——其汉字的后半字节编码跟英文有重叠），假如纯真的地点-1，会不会呈现问题，这个迭代子是否照旧random_iterator?
致
礼！
lanzhengpeng
2004-06-02
_______________________________________________
Cpp mailing list
发送时间: 2004年6月2日 15:53
收件人: C++ Discuss Group
主题: Re[2]: 复原: [cpp]正则表达式和多字节码的问题
Hello lanzhengpeng,
照旧转一下吧, 转成 wstring。
我想到别的一个问题, 也是我前段干过的。就是英文有 stricmp, 中文是否也应该有一个恍惚查找. 好比忽略掉同音字的。有时候也不消忽略所有同音字，高频字一般纵然同音也不会混用 。一些不常用到的字容易用同音别字取代。别的汉字有多音字的问题，使这种恍惚匹配的算法变得巨大。
我曾经花了一下午的时间整理资料，把大部门 GBK 字集里的汉字的汉语拼音都列出来的(包罗声调)，包罗一字多音的。
尚有一种最常用的 1000 多字的按利用频率分列的表。
有没有人感乐趣呀 🙂
Best regards,
Cloudwu
_______________________________________________
Cpp mailing list
关于C++汉字查找的问题最近假话西游也碰着，因为要限制经济频道里的措辞必需包括“卖”。要准确判定的话，需要先把char*或string的字符串先用MultiByteToWideChar转为 WCHAR或wstring, 然后再查找。这样只能判定有和无，实际上我需要准确位置。
是可以准确查找的呀。
别的是否可以嵌入其他对象：我以为没有须要，实际那些剧本语言最后也通过C/C++来做的，搞欠好还就是用的我们已知的对象。并且正则表达式如此有用，以至于我处处都在利用——无论措施巨细。假如为此在那些浩瀚的措施中嵌入一个剧本，也是我所不肯意的。
_______________________________________________
Cpp mailing list
kyo,您好！
关于C++汉字查找的问题最近假话西游也碰着，因为要限制经济频道里的措辞必需包括“卖”。要准确判定的话，需要先把char*或string的字符串先用MultiByteToWideChar转为 WCHAR或wstring, 然后再查找。这样只能判定有和无，实际上我需要准确位置。
别的是否可以嵌入其他对象：我以为没有须要，实际那些剧本语言最后也通过C/C++来做的，搞欠好还就是用的我们已知的对象。并且正则表达式如此有用，以至于我处处都在利用——无论措施巨细。假如为此在那些浩瀚的措施中嵌入一个剧本，也是我所不肯意的。
致
礼！
lanzhengpeng
2004-06-02
_______________________________________________
Cpp mailing list
Hello lanzhengpeng,
用什么多字节，不单贫苦，效率又低，转换成unicode再处理惩罚拉。
各人都这么推荐，我着手做一下吧。多字及码到ＵＮＩＣＯＤＥ的位置影射也应该不难为什么要转成 unicode? 我以为转成双字节就够了多一步转换干什么?
Best regards,
cloudwu
[每每有精采教化的人有一禁诫：勿发性情]_____________________________________________
Analyst，您好！
用什么多字节，不单贫苦，效率又低，转换成unicode再处理惩罚拉。各人都这么推荐，我着手做一下吧。多字及码到ＵＮＩＣＯＤＥ的位置影射也应该不难。
致
礼！
lanzhengpeng
2004-06-03
_______________________________________________
Cpp mailing list
kyo,您好！
关于C++汉字查找的问题最近假话西游也碰着，因为要限制经济频道里的措辞必需包括“卖”。要准确判定的话，需要先把char*或string的字符串先用MultiByteToWideChar转为 WCHAR或wstring, 然后再查找。这样只能判定有和无，实际上我需要准确位置。
是可以准确查找的呀。
我曾经做过一个小东西，提取并修改代码中的文字部门，并将文字汇总到一个文件里，需要当地化的时候，修改这个文件就可。好比：LANGUAGE(0,"我曾经做过一个小东西")；正则表达式应该很容易抽取出0，而且将0替换成一个其他的数值（就是后头的字符在文件中排序的编号）。假如转换事后，我怎么知道本来的位置呢？
致
礼！
lanzhengpeng
2004-06-03
_______________________________________________
Cpp mailing list
各人好！
克日空闲了，着手写个正则表达式理会的对象吧，不求速度，只求满意我的要求。在我完成必然阶段的编码后，会交付源代码给各人测试。
此刻问几个问题：
“^”作为匹配起始的时候：
#p#分页标题#e#
一、在单行模式下（即全文中可以包括换行标记“\n”，可是“$”不匹配“\n”，而是匹配竣事。同时，“.”可匹配“\n”），“^”能否写在表达式的中间，如此一定没有任何可匹配的对象。这个时候是否作为语法错误？
二、在多行模式下，“^”是作为匹配的起始地点照旧说匹配“\n ”的后一个字符？我较量趋向于匹配起始地点
三、在多行模式下，“$”能否匹配匹配串的竣事？照旧只匹配“\n|\r\n”
四、“^$”是否作为语法错误处理惩罚？假如不作为语法错误，是匹配一个空串照旧什么都不匹配？
这些疑问，在各个正则表达式库或各个东西(如VC，UEdit)都有差异的处理惩罚方案。
别的,我临时没有找到正则表达式具体先容的资料（如rfc或编译道理的书籍），烦请哪位达人提供一份资料，中文最好，英语也可，其它语言不思量。
_______________________________________________
Cpp mailing list
关于C++汉字查找的问题最近假话西游也碰着，因为要限制经济频道里的措辞必需包括“卖”。要准确判定的话，需要先把char*或string的字符串先用MultiByteToWideChar转为 WCHAR或wstring, 然后再查找。这样只能判定有和无，实际上我需要准确位置。
是可以准确查找的呀。
我曾经做过一个小东西，提取并修改代码中的文字部门，并将文字汇总到一个文件里，需要当地化的时候，修改这个文件就可。好比：LANGUAGE(0,"我曾经做过一个小东西");
正则表达式应该很容易抽取出0，而且将0替换成一个其他的数值（就是后头的字符在文件中排序的编号）。假如转换事后，我怎么知道本来的位置呢？
wchar 查找到位置后，然后把它逐个转换为char不就知道了嘛，哈哈 ：B
致
礼！
lanzhengpeng
2004-06-05
_______________________________________________
Cpp mailing list
我是初学者， 也来添乱：
一.在单行模式下^ $都只表述位置观念(开始， 竣事）， 而不匹配详细的任何字串，所以$虽然不匹配"\n "， ^写在中间是可以匹配的， 好比我写 a?^b 可能是a{0}^b时， bcd是可以匹配的， 虽然把开始位置的匹配写到其他处所不是一个好习惯， 可是也许也不该该克制吧？
二.多行模式下^匹配"\n"的下一个字符, 好比^\d 和abcd\n123匹配， 而$匹配"\n"的上一个字符， 好比is$ 和his\nhere匹配 。
三.不是很领略所说的， 应该是指is$是否和hr\nhis这样的字串匹配吧？ 谜底是yes多行模式下使$舆行的末端匹配（而不止是字符串的末端）， ^舆行的开始匹配（而不止是字符串的开始）
四.不该该判为犯科， 单行模式下 ^$匹配"" 多行模式下匹配"aaa\n\naaa"（空行)只用egrep测试过^_^
书就有一本了， 来可欣这边就可以看到啦…《regular expression》
_____________________________________________
Cpp mailing list
我想说的
我相信，这个世界上的正则表达式理会库远远不止我知道的这些，可是，愿意开源的就很少了。开源的库其质量也是东倒西歪，或着重点差异。出格引人注目标是，在所有这些已知的代码库中，没有一个是中国措施员写的。我但愿冲破这种排场，而且注重成果和支持多字节码（不只仅是东亚大字符集），速度是其次——因为我的功底不足，对正则表达式不长短常熟悉，对有限自念头也没有领略透彻。
假如你要说我这个正则表达式语法不正统，那么，我会说你长得不像人——因为我才是尺度的人样。
请勿散播造车不必从轮子造起的论调，我有许多大原理，但我不肯意写。公司率领对这个开放代码持有异议，不外，由于此代码库没有用在公司任何项目上，而且我僵持在家里完成代码的编码事情（这篇文章倒是在公司呆板上写的），因此，此代码库不存在其他的版权纠纷，
本文配套源码
