CRLF vs LF for a new line in your php code

[chadmg]

I was trying to replace all "\n\n" from a text field in a mysql database with "</p>\n<p>" when I realized that mysql (or PHP orApache, I'm not sure) sets the end line character as CR/LF. So I have two questions:

1. Is this a MySQL, PHP, or Apache setting to change what the end line character is? I want to make sure it might not sometimes just be CR or just LF. If someone enters text in a text field using Unix or a Mac, will the characters be stored in the database differently?

2. I use EditPlus as a source viewer and it never interpreted the "\n" correctly as a new line. It just gave me a block. When I set the "Check invalid CR/LF, null character when loading" option, it would tell me that there were invalid CR/LF characters and asked me if I would like to convert them to Windows format. My question is, should I use "\r\n" to end my lines in my php code instead of just "\n". I am a windows user and would therefore always want it to be \r\n right? Do any of you do this or do you all just use \n?

[jollymcfats]

Browsers are supposed to send line terminators as \r\n. You should expect to see this come in from any textarea.

If you want to guard against unexpected line terminators (e.g. bare \n), use regular expressions like

/\r?\n\r?\n/

instead of

/\n\n/

for your

<p>

transformations.

As far as your PHP source code goes, use the native settings on your OS. There's no advantage to doing anything differently.

[edited by: jollymcfats at 5:10 pm (utc) on Sep. 24, 2004]

[jezra]

It is the users computer that is setting the line endings. A quick str_replace can get the text formatted nicely for the web. As far as code editing goes, use \r\n if it looks good in your editor of choice. Really it is just a personal preference. The only headache with line endings that I have had was with using the file() function with an uploaded file from Mac OS9 which uses \r as the line endings and file() read it all as only one line.

[StupidScript]

\r\n is used in DOS-mode ASCII.

Unix ASCII uses \n.

If your server is Unix/Linux (Posix) and your development environment is Win, your must transfer text files in ASCII FTP mode, not binary. Transferring in ASCII mode will translate between DOS and Unix ASCII. This includes .PHP files and .SQL files you will use for MySQL.

If both your server and development environments are Posix, you should use binary FTP mode for everything, as no translation between DOS ASCII and Unix ASCII is necessary.

The user's client environment does not make a difference to the web application, as it uses web standards and the apps on your server. So it will use \n automatically from a Posix server.

Have you tried EditPad Classic? It does not offer regexp search and replace, like EditPad Pro, but it can handle the assignment you outlined with ease. Save it to a .SQL file and load it into your db.

Use the line ending format that is appropriate for your server, and make sure you upload using the proper mode to accomplish the translation.

[chadmg]

Thanks for the replies. I think I will end all of my php printing with $n and I'll set $n globally to be "\r\n" now and I can change it later as needed.

There is one last thing I'm still confused about though. If you transfer text files via ftp from a Windows to a Unix environment, you said I should use ASCII mode so that the line feed charachter is adjusted to the new environment. What benefit does this give me? Will this mean that when I view the file in Unix the line feed will be correct? I never view the file in Unix, so why should I care? And if I did transfer it in ASCII mode, when I view the file with a browser and then view the source, will the line feed character be correct for the platform that the browser is on, or will it be the line feed character of the server? Thanks again.

[jollymcfats]

There is one last thing I'm still confused about though. If you transfer text files via ftp from a Windows to a Unix environment, you said I should use ASCII mode so that the line feed charachter is adjusted to the new environment. What benefit does this give me? Will this mean that when I view the file in Unix the line feed will be correct? I never view the file in Unix, so why should I care?

You may never view the file, but the system will. Apache, PHP, whatever. Transfering in ASCII mode converts the line endings to the OS's native format. Your FTP program probably can (or does) automatically transfer text files in ASCII mode.

And if I did transfer it in ASCII mode, when I view the file with a browser and then view the source, will the line feed character be correct for the platform that the browser is on, or will it be the line feed character of the server? Thanks again.

The browser will correct the line feeds to the client's native format.

[chadmg]

Awesome. Thank you jollymcfats. One last question for those who ftp all of your files. Do you set up one ftp connection in ascii mode for your text files and one in binary for other files and switch between them? I wish there was a less cumbersome way.

[chadmg]

Nevermind, my ftp program forces files of certain types to be transfered in ascii mode. Thanks again for everyones help.

[StupidScript]

chadmg, if your FTP program does not recognize ALL of the file types you need to transfer as ASCII, you can usually add extensions in some part of the "preferences" or "options" for a session.

You would definitely notice the line endings if you uploaded a shell script you wanted to run using cron or some server-side process. If the shell script (not PHP or Javascript) has \r\n endings, then it will error with (at least) a "bad interpreter" message.