Msftedit与CRichEditCtrl处理RTF末尾\par的异常问题排查

你遇到的这个基于Msftedit 5.41.21.2510版本的CRichEditCtrl在RTF末尾\par标记上的异常行为，我之前也碰到过类似情况——而且正如你发现的，同版本控件驱动的WordPad也存在一样的问题。下面我拆解下各个场景的原因，再给你几个经过验证的解决办法：

一、为什么SetWindowTextA会生成双\par？ #

当你传入带\r\n的文本时，控件会自动将换行符转换为RTF标准的\par标记，但同时，这个旧版本控件有个默认逻辑：会在文档内容末尾额外追加一个\par，确保段落结构的完整性。这就导致了你看到的结果——一个来自\r\n的转换，一个来自控件的自动补全，最终出现双\par。

WordPad里输入带单个换行的文本后生成的RTF有多余\par，本质是同一个控件逻辑在起作用。

二、拼接RTF时段落分隔丢失的核心原因 #

你用SetSel(-1, -1)想把插入点定位到文档末尾，但这里有个容易踩的坑：该方法是将插入点放在最后一个可见字符的前面，而非RTF结构中最后一个\par的后面。

看你给出的测试代码结果：

std::string source1(_RichEditPreamble);
source1 += "\\cf1 test 1\\par}";
SetRichText(wrtf,source1.c_str());
std::string source2(_RichEditPreamble);
source2 += "\\cf0 test 2\\par";
wrtf.SetSel(-1, -1);
SetRichText(wrtf, source2.c_str(), SF_RTF | SFF_SELECTION);

生成的RTF里test 1和test 2直接衔接，就是因为插入点被定位到了test 1对应的\par之前，导致插入的新RTF内容覆盖/跳过了原有的段落结束标记，自然就没了段落分隔。

三、GetRichText导出多\par的问题 #

从数据库读取的RTF是{rtf_stuff ... content\par}，但通过GetRichText导出后变成末尾双\par，同样是控件的自动补全逻辑导致的：控件加载RTF后，会自动检查文档末尾是否有有效的段落结束标记，即使原RTF已经有一个\par，它也会再追加一个，这是旧版本控件的“过度保护”行为。

四、可行的解决办法 #

1. 手动修正插入点位置 #

放弃用SetSel(-1,-1)，改用GetTextLength()获取文本实际长度，然后将插入点定位到这个长度的位置——也就是真正的文档末尾：

int textLen = wrtf.GetTextLength();
wrtf.SetSel(textLen, textLen); // 精准定位到文档末尾

再插入新的RTF内容，就能正常保留段落分隔了。

2. 拼接前统一处理RTF末尾标记 #

在拼接RTF时，手动对齐两端的段落标记：

• 如果原文档导出的RTF末尾有双\par，插入的新RTF开头可以不用加\par；
• 或者在插入前，先给原文档手动添加一个\par（如果检测到末尾没有的话），再插入新内容，确保段落结构连贯。

3. 导出RTF时手动清理多余\par #

用GetRichText获取内容后，手动检查并去除末尾的多余\par，比如：

std::string rtfContent = GetRichText(wrtf);
// 匹配末尾的双\par+闭合括号
size_t pos = rtfContent.rfind("\\par\\par}");
if (pos != std::string::npos) {
    rtfContent.replace(pos, 6, "\\par}"); // 将双\par替换为单个
}

4. 尝试升级控件版本 #

你当前用的Msftedit 5.41.21.2510是Windows 7时代的旧版本，Windows 10/11自带的新版本Msftedit控件对RTF的处理逻辑做了优化，这类自动补全导致的异常大概率已经被修复。如果你的应用可以兼容高版本系统，升级控件是一劳永逸的办法。

关于控件缺陷的判断 #

你说的这个行为确实属于旧版本CRichEdit控件的设计缺陷——它的插入点定位逻辑和RTF自动补全逻辑没有对齐，导致开发者在拼接RTF时很容易出现段落丢失或多余标记的问题。而Word 2007的RTF规范里没有相关说明，是因为规范只定义RTF的格式标准，控件的具体实现细节并不在规范覆盖范围内，不同版本的控件行为自然会有差异。

另外，你提供的EditStreamCallBack回调函数本身没有问题，它只是负责流式读写数据，和这次的\par处理异常无关。

内容的提问来源于stack exchange，提问作者lakeweb