so i created tables in sql with £…it appears in PHP file as diamond
but when i deleted it in sql and wrote describtipn in my PHP contol-panel £ sign looks fine now in PHP but in SQL it looks like A£…
i am not posting the code i feel i need to add something in my file but not sure what
i have utf-8 set up everywhere
Unfortunately, it is not so.
A question mark in a diamond means that the page encoding is not utf-8.
Make sure you are sending the proper Content-type header, for example by issuing the following command
header('Content-Type: text/html; charset=utf-8');
There are quite a few places where you need to be set to utf-8. In the html header, in saving your files, the database collation etc. I was caught out by this after setting all these up as utf-8. As it turned out I had to set the database connection to utf-8 too, to display £ properly.
A hint:
So you can always tell whom to blame.
yes i have in html :
in php:header(‘Content-Type: text/html; charset=utf-8’);
in connection.php: mysqli_set_charset($con,“utf8”);
and in sql collation utf=8
what is strange that if i write £ in my php comtrol panel (INSERT ) it looks fine, but in sql it displays as A£…
but when i write £ in SQL it displays as black diamond with question mark in PHP but fine in the sql…
so there is someyhing wrong with connection sql/php
Hi there!,
I hope you solved already your problem, but if you still struggling… try my approach.
conifg.php
DEFINE("HOST",'mysql:host=localhost;dbname=mydb;charset=utf8');
DEFINE("USER",'root');
DEFINE("PASSWORD",'');
And In your application you instantiate pdo connection like this,
require_once 'config.php';
$connection = new PDO(HOST,USER,PASSWORD,array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8"));
// do some other stuff
no… not resolved and tried all 
Out of interest, where does your pound-sign come from? Are you hard-coding it in your editor, or typing into a text entry on a web page? If from an editor, could the editor character-set be incorrect?
I’ve hated pound-signs since trying to set up Epson dot-matrix printers to print them back in the mid-80s. Shouldn’t you encode it as £ to be safe, anyway?
so when i type it in the text entry on the website, it will display fine… but when i type it in the sql it displays as diamond with sign:?
but it is not all…
you could say type it text entry on a web and problem solved… not really…in sql it displays as " A£"
so decided have it with error in sql and on the website wil be fine
It should not be necessary, if everything is utf-8 everywhere, but something somewhere is not. 
As a quick fix you could try encoding.
echo htmlentities($row['ColumnName']);
Now come to think of it, that probably won’t work, as what’s in that string is not translating to a £ or it would surely display as such.
But doing that may give a clue to what it is coming out as.
i tried htmlentities (no idea what it is for) but what happened is:
column without £ displays fine
column with £ is empty/blank
Ah, yes, that will be…
If the input string contains an invalid code unit sequence within the given encoding an empty string will be returned, unless either the ENT_IGNORE or ENT_SUBSTITUTE flags are set.
http://php.net/manual/en/function.htmlentities.php
Well I did say it probably won’t work. 
So it’s still a case of finding which part of the process is not utf-8, which is the right thing to do after all.
What has not been mentioned in this thread yet is the character set of the database tables and columns. The text columns must be all declared as utf8 or utf8mb4. If they are not then strange things happen like the web site may display the characters properly while they remain encoded wrong in the database. I once noticed such a phenomenon on a web site:
The web site (html) was set to utf-8 while the database tables were defined as latin1 (or latin2, I can’t remember and it doesn’t matter) and everything displayed fine in the browser. You can still store utf8 multi-byte characters in a latin1 or ascii text column (most of the time) - for example, if you store a 2-byte utf8 character it will be visible in the database as two separate characters (usually some nonsensical ones) but when you fetch them and display on the web site in utf-8 they will display fine as a single character because the proper byte sequence has been preserved. Although you may think everything works fine, there are a few hidden problems with that, for example, string comparison, searching or string functions will be broken on all but basic ascii characters. The solution is to change the column character set to utf8 and re-encode the data (convert) to proper utf8. In most cases a simple search and replace is enough.
i feel i changed to utf-8 everywhere…
database: utf8_unicode_ci
php: header(‘Content-Type: text/html; charset=utf-8’);
html:
file encode in utf-8
php version 7
So we can be sure the columns are utf8, that’s good. Now make sure that your phpmyadmin is set to properly - look for “Server connection collation” setting. Do the characters show up properly in phpmyadmin?
So your data also appears to be ok. According to what you reported here you’ve got everything set up properly for utf-8 - in theory, because somewhere something is screwing things up. At this moment I would suggest trying to inspect and debug your code since this might look like an application error. You might also set up a separate independent php script that connects to the same database, grabs some data and displays it - then see how it works.
There’s certainly something we (and you) don’t know about, something unexpected in the code or setup that mangles the encoding. This needs more manual inspection.
can you change it to general_ci ? …also please delete first your old entry and input again via web forms then save it.
I duplicated the problem on my system, but I must say I’ve not given it any though because of what I’m doing here. But I fixed the issue by specifying “charset=utf8mb4” as part of my PDO connection string. In looking at it, this article seemed to be helpful - http://stackoverflow.com/questions/279170/utf-8-all-the-way-through
