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.
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
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