Update: my original test involving copy/pasting from a text file into the browser was flawed. I created a new test in JavaScript which verified that carriage return \r is in fact being matched.
The following code logs ['\r', '\r', '\r']
to the console, which verifies that the \r
is being matched:
<script>
const CarriageReturn = String.fromCharCode(13); // char code for carriage return is 13
const str = CarriageReturn + CarriageReturn + CarriageReturn;
const matches = str.match(/\r/g);
console.log(matches); // this will output ['\r', '\r', '\r']
</script>
Original Question
The common method suggested by numerous StackOverflow answers and articles across the internet to match a line break in regular expressions is to use the ubiquitous token [\r\n]
. It is supposedly to ensure compatibility with Windows systems, since Windows uses the carriage return \r
and line feed \n
together to make a new line, as opposed to just the line feed \n
for UNIX based operating system such as Linux or Mac.
I'm beginning to think JavaScript ignores this distinction and just treats every line break as \n
.
Today, I did an experiment where I created a text file with 10 carriage returns, opened up the text file, then copy/pasted the carriage returns into the regular expression tester at https://regex101.com.
When I tested all those carriage returns against the simple regular expression \r
, nothing matched. However, using the alternative \n
matched all 10 carriage returns.
So my question is, based on my experiment, is it safe to just write \n
instead of [\r\n]
when matching line breaks in JavaScript?