I have a password protected text file and to make it password protected, i used a password protector script (which works great) but it required me to rename the text file to .php on my server. This went fine, however, when I open this text file in any browser on windows, i do not seeing any new lines (I used to see them)
I tried writing -"\n", "\r", "\r\n". I think it has to do with the browser thinking its a .php file i guess.
This is because the server is sending a different MIME type. It is now sending text/html (the default type returned by PHP) rather than text/plain.
Your browser is then expecting HTML. Line breaks are just like any other white space in HTML, so they are essentially meaningless for what you are trying to do.
You can use this to fix it:
header('Content-Type: text/plain');
Be sure to put that at the top of your code, or at least before you output anything.
This causes the server to send the MIME type you are expecting.
By default the output of PHP scripts are rendered as HTML, which means that whitespace is folded. If you want to change this back to text then you need to set the Content-Type header to "text/plain", either in the web server or via the header() function.
That's because the browser would see the content as html and in html a newline is just a whitespace
I am not sure if I understood your question properly, but in two cases there is a solution:
-You output the text: In this case, you have to use
<br>
-You want to write it with new lines in the file: Use the PHP-Constant
PHP_EOL
which means End-of-Line. This inserts always a correct break.
You need to use <br>, as html is being rendered in the browser.
Browsers uses HTML to format text (contained in html of course)
use <br> or <p>
Also considering your file is a .php it's a normal behaviour that your webserver will send it as text/html
Related
I'm presenting an RSS feed with this part of a PHP function:
echo "<li><a target='_blank' href='$item_link'>$item_title</a></li>";
Using an example, this output the following in HTML:
<li>
<a target='_blank' href='http://www.internationalaccountingbulletin.com/news/ey-shinnihon-will-audit-toshibas-corrected-accounts-while-under-investigation-4639900'>
EY ShinNihon will audit Toshiba’s corrected accounts… while under investigation
</a>
</li>
The titles have a large amount of discrepancy when it comes to the symbols used.
It outputs this
EY ShinNihon will audit Toshiba’s corrected accounts… while under investigation
as
EY ShinNihon will audit Toshiba’s corrected accounts… while under investigation
with apostrophes and ellipses (among others) being various symbols prefixed by â€.
How can I convert these symbols back to the originals in PHP?
Choose you character encoding to match your what you are editing check this site to learn more. http://htmlpurifier.org/docs/enduser-utf8.html
I took out the charset meta tag because I understood that it was bad practice for speed/SEO. When putting it back in, the problem is rectified, thank you. However, is there an alternative that is better practice? Setting headers via PHP - is that prefferable or worse?
So your problem was that you were outputting text in some encoding, without informing the browser what encoding you're giving it, and the browser therefore misinterpreting the text in the wrong encoding, leading to garbage characters. You always need to inform clients about what encoding you're sending them text in. The primary method to do that over HTTP is an HTTP Content-Type header. That way the browser is informed about the type of content it receives before it actually receives the content. Which is exactly as it should be.
HTML <meta> tags are only a fallback. You should include them, since they help specify the encoding of the HTML document should it ever be used outside of an HTTP context (e.g. you just open it from your hard disk, no HTTP involved, no HTTP Content-Type header, no way to specify the encoding... other than the HTML <meta> tag). But again, it should only be a fallback. And there's absolutely no issue with SEO or speed; wherever you got that from, it's pure FUD.
This will work for you.
first just use mb_convert_encoding() function it will wok for you.
$item_title = addslashes('this is your text');
$item_title = mb_convert_encoding($item_title, "HTML-ENTITIES", 'UTF-8');
In a webapp I place a <div id="xxx" contentEditable=true > for editing purpose. The encodeURIComponent(xxx.innerHTML) will be send via Ajax POST type to a server, where a PHP script creates a simple txt file from it which in turn can be downloaded from the user to store it locally or print it on screen. It works perfect so far, but … Yes, but, character encoding is a mess. All special characters like the german Ä are interpretated wrong. In this case as ä
I google for some days and I study PHP methods like iconv() and I know how to set up a browsers character encoding and also set a text editor for a correct correspondending decoding. But nothing helps, its still a messs, or becoming even weired.
So my question is : Where in this encoding/decoding roundtrip from the browser to a server and back to the browser I have to do what, to ensure that an Ä will still be an Ä ?
I answer my question, because it turns out to be another problem as stated above. The contenteditable is actually part of a section of html code. On the serverside with PHP I need to filter out the contenteditable text which I do via a DOMDocument like this:
$doc = new DOMDocument();
$doc->loadHTML($_POST["data"]);
then I access the elements and their textual content as usual.
Finally I save the text with
file_put_contents($txtFile, $plainText, LOCK_EX);
The saved text then was a mess as written above. Now it turns out that you need to tell the DOMDocument the character set wich loadHTML() has to interpretate. In this case UTF-8.
First I did it as recommended in PHP this way :
$doc = new DOMDocument('1.0', 'UTF-8');
But that doesn't help (I wonder). Then I found this answer in SO. And the final solution is this :
$doc->loadHTML('<?xml encoding="UTF-8">' . $_POST["data"]);
Though it works it is a trick. Finally the question is left over, how to do it the right way ? If somebedoy has the definite answer, he is very welcome.
You need to make sure that the content is encoded consistently throughout its roundtrip from user input to server-side storage and back to the browser again.
I would recommend using UTF-8. Check that your HTML document (which includes the contenteditable zone) is UTF-8 encoded, and that the XMLHttpRequest/Ajax request does not specify a different encoding when it sends the content to the server.
Check that your server-side application encodes the text file as UTF-8 also. And check that the HTTP response headers declare the file's encoding as UTF-8 when the file is requested and downloaded in the browser.
Somewhere along this path, the encoding differs, and that is what is causing the error. iconv converts between different encodings, which should not be necessary if everything is consistent.
Good luck!
I have a problem sending a file to client. I want to send plain text using header, but the out file, instead of having just my content, has two empty lines at the beginning. I don't know why this happens.
The variable I use is an xml format like this:
$section=<book>xbook<author>nmauthor</author></book>
I use this code to send the file.
header("Content-type:text/plain");
header("Content-Disposition: attachment;filename=file.xml");
header("Content-Transfer-Encoding:binary");
header("Pragma:no-cache");
header("Expires:0");
echo $section
I will be very grateful if someone helps me.
Could be many things... for one, if you have no space before your opening php tag, one thing to look at would be the file's encoding type. If you're using UTF-8, especially, make sure it is "without BOM" as that could cause your problem.
I'm trying to output a newline character in PHP that gets viewed in a web browser. I can only manage it by using the <br /> tag.
When I use \n, nothing occurs, so what is the benefit of using \n? Also what is the benefit of PHP_EOL? When I concatenate it to a string, just a space is printed not a newline.
A web browser interprets the output of a PHP program as HTML, so \n and \r\n will not appear to do anything, just like inserting a newline in an HTML file. On the other hand, <br /> makes a new line in the interpreted HTML (hence "line BReak"). Therefore, <br /> will make new lines, whereas \r\n will not do anything.
The PHP_EOL define is correct for the platform that you are on. So on windows PHP_EOL is \r\n on MAC it's \r on Linux, it's \n. Whereas <br /> or <br> is the HTML markup for line brake. If you're new to HTML & PHP, it's better to get a grasp of HTML first, then worry about PHP. Or start reading some source code, and run other peoples source code to see how they have done it. It will make you're code better just by copying their style. (Most of the time.)
When you are using PHP to make a web app, there are a few layers involved:
Your PHP code, which outputs some data to
a web server, which transmits the data over the network to
a web browser, which parses the data and displays it on the screen.
Note that in the above, it is just data that is being passed along. In your case, that data is HTML, but it could just as easily be plain text or even a PNG formatted image. (This is one reason why you send a Content-Type: header, to specify the format of your data.)
Because it is so often used for HTML, PHP has a lot of HTML-specific features, but that's not the only format it can output. So, while a newline character is not always useful for HTML, is is useful:
if you want to format the HTML you are generating, not for the web browser, but for another person to be able to read;
if you want to generate plain text or another format where newline characters do matter.
PHP_EOL is useful when you're writing data to a file, example a log file. It will create line breaks specific to your platform.
For some reason, I want to serve my robots.txt via a PHP script. I have setup apache so that the robots.txt file request (infact all file requests) come to a single PHP script.
The code I am using to render robots.txt is:
echo "User-agent: wget\n";
echo "Disallow: /\n";
However, it is not processing the newlines. How to server robots.txt correctly, so search engines (or any client) see it properly? Do I have to send some special headers for txt files?
EDIT 1:
Now I have the following code:
header("Content-Type: text/plain");
echo "User-agent: wget\n";
echo "Disallow: /\n";
which still does not display newlines (see http://sarcastic-quotes.com/robots.txt ).
EDIT 2:
Some people mentioned its just fine and not displayed in browser. Was just curious how does this one display correctly: http://en.wikipedia.org/robots.txt
EDIT 3:
I downloaded both mine and wikipedia's through wget, and see this:
$ file en.wikipedia.org/robots.txt
en.wikipedia.org/robots.txt: UTF-8 Unicode English text
$ file sarcastic-quotes.com/robots.txt
sarcastic-quotes.com/robots.txt: ASCII text
FINAL SUMMARY:
Main issue was I was not setting the header. However, there is another internal bug, which is making the Content-Type as html. (this is because my request is actually served through an internal proxy but thats another issue).
Some comments that browsers don't display newline were only half-correct -> modern browsers correctly display newline if content-type is text/plain. I am selecting the answer that closely matched the real problem and was void of the above slightly misleading misconception :). Thanks everyone for the help and your time!
thanks
JP
Yes, you forgot to set the Content Type of your output to text/plain:
header("Content-Type: text/plain");
Your output is probably being sent as HTML, where a newline is truncated into a space, and to actually display a newline, you would need the <br /> tag.
header('Content-Type: text/plain') is correct.
You must call this method before anything is written to your output, including white space. Check for whitespace before your opening <?php.
If your Content-Type header has been set to text/plain, no browser in its right mind would collapse whitespace. That behaviour is exclusive to HTML and similar formats.
I'm sure you have your reasons, but as a rule, serving static content through PHP uses unnecessary server resources. Every hit to PHP is typically a new process spawn and a few megs of memory. You can use apache config directives to point to different robots files based on headers like User-Agent - I'd be looking into that.
It's likely that search engines ignore the Content-Type header, so this shouldn't be an issue anyway.
Hope this helps.
-n
<?php header("Content-Type: text/plain"); ?>
User-agent: wget
Disallow: /
BTW, the newlines are there just fine. They're just not displayed in a browser. Browsers collapse all whitespace, including newlines, to a single space.
deceze$ curl http://sarcastic-quotes.com/robots.txt
User-agent: wget
Disallow: /
i was having a similar issue and either "\n" nor PHP_EOL worked. I finally used:
header('Content-Disposition: attachment; filename="plaintext.txt"');
header("Content-Type: text/plain");
echo "some data";
echo chr(13).chr(10);
The echo of BOTH characters did the trick.
Hope it helps someone.
Bye
anankin
You must set the content type of the document you are serving. In the case of a .txt text file:
header("Content-Type: text/plain");
The IANA has information about some of the more popular MIME (content) types.
If you are using echo, then use <br> for new lines. the printf function is what uses \n.
In your case, use printf because you are not using HTML. I believe this is the proper way to do this, along with setting the MIME type to text.