Standardizing and Preserving CRLF

I have a form with a textarea that lets people enter multiple lines. The value of the string is passed to the action script as a hidden input, named "instructions."  The action script picks it up as $_REQUEST['instructions'].

I have this same code running on two domains, that are hosted on different servers, and I'm seeing a different behavior for each domain.  

On the first domain, selecting the Enter key after entering each line in the form textarea generates %D%A while the other domain generates %A.

The second difference is with the behavior of $_REQUEST['instructions'] .  Displaying the entire $_REQUEST array at the beginning of the action script with print_r shows a line feed after each line of the instructions parameter for both domains,   but if I pull the instructions parameter out with

            $instructions = $_REQUEST['instructions']

the first domain puts the %A into $instructions and the other domain leaves it out entirely, so that all the lines that were entered become one line. This is not good since I need to know in the action script how many lines were entered in the form.  If I change the second domain code to be

        $instructions = urlencode($_REQUEST['instructions']

then I get the %D%A in $instructions and I'm ok.

What am I fighting here?  Why does one domain insert %D%A for "Enter" while the other inserts just %A.  And why does


 preserve the CRLF characters in one case and throw them out in the other?

Thanks for any input.
Who is Participating?
Ray PaseurCommented:
End of line characters differ between operating systems.  In PHP, you can use the context-aware predefined constant PHP_EOL to represent and end of line.  You can use nl2br to turn end-of-lines into HTML <br> tags.
Ray PaseurCommented:
to represent and end of line  to represent an end of line
Scott MadeiraCommented:
Here is some detail on the different line end characters.  Only thing that I didn't like was he phrased the linux/unix section to sound like linux was like OS X when in fact OS X is like linux (linux was here first and Apple adopted a version of it to become OS X.)

To get consistent behavior in your data you may want to take you raw input in your $_REQUEST[] variable and do a conversion from LF to CRLF if that is all that is present in your input string.

You could check for the existence of CRLF and if it isn't there then do the conversion.  If it already contains the CRLF then don't do anything.
Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

stevaAuthor Commented:
Thanks.   One domain was hosted several months later and got put on a different plan and a different machine, but they're not different operating systems. They're both Linux and the servers are both Apache.  There must be a configuration constant somewhere that sets the default for what gets inserted for ENTER.  I'll talk to the hosting provider.

But no one commented on the $_REQUEST['instructions'] difference, where one machine brings in the end-of-line characters and the other needs urlencode to do it. This sounds like a configuration parameter in PHP.  Any thoughts there?

Ray PaseurCommented:
Check the man page here about the different mode modifiers.

I often find that I need to use trim() to process information that came from Windows machines.  My server is Linux, and it expects \n, but Windows puts in \r\n.  In some text editors you can set the end-of-line characters.  Since that is external client data (and by definition, tainted) you just have to deal with the variables.
stevaAuthor Commented:
Ok, I think I have this sorted out.  I can't reproduce the situation any more of one server putting \n into the textarea and another putting \r\n when I enter the Enter key.  They both insert \r\n.  And this doesn't seem to be a Linux  thing or a Windows thing.  It's an HTML thing. When you hit Enter while typing into an HTML textarea the characters 13 and 10 get inserted. Period.

The problem of $_REQUEST['instructions'] throwing away the eol characters is also my misunderstanding. The eol characters are there, you just don't see them in an echo, which replaces all white space with a single space.

I split the points for letting me bounce my thoughts off of you and seeing then that they didn't make any sense.
Ray PaseurCommented:
Wow, I did could not have imagined you were using echo to print the variables.  Try using var_dump() or print_r() while you are debugging.  It may help clarify what is really going on.  See also "view source" for more.

Anyway, thanks for the points and good luck! ~Ray
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.