JS lexing---多行字符串
JS lexing---multi line string
作为学习的一部分，我正在制作一个 JS 词法分析器。在 JS 中，单行字符串从 " 或 ' 开始并以相同的字符结束，除非该字符前面有反斜杠。
在我当前的代码中，我遍历每个字符并根据 "string" 或 "regex" 等标志将它们附加到现有标记。所以用 " 或 ' 实现多行字符串感觉很自然，因为它似乎不会影响我的词法分析器的任何其他部分
是否有任何实际原因不允许换行作为字符串的内容？
也有这样的语法
const string =
'line1\
line2\
line3'
许多语言（但不是全部）禁止在字符串文字中使用未转义的换行符。所以JavaScript在这里肯定不是唯一的。
但动机真的与词法分析的难易程度或效率无关。事实上，对于词法分析，最简单的语法是允许任何字符，而不必包括特殊情况检查。 [注1]
不过还有其他的考虑；值得注意的是，程序的可读性和易于调试的重要性。长字符串会给阅读代码的人带来额外的负担，因为他们可能不知道程序文本的一部分实际上是字符串文字的一部分。 （多行注释也有类似的问题，这就是为什么通常认为以某种方式标记长注释中的每一行是一种很好的风格，例如在左侧空白处使用垂直的星号列。字符串不存在这样的解决方案不过是文字。)
此外，未终止的多行字符串可能很难更正。如果字符串不能跨行，则将在包含问题的行上检测到错误。但是多行字符串可能会一直持续到下一个字符串的开头，然后在下一个字符串的内容被意外解析为程序文本时触发语法错误。或者更糟的是，导致完全错误地解析应该是程序文本的内容，然后是另一个不正确的字符串文字，从第二个文字结束的地方开始，并从那里继续。
这也使得开发人员工具（例如编辑器和语法高亮显示器）很难在键入时处理程序文本。
最后，您可能会或可能不会发现这些论点令人信服，并且语言设计者也可能有其他审美偏好。我真的不能代表 JavaScript 语言的原始设计者，我们都不能及时远航与他们争论并可能改变他们的决定。
无论好坏，语言都是根据特定的主观判断设计的，如果语言成功，这些判断就会成为永久的特征。如果你使用一种语言，它们是你必须接受的东西，它们通常不值得为之着迷。你习惯了它们，或者你找到了一种不同的语言来编程，它有自己的语法怪癖。
当你设计自己的语言时，你将需要解决大量的句法问题，你无疑会运行遇到答案不明确的情况，因为没有客观正确的唯一解决方案。无论你做什么，都会有人想和你争论。也许你可以让他们参考这个答案。
备注：
实际上有一个不允许多行字符串文字的历史原因，这更清楚，但几十年来或多或少已经无关紧要。
曾几何时，常见的文件系统将文本文件视为 固定长度行 的线性阵列（通常为 80 个字符行，与 Hollerith 卡匹配）。这种文件系统的一个优点是它可以立即导航到文件中的特定行号，因为所有行的长度都相同。但无论如何，对于在穿孔卡片上输入程序的系统，固定长度的行只是环境的一部分。
要使所有行的长度相同，需要用 space 个字符填充行。这显然会使多行字符串文字变得尴尬，这就是为什么 C 从来不允许多行字符串文字，而是依赖于连续的字符串文字自动连接成单个文字的语法功能。
最后，固定行长度的文件系统被证明是不受欢迎的，而且我认为这些天您不太可能 运行 加入其中。但是仔细阅读 C 和 Posix 标准表明，这样的文件系统必须仍然可以通过一致的实现使用，结果是一个完全可移植的程序必须准备好处理输出和尾随的行长度限制 whitespace 输入。
作为学习的一部分，我正在制作一个 JS 词法分析器。在 JS 中，单行字符串从 " 或 ' 开始并以相同的字符结束，除非该字符前面有反斜杠。
在我当前的代码中，我遍历每个字符并根据 "string" 或 "regex" 等标志将它们附加到现有标记。所以用 " 或 ' 实现多行字符串感觉很自然，因为它似乎不会影响我的词法分析器的任何其他部分
是否有任何实际原因不允许换行作为字符串的内容？
也有这样的语法
const string =
'line1\
line2\
line3'
许多语言（但不是全部）禁止在字符串文字中使用未转义的换行符。所以JavaScript在这里肯定不是唯一的。
但动机真的与词法分析的难易程度或效率无关。事实上，对于词法分析，最简单的语法是允许任何字符，而不必包括特殊情况检查。 [注1]
不过还有其他的考虑；值得注意的是，程序的可读性和易于调试的重要性。长字符串会给阅读代码的人带来额外的负担，因为他们可能不知道程序文本的一部分实际上是字符串文字的一部分。 （多行注释也有类似的问题，这就是为什么通常认为以某种方式标记长注释中的每一行是一种很好的风格，例如在左侧空白处使用垂直的星号列。字符串不存在这样的解决方案不过是文字。)
此外，未终止的多行字符串可能很难更正。如果字符串不能跨行，则将在包含问题的行上检测到错误。但是多行字符串可能会一直持续到下一个字符串的开头，然后在下一个字符串的内容被意外解析为程序文本时触发语法错误。或者更糟的是，导致完全错误地解析应该是程序文本的内容，然后是另一个不正确的字符串文字，从第二个文字结束的地方开始，并从那里继续。
这也使得开发人员工具（例如编辑器和语法高亮显示器）很难在键入时处理程序文本。
最后，您可能会或可能不会发现这些论点令人信服，并且语言设计者也可能有其他审美偏好。我真的不能代表 JavaScript 语言的原始设计者，我们都不能及时远航与他们争论并可能改变他们的决定。
无论好坏，语言都是根据特定的主观判断设计的，如果语言成功，这些判断就会成为永久的特征。如果你使用一种语言，它们是你必须接受的东西，它们通常不值得为之着迷。你习惯了它们，或者你找到了一种不同的语言来编程，它有自己的语法怪癖。
当你设计自己的语言时，你将需要解决大量的句法问题，你无疑会运行遇到答案不明确的情况，因为没有客观正确的唯一解决方案。无论你做什么，都会有人想和你争论。也许你可以让他们参考这个答案。
备注：
实际上有一个不允许多行字符串文字的历史原因，这更清楚，但几十年来或多或少已经无关紧要。
曾几何时，常见的文件系统将文本文件视为 固定长度行 的线性阵列（通常为 80 个字符行，与 Hollerith 卡匹配）。这种文件系统的一个优点是它可以立即导航到文件中的特定行号，因为所有行的长度都相同。但无论如何，对于在穿孔卡片上输入程序的系统，固定长度的行只是环境的一部分。
要使所有行的长度相同，需要用 space 个字符填充行。这显然会使多行字符串文字变得尴尬，这就是为什么 C 从来不允许多行字符串文字，而是依赖于连续的字符串文字自动连接成单个文字的语法功能。
最后，固定行长度的文件系统被证明是不受欢迎的，而且我认为这些天您不太可能 运行 加入其中。但是仔细阅读 C 和 Posix 标准表明，这样的文件系统必须仍然可以通过一致的实现使用，结果是一个完全可移植的程序必须准备好处理输出和尾随的行长度限制 whitespace 输入。