Question

众所周知，类Unix系统使用LF个字符表示换行符，而Windows使用CR+LF。

但是，当我在Windows PC上从本地HTML文件测试此代码时，似乎JS将所有换行视为以LF分隔。这是正确的假设吗？

var string = `
    foo




    bar
`;

// There should be only one blank line between foo and bar.

// \n - Works
// string = string.replace(/^(\s*\n){2,}/gm, '\n');

// \r\n - Doesn't work
string = string.replace(/^(\s*\r\n){2,}/gm, '\r\n');

alert(string);

// That is, it seems that JS treat all newlines as separated with 
// `LF` instead of `CR+LF`?

Answer 1

我想我找到了解释。

您正在使用ES6 Template Literal来构建多行字符串。

根据ECMAScript specs a

..模板文字组件被解释为Unicode序列代码点。文字组件的模板值（TV）是用代码单位值（SV，11.8.4）来描述模板文字组件的各个部分。作为其中的一部分进程中，模板组件中的一些Unicode代码点是被解释为具有数学值（MV，11.8.3）。在确定电视时，转义序列被UTF-16代码取代由转义序列表示的Unicode代码点的单位。模板原始值（TRV）类似于带有的模板值 TRVs转义序列的差异按字面解释。

在此之下，定义为：

LineTerminatorSequence ::＆lt; LF＆gt;的TRV是代码单元0x000A（LINE   FEED）。
  LineTerminatorSequence ::＆lt; CR＆gt;的TRV是代码单元0x000A（LINE FEED）。

我的解释是，您始终只获取换行符 - 无论使用模板文字时是否使用特定于操作系统的新行定义。

最后，在JavaScript's regular expressions a

\ n匹配换行符（U + 000A）。

描述了观察到的行为。

但是，如果您定义字符串文字'\r\n'或从包含特定于操作系统的新行的文件流等中读取文本，则必须处理它。

这样的混淆可能会导致Google's JavaScript Style Guide not to use template literals中的建议。

以下是一些演示模板文字行为的测试：

`a
b`.split('')
  .map(function (char) {
    console.log(char.charCodeAt(0));
  });

(String.raw`a
b`).split('')
  .map(function (char) {
    console.log(char.charCodeAt(0));
  });
  
 'a\r\nb'.split('')
  .map(function (char) {
    console.log(char.charCodeAt(0));
  });
  
"a\
b".split('')
  .map(function (char) {
    console.log(char.charCodeAt(0));
  });

解释结果：
char（97）= a，char（98）= b
char（10）= \n，char（13）= \r

Answer 2

您可以使用正则表达式：/^\s*[\r\n]/gm

代码示例：

let string = `
    foo




    bar
`;

string = string.replace(/^\s*[\r\n]/gm, '\r\n');

console.log(string);

JS字符串中的行结尾（也称为Newlines）

2 个答案: