What mode of UltraEdit shows me the "raw" line endings that are in the file without making any changes to them?

herrblint · Apr 13, 2019#12019-04-13T12:20+00:00

I am working with some exported data, and one of the files contains a notes field, and users have been cutting and pasting emails via the user interface and saving them to that field. The notes field in a given record may thus contain multiple paragraphs (to, from, subject, body, signatures at the bottom, nested email chains, etc.) that employ a mix of line ending characters and character sequences: sometimes a CR, sometimes a LF, sometimes a CRLF pair.

I need to be able to see exactly what line endings are there, without the editor normalizing things for me according to some Windows, Unix, or Macintosh mode setting somewhere.

What settings do I need in UltraEdit for it to show me the file contents "raw"? Not in hex, just not changing what it finds to make things consistent.

Thanks.

Mofi · Apr 13, 2019#22019-04-13T14:30+00:00

Open Advanced - Settings or Configuration - File handling - DOS/Unix/Mac handling and configure

DOS for Default file type for new files (does not matter here);
Never prompt to convert files to DOS format for Unix/Max file detection/conversion;
uncheck Only recognize DOS terminated lines (CR/LF) as new lines for editing;
uncheck Save file as input format (Unix/Mac/DOS);
uncheck Status bar shows original line terminator format (on disk) (does not matter here).

Open the file and enable Show line endings.

CRLF line endings are displayed with ¶ and LF line endings with ¬. A carriage return without a line-feed is not interpreted in this mode as line ending. The carriage return is interpreted as normal character which means it is displayed according to used font. Most Microsoft fonts don't display anything for a carriage return interpreted as normal character. The fonts Cambria and Candara display a carriage return like a space character, the font Modern with a dot and the bitmap font Dina not installed by default on Windows as rectangle. The Perl regular expression search \r(?!\n) can be used to find a carriage return with next character being not a line-feed even if the used font is not displaying it with a glyph. I recommend to replace every carriage return with next character not being a line-feed by a line-feed to have finally at least only two types of line endings in file. This does not change the file size or the individual offsets of blocks in text file.

There is no configuration on which a text file containing Mac and Unix and DOS line endings can be viewed and edited in text editing mode with all three line ending types interpreted as line endings.

I have attached a very small example file for testing purposes.

If you know the programmer being responsible for the code processing the text of the edit field on which users could paste text without standardizing the line endings before saving them into a database or files, I recommend to contact this programmer and ask what to do now with the text data containing a mixture of line ending types because of the programmer's omission to standardize the line endings. Nothing is more useful on learning how to code something right than when a programmer must carry the consequences of his/her slackness in code writing himself/herself.