RTF 行尾转换的意外结果

Question

如果txtLog 是RichTextBox 控件：

Dim text = "hi" & vbCrLf
Debug.WriteLine("t:" & text.Length)        ' --> 4, as expected

txtLog.Text = text
Debug.WriteLine("tL:" & txtLog.TextLength) ' --> 3. muh?! :(

查看the RTF spec，段落的结尾被标记为\par，既不是CR也不是LF。这是有道理的，因为 RTF 是标记语言；就像在 HTML 中一样，行尾本身没有什么意义。

所以大概，在写入RichTextBox 时，我的行尾被编码为\par。然后，在提取时，\par 被转换回真实的行尾以供使用。

原来这行结尾是vbLf。

为什么，既然 Microsoft 几乎一致地使用 CRLF 作为行尾，那么 RichTextBox 会将 \par 翻译成 vbLf 而不是 vbCrLf？

Answer 1

您对规范的解释不正确。

RTF 规范明确规定：

回车（字符值 13）或换行符（字符值 10) 如果字符前面有 一个反斜杠。您必须包含反斜杠；否则，RTF 忽略 控制字。 （您可能还想插入一个 至少每 255 个不带反​​斜杠的回车/换行对 字符以便更好地通过通信线路传输文本。）

这使得 RTF 成为一种几乎无格式的语言，即 RTF 内容独立于换行符（即换行符不是原始文本的一部分）：

Hi
\par
guys
\par<eof>

与

相同

Hi\par\guys\par<eof>

即您的读者必须将所有没有前导反斜杠的 CR 和 LF 视为空格。

Hi
\
guys
\
<eof>

-如果换行符是 CR+LF- 让前缀 CR 字符像 \par 标记一样处理，所有 LF 字符都作为空格处理（因为 LF 没有反斜杠前缀)。

所以规范是正确和精确的。

明白了吗？ ;)

(<eof> 表示此处的文件结尾字符，或文件结尾，无论您的文本编辑器输出什么，换行符是 CR、CR LF 或 LF，无论您的文本编辑器输出什么 :) )

为什么，因为 Microsoft 几乎一致地使用 CRLF 作为行尾， RichTextBox 会将 \par 翻译成 vbLf 而不是 vbCrLf？

只有在 Windows 换行符是 CRLF。在其他平台/某些应用程序中，它只是 LF。没有平台只使用 CR 作为换行符。但是，有些平台可以平等地处理 CR 和 LF，即 CRLF 是那里的两个换行符。在其他情况下，如果紧跟 LF，则 CR 将被忽略（这通常包括 Windows 应用程序。）

您看到的行为是确保文本结果在几乎所有平台上产生相同数量的换行符的唯一方法。

（当然，这也是特定于应用程序的......我将其称为鲜为人知的兼容性噩梦之一，即换行符。）

Answer 2

以这种方式实现 RichTextBox 的直接原因是因为 RTF specification 表示回车（本身）或换行符本身等同于 \par。

。 . .回车（字符值 13）或换行符（字符值 10）将被视为 \par 控件。 . .

至于微软为什么要制定这样的规范，我不确定。但是我推测这与first version of RTF 是在 1980 年代为 Mac 版本的 Microsoft Office 开发的事实有关。我猜他们开发了这个 par 规则，以便它在 Mac 上运行良好，或者作为跨平台格式运行良好。如果是这种情况，那么微软可能会非常犹豫在未来几年（90 年代、00 年代等）修改规范以匹配标准 Windows 行尾（因为总的来说，微软有尝试向后支持的历史尽可能地兼容这样的事情）。