Re: Form Post to different domain

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Feb 16, 2012 at 5:02 PM, Daniel Brown <danbrown@xxxxxxx> wrote:
> On Thu, Feb 16, 2012 at 10:57, Matijn Woudt <tijnema@xxxxxxxxx> wrote:
>>
>> What if the system PHP is running on not the same one as the one that
>> is going to read the plain-text/CSV/.. files? I don't think it is good
>> practice to use it when writing to files. I often write files on a
>> Linux server that people are going to read on a Windows PC.
>
>    Then what is the difference between PHP_EOL and forcing \n?  It's
> still going to use POSIX-style EOLs, but now you've taken away the
> benefit of the compatibility.

I'm not saying you should force \n then, but you might want to decide
what to force depending on who will be using it, so in case a windows
user is going to read it, then you set \r\n, otherwise you select
\n.You could even try to detect that based on a browser identification
string.

>
>> Apart from that, most software written in the last 5-10 years will
>> happily read files with either \n or \r\n line endings. I'm not really
>> sure about Win XP for example, but if it would have a problem with the
>> Linux \n endings, it might even be better to *always*  use \r\n line
>> endings (except where standards require it), as I haven't seen a
>> single Linux application since I started using it (about 9 years ago)
>> that was not able to read a file with \r\n based line endings.
>
>    You may want to check again.  Ever see ^M at the end of your
> lines?  Or, in vim, notice how it says it's a DOS file?

I have seen them, but only in files which had mixed line endings,
which should of course never be used. Vim does indeed notice it's a
'dos' file, but it's merely detecting that the file has \r\n line
endings and that it should add those too. I don't consider that bad.

>
>> Even better, go Unicode. Unicode specifies that there are 8 ways to
>> make a new line, and they should all be accepted. However, the pretty
>> uncommon NEL, LS and PS are not supported in many applications.
>> (though CR, LF and CRLF are).
>
>    Nothing you've suggested is necessarily bad, but more to the
> point, it doesn't come close to invalidating the benefit of PHP_EOL.

I'm not saying using PHP_EOL is bad, but I disagree with using it
always as a habit. If line endings matter, then you need to make
decisions based on that, and don't depend on it being automatically OK
if PHP_EOL is used.

- Matijn

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux