I have a weird issue where my PHP files have lost their line breaks and appear to have weird box/rectangle shaped characters in them. I have no clue how to fix them and they are interfering with my website.
What editor are you using? That is a symptom of trying to edit Unix format files in MS notepad (amongst other combinations).
Your files have most likely been converted by an FTP transaction of uploading them to the remote server (because the client correctly used TYPE A) and not converted back when you retrieved them (because it incorrectly used TYPE I).
Either get a better editor (like Notepad++ or EditPadPro) or force your FTP client into ASCII mode (TYPE A).
FYI, on *nix a line ending character is LF only (\n), on Windoze it is CRLF (\r\n) and on Mac it is CR only (\r).
By the way, this can still occasionally happen in Notepad++ if you use Notepad++'s FTP plugin and do not set the FTP plugin (nppftp) settings to ASCII. That is why I found this post.
You are likely seeing the difference between Windows and Unix line breaks.
Windows uses CR+LF whereas Unix-based systems simply use LF.
See also: http://en.wikipedia.org/wiki/Line_break_(computing)#Representations
PHP will parse both, so I doubt that is the reason your code isn't running. Of course, with no file posted, this is only a best guess (and a common issue).
Yes, as Brad said, you probably have the wrong line breaks. Assuming that you're on a *nix system, run dos2unix <filename>, and that will replace the Windows endline \r\n with the *nix endline character of \n.
You just enabled "Show Linebreaks" or "Show special characters" in your editors menu options. So now, rather than an invisible "\n" or "\r\n" you are seeing a representation of them.
Related
I have strange problem in every PHP page, at end of every response there is some special character, that is not related to PHP script, I test it with just <?php phpinfo();?> page that is there.
They are like this
�
But that is not in 404 static page response, I think that is related to php config over version or, not Apache config, but I can’t find what cause this.
Bad situation is that it cause every AJAX/Json response fails, because change structure of response data by adding special character at end of every response
What cause this problem and how can solve it?
According to this answer on Server Fault, the issue is problems with mod_gzip:
The problem is being caused by mod_gzip and the fact that you do not
have a final newline in your files. The newline problem is caused by
serving Windows-encoded files on a Unix system.
This might be connected to line ending differences between Windows & Unix machines. I actually answered a similar question earlier today. Specifically:
Different operating systems use different characters to mark the end
of line:
Unix / Linux / OS X uses LF (line feed, '\n', 0x0A)
Macs prior to OS X use CR (carriage return, '\r', 0x0D)
Windows / DOS uses CR+LF (carriage return followed by line feed, '\r\n', 0x0D0A)
If you are on a Linux server you can install the dos2unix tool to convert the PHP files in question to properly formatted Linux text files.
If you are on Ubuntu—for example—just run this command to install it:
sudo apt-get install dos2unix
Then you can run it like this on a file:
dos2unix some_kind_of_file.php
Which would take some_kind_of_file.php and convert it in place from Windows line endings to Unix line endings. More details here.
I have recently bought a new MacBook Pro. Before I had my MacBook Pro I was working on a website on my desktop computer. And now I want to transfer this code to my new MacBook Pro.
The problem is that when I transfered the code (I put it on Dropbox and simply downloaded it on my MacBook Pro) I started to see lots of error messages in my PHP code.
The error message I”m receiving is:
Warning: Cannot modify header information - headers already sent by (output started at /some/file.php:1) in /some/file.php on line 23
I have done some research on this and it seems that this error is most frequently caused by a new line, simple whitespace or any output before the <?php sign. I have looked through all the places where I have cookies that are being sent in the HTTP request and also where I'm using the header() function. I haven’t detected any output or whitespace that possibly could interfere and cause this problem.
Noteworthy is that the error always says that the output is started at line 1. Which got me thinking if there is some kind of coding differences in the way that the Mac OS X and Windows operating systems handle new lines or white spaces? Or could the Dropbox transfer messed something up?
The code on one of the sites(login.php) which produces the error:
<?php
include "mysql_database.php";
login();
$id = $_SESSION['Loggedin'];
setcookie("login", $id, (time()+60*60*24*30));
header('Location: ' . $_SERVER['HTTP_REFERER']);
?>
login function:
function login() {
$connection = connecttodatabase();
$pass = "";
$user = "";
$query = "";
if (isset($_POST['user']) && $_POST['user'] != null) {
$user = $_POST['user'];
if (isset($_POST['pass']) && $_POST['pass'] != null) {
$pass = md5($_POST['pass']);
$query = "SELECT ID FROM Anvandare WHERE Nickname='$user' AND Password ='$pass'";
}
}
if ($query != "") {
$id = $connection->query($query);
$id = mysqli_fetch_assoc($id);
$id = $id['ID'];
$_SESSION['Loggedin'] = $id;
}
closeconnection($connection);
}
Complete error:
Warning: Cannot modify header information - headers already sent by (output started at /Users/name/GitHub/website/login.php:1) in /Users/namn/GitHub/website/login.php on line 9
Check if there are spaces in front of your php opening tag. Also try resaving the file from notepad++ using the windows (crlr) line endings. (Edit > EOL Conversion > Windows format)
Noteworthy is that the error always says that the output is started at
line 1. Which got me thinking if there is some kind of coding
differences in the way that the Mac OS X and Windows operating systems
handle new lines or white spaces? Or could the Dropbox transfer messed
something up?
Don’t redo your code or worry about the header() calls or even the cookie stuff. That is not the issue.
The issue is that Windows line endings are different from Mac line endings. More details here.
Different operating systems use different characters to mark the end
of line:
Unix / Linux / OS X uses LF (line feed, '\n', 0x0A)
Macs prior to OS X use CR (carriage return, '\r', 0x0D)
Windows / DOS uses CR+LF (carriage return followed by line feed, '\r\n', 0x0D0A)
And what happens in cases like this is the formatting of the page causes the PHP parser in Apache to choke on the files. Possibly sending content to the browser before you intend to when making header() calls or setting cookies. Meaning technically the screwed up line endings force a “header” to be sent because the file itself is outputting data to the browser inadvertently.
The solution might be to avoid using Dropbox & just copy the files onto a flash drive & transfer it that way. That’s an idea but I am not convinced that Dropbox was the culprit in this. Meaning the issue might still exist even if you copy the files to a flash drive.
Or if that does not work, do as the linked to article suggests & download a good text editing tool like TextWrangler. Just load the files into TextWrangler & then manually change the line endings so they are Mac (CR) and resave the files.
Another long-term solution to this issue might be to use a version control system like git coupled with an account on GitHub to manage your code. The benefit is by pushing code to GitHub & pulling code from GitHub, the process itself will deal with cross-platform line ending headaches. And you don’t need to worry about inadvertent oddities caused by a straight copy of files to a service like DropBox.
But again, pretty convinced this has nothing to do with Dropbox. It’s all about Windows line endings being different from Mac OS X line endings.
EDIT: There are some interesting ideas on how to handle the bulk conversion of Windows line endings to Mac OS X line endings on Mac OS X Hints. The most intrguing one is the use of zip and unzip to facilitate the process. I have not tried this, so caveat emptor! But it does sound like something worth testing since the last line states, BTW, it's the "-a" flag to unzip, that is causing the ascii files to have their lines endings converted.:
I've always used the following (in a file named fixascii):
#!/bin/sh
zip -qr foo.zip "$#" && unzip -aqo foo.zip && rm foo.zip
And then execute it as:
fixascii [files or directories to convert]
Which has the benefit over most of these other commands in that you
can point it with impunity at an entire directory tree and it will
process all the files in it and not corrupt any binaries that may
happen to have a string of bits in them that look like a line-ending.
I've seen too many times where someone corrupted a ton of images and
other binaries, when trying to fix line-endings on text files using
dos2unix or tr in combination with find but failed to ensure that only
text files were processed. Unzip figure out which files are ascii,
converts them, and leaves the binaries alone.
BTW, it's the "-a" flag to unzip, that is causing the ascii files to
have their lines endings converted.
And then looking in the official man page for unzip under the -a (convert text files) option; emphasis is mine:
Ordinarily all files are extracted exactly as
they are stored (as ''binary'' files). The -a option causes files
identified by zip as text files (those with the 't' label in zipinfo
listings, rather than 'b') to be automatically extracted as
such, converting line endings, end-of-file characters and the
character set itself as necessary. (For example, Unix files use
line feeds (LFs) for end-of-line (EOL) and have no end-of-file (EOF)
marker; Macintoshes use carriage returns (CRs) for EOLs; and most
PC operating systems use CR+LF for EOLs and control-Z for EOF. In
addition, IBM mainframes and the Michigan Terminal System use
EBCDIC rather than the more common ASCII character set, and NT
supports Unicode.) Note that zip's identification of text files
is by no means perfect; some ''text'' files may actually be binary
and vice versa. unzip therefore prints ''[text]'' or
''[binary]'' as a visual check for each file it extracts when using
the -a option. The -aa option forces all files to be extracted
as text, regardless of the supposed file type.
EDIT: Also, if you have access to a Linux machine, you might want to checkout dos2unix. More details here as well. And found another Stack Overflow question here.
Finally found an easy way to fix this! I was looking through the php.ini file when i came across an option which is named: auto_detect_line_endings, and has its default value set to: Off.
The description to this option is:
; If your scripts have to deal with files from Macintosh systems,
; or you are running on a Mac and need to deal with files from
; unix or win32 systems, setting this flag will cause PHP to
; automatically detect the EOL character in those files so that
; fgets() and file() will work regardless of the source of the file.
; http://php.net/auto-detect-line-endings
Which is exactly what i was looking for!
I simply used the ini_set() function at the beginning of my database file(which i load on every php page) and it seems to have solved the problem for me! The ini_set() function also returns the option changed in the php.ini file to normal when script is completed.
Full line of the ini_set() function that i used:
ini_set("auto_detect_line_endings", true);
Thanks for all your help guys!
More info on ini_set() function here: ini_set() function
More info on the auto_detect_line_endings option here: Auto detect line endings option
I'm searching there for a long time, but without any helpful result.
I'm developing a PHP project using eclipse on a Ubuntu 11.04 VM. Every thing works fine. I've never need to look for the file encoding. But after deploying the project to my server, all contents were shown with the wrong encoding. After a manual conversion to UTF8 with Notepad++ my problems were solved.
Now I want to change it in my Ubuntu VM, too. And there's the problem. I've checked the preferences in Eclipse but every property ist set to UTF8: General content types, workspace, project settings, everything ...
If I look for the encoding on the terminal, it says "test_new.dat: text/plain; charset=us-ascii". All files are saved to ascii format. If I try to create a new file with the terminal ("touch") it's also the same.
Then I've tried to convert the files with iconv:
iconv -f US-ASCII -t UTF8 -o test.dat test_new.dat
But the encoding doesn't change. Especially PHP files seems to be resistant. I have some *.ini files in my project for which a conversion works?!
Any idea what to do?
Here are my locale settings of Ubuntu:
LANG=de_DE.UTF-8
LANGUAGE=de_DE:en
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
I was also wondering about character encoding and found something that might be usefull here.
When I create a new empty .txt-file on my ubuntu 12.04 and ask for its character encoding with: "file -bi filename.txt" it shows me: charset=binary. After opening it and writing something inside like "haha" I saved it using "save as" and explicitly chose UTF-8 as character encoding. Now very strangely it did not show me charset=UTF-8 after asking again, but returned charset=us-ascii. This seemed already strange. But it got even stranger, when I did the whole thing again but this time included some german specific charakters (ä in this case) in the file and saved again (this time without saving as, I just pressed save). Now it said charset=UTF-8.
It therefore seems that at least gedit is checking the file and downgrading from UTF-8 to us-ascii if there is no need for UTF-8 since the file can be encoded using us-ascii.
Hope this helped a bit even though it is not php related.
Greetings
UTF-8 is compatible with ASCII. An ASCII text file is therefore also valid UTF-8, and a conversion from ASCII to UTF-8 is a no-op.
I work on a Windows 7 machine and Notepad++ for a number of tasks. I have noticed that when I work with someone on a Mac who tries to edit a file, and then I access it later, there are always extra lines, sometimes missing lines, white space is all crazy. Usually extra lines.
Sometimes, there fewer lines or code is just collapsed as if all white space were removed.
I'm certain there isn't a prank involved, as it has happened a number of times over the years. I'm just finally curious enough to ask if anyone knows what causes this?
That happens when you download a file that it's in Linux to a Windows throught FTP ASCII, you can download the files with FileZilla selecting:
Transfer -> Transfer Type -> Binary
That way the EOLs transfers just fine.
This is probably caused by the EOL or end-of-line character that you have selected in your editor. I also code on a Windows 7 machine, but have to push my files to UNIX where if I view the files, I will see ^M's or other strange characters in VI. If I recall correctly, go to Edit -> EOL Conversion and convert to UNIX/MAC. Just be sure to always set your EOL to UNIX and you shouldn't see the issue anymore.
Here's a link to a similar topic on SO:
https://stackoverflow.com/questions/2889163/eol-in-notepad-and-notepad
What may be happening is that the Mac user is encoding the file in a slightly different way. Notepad++ is readying the file, but is not expecting to have to handle a Mac encoded file -- thus it renders oddly.
For example, the software may be converting tabs to spaces. Another example is the special characters used between systems, such as:
\n = CR (Carriage Return) - used as a new line character in Unix
\r = LF (Line Feed) - used as a new line character in Mac OS
\n\r = CR + LF - used as a new line character in Windows
That's my thought.
Issue 1
I have been using NetBeans on my work machine to develop a PHP website. The issue I have is that using netbeans, in the application itself, every other line is a blank line. Even opening a correctly formatted document will cause this issue. E.g.:
Coded using Notepad:
<p>Test para with
just a standard line break
and just a few more to
show what I mean</p>
When displayed in NetBeans is shows as:
<p>Test para with
just a standard line break
and just a few more to
show what I mean</p>
Issue 2
The main issue I have, is that all files saved are saved in a single line (proven when opened in notepad). This causes me an issue when uploading as it reads the PHP files in a single line so the first comment will cause the rest of the document to be commended:
<?php[]include('lib/config.php');[][]$query = "SELECT * FROM......"[][]// This comment now comments out the rest of the document>
The [] represent the square boxes shown in the notepad file.
I have tried all the formatting settings in NetBeans for PHP but I can't seem to resolve it.
Thanks
This question got answered in one way on an old StackOverflow question here.
To change the way how NetBeans IDE editor save your line endings, you can follow the following instruction.
Open the NetBeans Configuration file from NETBEANS_HOME\etc\netbeans.conf where NETBEANS_HOME is the folder where NetBeans IDE is installed, which is usually C:\Program Files\NetBeans IDE 6.9.1 (may change according to your version) in Windows
Update the setting netbeans_default_options and add -J-Dline.separator=CRLF at the end of it.
For example:
netbeans_default_options="...... -J-Dline.separator=CRLF"
--where ....... means existing settings which we have to keep as they are.
References:
Wiki entry at netbeans.org for line endings
with regards
Tushar Joshi, Nagpur
Notepad uses windows line end style - CR/LF (\r\n), while Netbeans for some reason, opens a file in Linux style (\n). To fix this you can:
stop using a Notepad, and use f.i. Notepad++ - where you can configure line ending style. (notepad can't understand LF - so displays it as squares)
convert your documents to one chosen style - I always force my software (editors, git, ect) to use LF only. You can do this with NetBeans:
Ctrl+Shift+H (opens Replace in projects window)
Containing text: \r
Replace with: nothing, leave this blank
tick Regular Expression
find and replace
Backup your data before doing this :)