Carriage Returns and Line Feeds

Shadow2531

[H]ard|Gawd
Joined
Jun 13, 2003
Messages
1,670
I'm messing with C++ cgi on Windows running on Apache2. I need to determine the correct way to handle line breaks. For that, I need to know how other OSs handle them. (Don't have a mac and don't have Linux anymore).

Here's what I know:

%0D = CR - Line Feed
%0A = LF - Carriage Return

Windows Format = CRLF
Mac Format = CR
*nix format = LF

Opera, Firefox and IE on Windows all submit %0D%0A (CRLF) to my app unless the enctype for the form is set to multipart/form-data. (I'm not worried about multipart/form-data and uploading files at the moment.)

When that decoded POST/GET data is printed to a page or file via my cgi app, the line breaks end up in the form CRCRLF. This happens because each LF in CRLF gets converted to CRLF and you end up with CRCRLF. GCC and python on Windows do that. PHP and Perl on Windows just have CRLF.

Here's a test to show you what I mean.

Code:
#include <iostream>
#include <fstream>
#include <cstdlib>

using namespace std;

int main() {
    ofstream createfile("test.txt");
    if (!createfile) {
        exit(EXIT_FAILURE);
    }
    createfile << static_cast<char>(0x0A);
}

View test.txt in a hex editor after you run the program. You will notice 2 hex values. 0D and 0A, but only 0A was supposed to be written to the file. (I know with binary mode, I can make it only write the 0A to the file.) That's what happens on Windows at least.

Currently, I have my decode function ignore %0D and convert each %0A to \n . Doing it that way, the line break format ends up being CRLF.

What I want to know:

What format are the line breaks, when submitted from forms(text areas) by Linux and Mac browsers? Does Safari submit just %0D and does Opera on Linux submit just %0A or are all browsers supposed to submit %0D%0A?

On Apache2 (on Linux and mac), what do PERL,PHP,PYTHON do cgi-wise and what does GCC do with the example above? Do they stick with the format for the OS?

Browsers seem to render pages in whatever format without a problem, but I'd still like to know how Linux and Mac behave.

Thanks
 
In "theory" the behavior would be to convert from the html encoded newline to whatever the line feed semantics are for the local platform. In C++ this would likely have to be done manually, but in PHP and Perl I'd think there would be a library function to do that.

In "practice" I don't know off hand if the decode functions on those languages do the newline conversion.
 
Here's what I've come up with.

On windows

\n = %0D%0A = CRLF
\r = %0D = CR

When 0x0A is converted to a char, it is converted to \n because there is no escape sequence for just 0x0A, which is
why %0D%0A turns out to be CRCRLF after its decoded. MinGW at least behaves this way with streams in ASCII mode.

On linux (cygwin with unix format set)

\n = %0A = LF
\r = %0D = CR

(gcc does not do any conversion and leaves them alone)

on mac (guessing)
\n = %0D = CR
\r = %0A = LF

Since all browsers are supposed to submit %0D%0A (according to W3C), when decoding the data, I
should convert all instances of %0D%0A to \n. Then the app will produce the
proper line break for the OS that the app is running on.

I just need confirmation that popular linux and mac browsers actually do follow
the W3C recommendation of submitting %0D%0A. If so, then I'm all set.

Plus I need confirmation that the \r on mac = LF = %0A
 
Back
Top