10
I’ve been informed that PHP_EOL
sets the end of the line, ok.
But why should I write.
echo 'a'.'<br>'.PHP_EOL;
echo 'b';
If the
echo 'a'.'<br>';
echo 'b';
It has the same effect, what difference it makes to use the PHP_EOL
10
I’ve been informed that PHP_EOL
sets the end of the line, ok.
But why should I write.
echo 'a'.'<br>'.PHP_EOL;
echo 'b';
If the
echo 'a'.'<br>';
echo 'b';
It has the same effect, what difference it makes to use the PHP_EOL
12
It is not what you should use, you use if you want and need. First, you will only use it if you want to jump a line in the generated text. Is that what you want there? You know why you’re gonna jump the line there?
This line jump has to do with the generated text, not with HTML. o <br>
it has nothing to do with that, actually this code is like this, but jump line there only changes the layout of the code and not of the page it will draw. Do not forget that you are generating a text that is a code to be sent to a browser. This line jump you’re talking about will only affect this text, not what it will render.
The first code will generate in the browser something like that:
a<br>
b
The second will look like this in the browser:
a<br>b
I put in the Github for future reference.
But at the time you assemble the page and shown the two will show exactly the same thing (save some bug in the browser) because to render the page what is worth is only the <br>
, and not the line break.
If you really want to skip line you can use a pure skip line character or you can use this defined constant that will use the appropriate character to skip line according to the operating system your code is running. But since we are talking about a text generated for HTML this has no relevance, and actually does not even make sense since if it is running on Linux, for example, and its generated HTML is for a browser running on Windows, it generated a line break in a way that Windows does not understand correctly (it may be that the browser do something to manage it).
For this case a \n
in place of PHP_EOL
should work well. The PHP_EOL
makes more sense when going to create files that need to be shown on a specific platform but you don’t know which one it will be yet. The browser there is no way you can control, when you send the HTML to the client via HTTP server you have to choose a way, then it is usually too late, unless you try to detect which platform the browser who made the request is running (not reliable), but then has to do the opposite of what the PHP_EOL
do, you would have to control that.
The summary of all this is that you don’t need to use this constant, I don’t know the context, but it seems that someone has steered you wrong, at least for this context.
I assumed you know what concatenation is string.
Read the comments that have relevant information about why this exists and when it should be used for real. It is rare to be needed in PHP and usually only when it is used for things that is not normal that people do.
You can read more on What is the difference between Carriage Return and line feed?.
-1
The alternatives below worked similarly in the environment Windows
, already to another OS
, LF+CR might not have the same result.
echo "Pula linha 1", PHP_EOL;
echo "Pula linha 2" . PHP_EOL;
echo "Pula linha 3" . chr(10) . chr(13);
Note: Chr(10) = LF(line feed), Chr(13) = CR (Carriage Return). See ascii table :https://web.fe.up.pt/~ee96100/project/Table%20ascii.htm
Browser other questions tagged php string
You are not signed in. Login or sign up in order to post.
First it is important you understand that the
.
is a thing and thePHP_EOL
is another. The.
is just an operator to concatenate two strings. In this case,PHP_EOL
is one of them, more precisely it is a constant that contains a string. The exact string it contains depends on the operating system. Now (re)read Maniero’s reply :)– bfavaretto
It does not have the same effect, it only looks the same in HTML, if the
content-type:
fortext/plain
BR will not be a tag, it will be text and without PHP_EOL there will be no line break, leaving everything in one line only, however PHP_EOL is a little unnecessary in this your example, both apostrophes and quotation marks support having real line breaks inside and to facilitate you can use heredoc.– Guilherme Nascimento
@bfavaretto, thank you very much for the answer, the "." it was my mistake, at the time of copying, the code of the editor, it ended up coming together, again thank you very much.
– Jonathan Matheus
But now you’ve included the
;
of the end which is also something else :D– bfavaretto
Almost never should. PHP_EOL is not "end of the line". It is only the "end of the OS line in which PHP is running at that moment". Neither more nor less. If using in email is wrong, if using in HTTP is wrong, if using in bank remittance is wrong, and the list of where it is wrong to use is immense. You should only use in the minority of situations where the break is the same as the OS default in which the script is running. The examples I gave (and the vast majority of the files) have RFC-defined format or specific documentation, and should not use breaks that vary by environment.
– Bacco
An addendum to @Bacco’s comment just to get a sense of how it differs, the
var_dump(PHP_EOL);
in Windows returns this\r\n
in Unix-like environments "usually" returns this\n
(of course not exactly what you see, this is the representation) and probably if PHP ran on other systems (I don’t know if it runs) exist (did they exist? ) those who used to\025
, then if theoretically you use PHP_EOL for web pages and the server uses\025
absolutely everything would break/fail.– Guilherme Nascimento
@bfavaretto Eita truth, obliging, not observed that.
– Jonathan Matheus