steva
asked on
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['instr
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
$_REQUEST['instructions']
preserve the CRLF characters in one case and throw them out in the other?
Thanks for any input.
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['instr
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
$_REQUEST['instructions']
preserve the CRLF characters in one case and throw them out in the other?
Thanks for any input.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Ray Paseur
to represent and end of line to represent an end of line
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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?
Thanks.
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?
Thanks.
Check the man page here about the different mode modifiers.
http://php.net/manual/en/function.fopen.php
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.
http://php.net/manual/en/function.fopen.php
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.
ASKER
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.
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.
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
Anyway, thanks for the points and good luck! ~Ray