I have encountered a similar problem described here (and in other places) -
where as on an ajax callback I get a xmlhttp.responseText that seems ok (when I alert it - it shows the right text) - but when using an 'if' statement to compare it to the string - it returns false.
(I am also the one who wrote the server-side code returning that string) - after much studying the string - I've discovered that the string had an "invisible character" as its first character. A character that was not shown. If I copied it to Notepad - then deleted the first character - it won't delete until pressing Delete again.
I did a charCodeAt(0) for the returned string in xmlhttp.responseText. And it returned 65279.
Googling it reveals that it is some sort of a UTF-8 control character that is supposed to set "big-endian" or "small-endian" encoding.
So, now I know the cause of the problem - but... why does that character is being echoed?
In the source php I simply use
echo 'the string'...
and it apparently somehow outputs [chr(65279)]the string...
Why? And how can I avoid it?
To conclude, and specify the solution:
Windows Notepad adds the BOM character (the 3 bytes: EF BB BF) to files saved with utf-8 encoding.
PHP doesn't seem to be bothered by it - unless you include one php file into another -
then things get messy and strings gets displayed with character(65279) prepended to them.
You can edit the file with another text editor such as Notepad++ and use the encoding
"Encode in UTF-8 without BOM",
and this seems to fix the problem.
Also, you can save the other php file with ANSI encoding in notepad - and this also seem to work (that is, in case you actually don't use any extended characters in the file, I guess...)
If you want to print a string that contains the ZERO WIDTH NO-BREAK SPACE char (e.g., by including an external non-PHP file), try the following code:
echo preg_replace("/\xEF\xBB\xBF/", "", $string);
If you are using Linux or Mac, here is an elegant solution to get rid of the character in PHP.
If you are using WordPress (25% of Internet websites are powered by WordPress), the chances are that a plugin or the active theme are introducing the BOM character due a file that contains BOM (maybe that file was edited in Windows). If that's the case, go to your wp-content/themes/ folder and run the following command:
grep -rl $'\xEF\xBB\xBF' .
This will search for files with BOM. If you have .php results in the list, then do this:
Rename the file to something like filename.bom.bak.php
Open the file in your editor and copy the content in the clipbard.
Create a new file and paste the content from the clipboard.
Save the file with the original name filename.php
If you are dealing with this locally, then eventually you'd need to re-upload the new files to the server.
If you don't have results after running the grep command and you are using WordPress, then another place to check for BOM files is the /wp-content/plugins folder. Go there and run the command again. Alternatively, you can start deactivating all the plugins and then check if the problem is solved while you active the plugins again.
If you are not using WordPress, then go to the root of your project folder and run the command to find files with BOM. If any file is found, then run the four steps procedure described above.
You can also remove the character in javascript with:
myString = myString.replace(String.fromCharCode(65279), "" );
I had this problem and changed my encoding to utf-8 without bom, Ansi, etc with no luck. My problem was caused by using a php include function in the html body. Moving the include function to above my html (above !DOCTYPE tag) resolved the issue.
After I knew my issue I tested include, include_once and require functions. All attempts to include a file from within the html body created the extra miscellaneous 𐃁 character at the spot where the PHP code would start.
I also tried to assign the result of the include to a variable ... i.e $result = include("myfile.txt"); with the same extra character being added
Please note that moving the include above the HTML would not remove the extra character from showing, however it removes it from my data and out of the content area.
In addition to the above, I just had this issue when pulling some data from a MySQL database (charset is set to UTF-8) - the issue being the HTML tags, I allowed some basic ones like <p> and <a> when I displayed it on the page, I got the 𐃁 character looking through Dev Tools in Chrome.
So I removed the tags from the table and that removed the 𐃁 issue (and the blank line above the where the text was to be displayed.
I just wanted to add to this, since my Rep isn't high enough to actually comment on the answer.
EDIT: Using VIM I was able to remove the BOM with :set nobomb and you can confirm the presence of the BOM with :set bomb? which will display either bomb or nobomb
I use "Dreamweaver CC 2015", by default it has this option enabled: "include BOM signature" or something like that, when you click on save as option from file menu. In the window that apears, you can see "Unicode Options..". You can disable the BOM option. And remeber to change all your files like that. Or you can simply go to preferences and disable the BOM option and save all your files.
I'm using the PhpStorm IDE to develop php pages.
I had this problem and use this option of IDE to remove any BOM characters and problem solved:
File -> Remove BOM
Try to find options like this in your IDE.
Probably something on the server. If you know it's there, I would just bypass it until solved.
myString = myString.substring(1)
Chops off the first character.
When using atom it is a white space on the start of the document before <?php
A Linux solution to find and remove this character from a file is to use sed -i 's/\xEF\xBB\xBF//g' your-filename-here
My solution is create a php file with content:
<?php
header("Content-Type:text/html;charset=utf-8");
?>
Save it as ANSI, then other php file will require/include this before any html or php code
Related
Since yesterday, my server is adding some garbage characters to any script in PHP. If I look at my code with view source, I see some spaces and if I display a JSON string, it is considered invalid.
If I take this simple example:
<?PHP
echo "hello";
?>
It displays hello but in the source code I see a blank line before hello. The encoding of the file is in UTF8 without BOM (did it with Notepad++)
If I use file_get_contents to load the PHP file and then use rawurlencode before outputting the content, I get the following garbage before hello:
%EF%BB%BF%EF%BB%BF%EF%BB%BF
My first thought was that it was an encoding issue but I checked the concerned PHP file(s) and they are all in UTF8 without BOM. The only solution I have found is to remove this string of garbage each time before treating the content of a file.
I'm using Wordpress and the problem suddenly appeared yesterday while I had not modified any file.
Do you have any idea?
Thanks
Laurent
This is very bizarre. I have a .txt file on my Windows server. I'm using file_get_contents to retrieve it, but the first several characters show up as a diamond with a question make inside them. I've tried recreating the file from scratch and it's the same result. What's really bizarre is other files don't have this issue.
Also, if I put a * at the start of the file it seems to fix it, but if I try to open the file and do it with PHP it's still messed up.
The start of the file in question begins with: Trinity Cannon - that's a direct copy and paste from the text file. I've tried re-typing it and the first few characters are always that diamond with a question mark.
$myfile='C:\\inetpub\\wwwroot\\fastpitchscores\\data\\2020.txt';
$fh = file_get_contents($myfile);
echo $fh; // Trinity Cannon
echo $fh[0]; // �
It sounds like whatever editor you used to originally create the file a UTF Byte Order Mark at the beginning the file.
You typically can't edit the BOM from within an editor. If your editor has a encoding conversion functionality, try converting to ASCII. For example, in Notepad++ use Encoding->Encode in ANSI.
I'm having troubles with multiple html pages include.
I had main index.html but it started to be a bit too complex so I decided to split it in multiple html files and each one of them inport into single index.php using php.
index.php file
<?php
include('head.html');
include('header.html');
include('slideshow.html');
include('pictureGalery.html');
include('footer.html');
include('closer.html');
?>
using Google Chrome Developer Tool I found, that php includes included also some white spaces (you can see them in picture in between of divs header, content, container etc...
With a bit of googling I found some arciles about this problem, like:
PHP include causes white space at the top of the page (I can't use edit cmd command because I have win7 64-bit and it is not implemented there. You can only use "open notepad " command, but these whitespaces are not visible in notepad.
UTF-8 Without BOM?
PHP include() before doctype, causing a white space
I also tried to import reset.css file (http://meyerweb.com/eric/tools/css/reset/) but it didnt work either. The only way that seems to work for me is one that posted cebasso (https://stackoverflow.com/a/14362246/1784053). But I find this way a bit too agresive and unefective.
Any other ideas how to fix this problem?
Then, ends up this is caused by unexpected BOM on the file that are included:
For future reference, I just post the code used to check by PHP plainly.
print_r(array_map('dechex', array_map('ord', str_split(file_get_contents("xxxxxxxxxxxxx.html")))));
I would definitely prefer using Notepad++ or other software to save a non-BOM version,
but if still prefer using PHP to remove them, just use:
This removes first 3 characters in the file PERMANENTLY every time you execute it, so run once only.
$filename="xxxxxxx.html";
$filec = file_get_contents($filename);
file_put_contents($filename,substr($filec, 3, strlen($filec)));
Hopes it helps :D
Good luck!
I have the same problem before a moment. but when I see BOM characters, I think of a solution. Am not sure, but these characters for utf-8 encoding. I save my included file as ansi and the problems solved. also it's works fine with encode in utf-8 without BOM in Notepad++
Thanx
Regards
I'd look closely at your included files. Ensure that there is no white space at the top or bottom of every one of those documents. White space is not ignored by php and will definitely be included.
Consider the following code:
<div id="sidebar">
<?php
require_once('/components/search.php');
require_once('/components/categories.php');
?>
</div>
search.php and category.php are essentially the same structure - a div container with some specific contents. Nothing special here, pure HTML:
<div class="component">
<!-- blah -->
</div>
However, when inserted with require_once (or require / include etc), PHP adds whitespace above each element, pushing it down, identifiable as an empty text node in Chrome's Inspect Element tool (the whitespace disappears when this node is deleted)
Deleting all unnecessary whitespace from the sidebar script (making it a single line of code) doesn't fix it. And if I just replace the require_once lines with the contents of the components, the whitespace doesn't appear. So not sure why PHP is adding it on require. Any ideas?
Update
This one's still proving to be a weird one. I agree now that require_once does not seem to be the root cause as such. I decided to ignore the problem for a while and hope it would go away after I'd worked on it further. Alas, it remains, so I did bit more investigating. Checking the page source in the browser confirms that the code in question is indeed returned as a single long unbroken line http://pastebin.com/dtp7QNbs - there's no whitespace or carriage return between any of the tags, yet space appears in the browser - identifiable in the Inspect Element tool as empty lines between each <div class="component">
Does this help shed any more light on the issue?
I had the same problem and verified Kai's solution to change the format to ANSI but also found that "Encode in UTF-8 without BOM" also works.
This comes up as the default format for new Notepad++ PHP files so one less conversion step.
It seems that use of the byte order mark file header in UTF-8 is not generally recommended. I verified that my installation of VS2010 was adding BOM when saving PHP files.
The following stackoverflow article explains nicely where the extra whitespace got inserted.
What's different between utf-8 and utf-8 without BOM?
Problem solved! This took forever to figure out. The short answer is that my php files were UTF-8 encoded. Changing this in Notepad++ to ANSI fixed it.
I only found the real cause of the problem by doing a character-by-character comparison of the output HTML - one output from where 'require_once' was used and one where the code was manually pasted in place.
In a visual comparison of the output, both appeared identical - same length, no extra/different characters. But when pushed through preg_split('//', $string), and looped through character by character, 3 extra "invisible" characters were revealed at the start of each require_once insert point. I idenitified these as the ASCII characters ï, » and ¿ (a double-dotted i, a right chevron and an upside-down question mark).
Changed the encoding to ANSI (I discovered this as the cause when I recreated one of the scripts in Notepad word-for-word and it did not suffer the same issue), and the extra lines have gone.
The extra characters are the BOM (Byte Order Mark). So converting to UTF-8 without BOM was the real trick here. More info here: http://en.wikipedia.org/wiki/Byte_order_mark
some time it happened because of white space after ?> on the class file, also or before <?php
It's easy to save PHP file as UTF-8 without mark symbols in Programmer's Notepad editor using:
File -> Encoding -> UTF-8 No Mark
File -> Save
After that require command will include PHP script without adding whitespaces.
First, put <?php on the same line as the DIV:
<div id="sidebar"><?php
This gets rid of the whitespace before search.php.
Then make sure that search.php has no newline at the end, that's causing the whitespace between search.php and categories.php. Some text editors add a trailing newline by default, you may need to override this.
I just tried this, the output of php main.php is:
<div id="sidebar"><div class="component">
<!-- search.php -->
</div><div class="component">
<!-- categories.php -->
</div></div>
I'm editing the functions.php file of a WordPress theme and whenever I edit it, even when the edit is adding a single space the server returns
error:
Parse error: syntax error, unexpected '}' in /theme/functions.php on line 1
This is where I add the single space:
<?php load_theme_textdomain('theme', get_template_directory() . '/languages');
<— I added a single space here
and everything dies after that. This is not a consistent error, as it goes away after I replace the whole functions.php file itself with a backed up one. It only is replicated when I edit the file, that is, as presented even with single white-space character. I'm using NetBeans and CuteFTP to edit then upload the files.
What is going on?!
This must have to do with some kind of file quality itself, since from a code standpoint the code is exactly the same...or maybe my server.
Solution:
Netbeans defaults to a specific file encoding per project. Foreign files may have a different encoding which may cause problems. Cody the foreign file's contents to a new blank file which you created via Netbeans.
It could be an encoding error. Maybe when you try to edit the file your text editor is including a UTF-8 BOM at the top.
EDIT
Just found instructions for saving as UTF-8 without BOM in Notepad++:
1) Click on "Format"
Select "Encode in UTF-8 without BOM"
2) Click on "settings"
Click on "Preferences"
Click on "new document/open save directory"
Select "UTF-8 without BOM"
(Source: http://www.phpbb.com/community/viewtopic.php?f=66&t=1584655#p9490925, 5th answer from the bottom)
But the encoding you need to set really depends on the original file. If it's not UTF-8, you should keep the original encoding (Latin 1 or whatever).
Are you including it in the right place? See http://codex.wordpress.org/Function_Reference/load_theme_textdomain