With View - Show Line Endings
(UE v13.10 and later) respectively View - Show Spaces/Tabs
(UE < v13.10) following is displayed for the various line termination types:
The paragraph sign ¶
(decimal: 182, hex.: 0xB6) is used for DOS line terminations which is carriage return plus linefeed.
The not sign ¬
(decimal: 172, hex.: 0xAC) is used for UNIX line terminations which is a linefeed only.
The plus-minus sign ±
(decimal: 177, hex.: 0xB1) is used for MAC line terminations which is a carriage return only.
The symbols displayed depend on the font set and the selected script (code page). That's the reason why I have added also the decimal and hexadecimal value of the characters because the symbols can be different when not using a font like Courier New and a different script than Western (ANSI 1252, Latin I).Carriage return
is often abbreviated with CR
and in UltraEdit regular expression and in non regular expression Finds/Replaces with ^r
is often abbreviated with LF
and in UltraEdit regular expression and in non regular expression Finds/Replaces with ^n
can be used for the pair carriage return plus linefeed
in UltraEdit regular expression and in non regular expression Finds/Replaces. In Unix regular expressions \p
must be used because no separate definition for this character sequence.
Carriage return only is often used by Microsoft Office applications for line breaks within a paragraph or table cell. Line break is not equal end of paragraph in word processing applications. A line break can be inserted within a paragraph in MS Word with Shift+Return.
In MS Excel tables a line break inserted within a cell with Alt+Return results on saving the table as CSV file in having a carriage return without a linefeed within a value. Copying table data from MS Word or MS Excel are copied always in CSV format into the text version of the clipboard.
According to CSV specification it is absolutely no problem if a field value contains CR, LF or CRLF for a line break if the field value is enclosed in double quotes. That does not make the CSV invalid according to CSV specifications. But many, really many programmers have implemented CSV file reading poorly and interpret every line terminating character as end of data row. And also many programmers have coded the export of CSV files also poorly because field values with line terminating characters are not enclosed in double quotes (and quotes within such values escaped with an additional double quote character).
For details on CSV see Wikipedia article Comma-separated values