程序代码主动地往Richtextbox的客户区堵塞额外字符，讲真，一直都有些心理排斥——主要这样子处理，可能不太安全。

嗯……在表单看不见的负X值区域，复制出一份孖崽，一个不可见的影子控件，反倒是可以为所欲为：反正永远不会影响正常的界面显示，唯，多浪费一份系统资源就是啦。

在影子控件中，可随意加载任意中、英、数字符，这也更贴近实战需求；且，不需[保存/恢复]现场，这也是基于性价比方面考量的一大优势。

故而，这种直接、粗暴的方式，可能是相对合理、方便、快捷的方式。

这星球上，原本最有希望实现“RTF 《==》 MD 双向转换”的代码库，是微软原厂出品的开源的文档转 Markdown 工具“Markitdown”：
https://

结果你猜怎么着？微软似乎自己已放弃了古老的 RTF 格式！微软自己出品的“万能 Markdown 转换工具”，什么阿猫阿狗都能支持，唯独不支持 RTF ！
嘤嘤嘤。

不能逆向说明标记没有完全对等，转换也不能是100%的样子。
既然是开源的东西，文件格式应该是公开的。自己应该可以写转换代码，文件结构确定了就是对号入座。

自己写转换代码，难度太大！且，我对于Python几乎是“文盲”。

我曾经“盯”上一个开源代码：
https://
国内访问时常被墙，也不知现在还能否访问？
若能看到先前的简介——意不意外？惊不惊喜？
那其实是我老人家向作者提出的一系列建议。
只可惜收到了最终代码后，用Python编译出DLL，一测试：

完犊子！这东东并不支持中文！

Python的东西，其实至少有80%以上，是你抄我，我抄你的，真正原创转换算法的极少，大多无非拿人家大厂的算法代码，再外边套一层壳，取个漂亮名字，就可以重新放上github了。
最后一封电邮，我不无遗憾地回复：

Since my specific need was for lossless, reversible conversion between the formats, and current solutions inevitably introduce significant discrepancies, I've concluded this approach isn't viable for my use case.