这个问题指的是 TeX 程序在读取 .tex 文件的一行后如何创建标记。它实际上并不是指编写宏或进行标记化后分阶段进行的排版工作。
假设 TeX 已切换到逐字 catcode 制度，其中^^-notation 等不起作用。
（逐字的 catcode 制度：（␣空格）、、、、、、、、、、\和都分配了类别代码 12，即“其他”。没有字符分配类别代码{0、1、2、3、4、6、7、8、10、14之一，并且唯一可能处于活动状态或可能具有类别}5的字符是回车符，它也可能具有类别 9、11、12 和 15 之一。）$&#^_%~
当这种 catcode 机制生效时，TeX 能否通过从 .tex 文件中读取行并对该行的字符进行标记来生成字符代码为 13 的显式字符标记？
（TeX 内部字符编码方案中的字符代码 13 表示也称为“回车符”或 CR 的字符。因此，我们将此类标记命名为显式回车符标记。）
（编辑：提出这个问题的动机是试图理解为什么 LaTeX 的逐字环境和类型参数+v依赖于显式回车符标记作为相应 .tex 输入文件中行结束位置的标记是安全的。似乎它是安全的，因为在逐字模式下，除了由于 -mechanism 之外，这样的字符标记在标记化过程中不能出现\endlinechar。）
答案1
（这个答案没有考虑到 LuaTeX 引擎的 Lua 后端的可能性。）
简单来说：
使用此答案1的初始版本的作者所知的 TeX 实现，从文本文件读取一行的例程（在其他内容之下）不会将文本文件中出现的回车符视为属于写入“一行”文本的字符的内容。 但是，从文本文件中读取一行的例程将文本文件中出现的回车符视为表示文本文件中的后续内容属于文本文件后续行的内容。
因此，根据该答案初始版本的作者所知的 TeX 实现，文本文件中出现的回车符在从文本文件读取一行后不会被 TeX 处理为“文本文件行的字符”，而在从文本文件读取过程中没有被处理成“文本文件行的字符”的文本文件字符在标记化过程中不会受到处理。
利用该答案初始版本的作者所知的 TeX 实现，在阅读文本文件的背景下，该答案初始版本的作者仅知道两种可能性，即回车符在标记化过程中受到处理的情况如何产生：
可能性 1：
在读取文本文件中的一行之后，在预处理该行字符的阶段，如果分类代码制度尚未生效，TeX 的\endlinechar-mechanism 可能导致将回车符附加到“文本文件行的字符”中。该回车符在标记化过程中会受到处理，因此会根据处理时当前的 catcode 制度进行处理。
（在^^无法使用 -notation 的 catcode 制度下，这是在标记化过程中处理回车符的唯一可能性。）
可能性 2：
在^^可以使用 -notation 的 catcode 机制下，在标记化阶段（即预处理之后），可能会出现对回车符进行处理的情况，因为会遇到回车符的^^-representation，即^^M或^^0d，并用回车符替换形成该 -representation 的字符^^，然后根据处理时当前的 catcode 机制处理该回车符。
因此，根据该答案初始版本的作者所知的 TeX 实现，在标记化过程中对回车符进行处理的情况绝不是由于 TeX 在读取文本文件的一行之后立即在文本文件中发现它，TeX 会考虑该文本文件的该行的字符。
----
1这个答案的初始版本的作者只知道 TeX 的 web2c 实现，其中 ⟨linefeed⟩ 和 ⟨carriage return⟩ 和 ⟨carriage return⟩⟨linefeed⟩ 被视为行尾。