为什么这个复杂的RTF编码的撇号？

Question

Scrivener使用这种精细的撇号编码生成RTF文件：

They didn\loch\af0\hich\af0\dbch\af0\uc1\u8217\'92t do it.

Unicode 8217是“正确的单引号”。好的，但是这个RTF也有unicode字符和\'92。这里发生了什么事？

Answer 1

RTF分为以下几个部分：

They didn    - plain text
\loch        - The text consists of single-byte low-ANSI (0x00–0x79) characters
\af0         - Associated Font Number 0
\hich        - The text consists of single-byte high-ANSI (0x80–0xFF) characters
\af0         - Associated Font Number 0
\dbch        - The text consists of double-byte characters
\af0         - Associated Font Number 0
\uc1         - number of bytes corresponding to a given \uN Unicode character
\u8217       - a single Unicode character that has no equivalent ANSI representation based on the current ANSI code page
\'92         - A hexadecimal value, based on the specified character set (may be used to identify 8-bit values). 
t do it.     - plain text

其中有些是多余的，在这个上下文中可以忽略，它只是字体信息。重要的是，\u8217代表Unicode中的撇号，\'92表示ANSI中等效的撇号，\uc1表示\'92占用1个字符。启用Unicode的RTF阅读器将处理\u8217而忽略\'92。非Unicode读取器将忽略\u8217并处理\'92。这在Unicode RTF的RTF规范中有说明。

\uN 此关键字表示没有基于当前ANSI代码页的等效ANSI表示的单个Unicode字符。N表示以十进制数表示的Unicode字符值。 这个关键字后面紧跟ANSI表示中的等效字符。这样，老读者将忽略\uN 关键字，并正确地选择ANSI表示。当遇到这个关键字时，读取器应该忽略下一个 N 字符，其中 N 对应于遇到的最后一个值。 ..。 当RTF写入器遇到没有相应ANSI字符的Unicode字符时，应该输出\uN，然后是它能够管理的最佳ANSI表示形式。此外，如果Unicode字符转换为ANSI字符流，其字节数与当前Unicode字符字节数不同，则应在\uN关键字之前发出\uN关键字，以通知读者更改的情况。