I created an Arabic website using PHP 5.3, MySQL 5 and PHPMyAdmin 3.4.
On every page, I use the "utf-8" character set. I include the following line on every page:
http://jsfiddle.net/Hh7mk/
The website works fine offline (on local server (localhost)). Even after I edited and inserted new Arabic writings into the database.
The problem is when the website is online. All Arabic fonts are displayed properly, but after I edited or inserted new Arabic writings into the database online, the new writings are displayed as question marks.
My settings (online):
PHPMyAdmin MySQL Connection Collation : utf8_general_ci.
PHPMyAdmin MySQL charset : UTF-8 Unicode (utf8).
The database and tables collation : utf8_general_ci.
In the connection file, I have included mysqli query SET NAMES 'utf8' and SET CHARACTER SET utf8.
I also have tried to change the collation to "cp1256_general_ci", and the pages character set to "windows-1256", but the fonts still show as question marks.
Why the Arabic fonts show as question marks after I inserted/ edited them online? How to fix this?
Thank you in advance
Have you tried using mysql_set_charset
mysql_set_charset("utf8");
seems you are doing everything right. but did you make all this before inserting data?. try cleaning up database and inserting from the scratch
The ASCII ? mark's code is 63 which is the first byte of all Arabic characters (each character has two bytes). Having your strings turned to ? means that only the first bytes of your characters are stored/retrieved. This is an indication that somewhere is your store/retrieve process you've got a bottleneck in which only ASCII characters can pass. My bet is on MySQL. The best way you can find this out is to use your local server's code (a local PhpMyAdmin shall do) connecting to your production server's MySQL. If the problem remains it shows that it's MySQL's configuration doing (considering the fact that your local PhpMyAdmin works fine with your local MySQL). I can only give you ideas on how to investigate the problem. You need to find the problem itself on your own.
Related
For multi language, i have tried mysql collation with "utf8_unicode_ci" and also "utf8mb4_unicode_ci", but i getting issues.
1) when i update the text by coding. the output in phpmyadmin showing "எமà¯à®à®ªà®¿" junk character, but the output in website is displaying correctly.
2) when i update the text by directly in phpmyadmin. the output in phpmyadmin showing correct, but the output in website is showing "??????" characters.
How to showing correct in both phpmyadmin and website?
Note: the language text is tamil text
You need to use utf8_general_ci encoding for multi-language is widely used.
Also, when you need to do operation from code set character encoding to utf8 from mysql.
Hope fully it will solve your issue.
My database deals with Chinese and Japanese characters.
When I insert rows on the phpMyAdmin command box, it works beautifully.
But problem occurs when I set up a query input on my website, the query is fetched by a php file, like:
$query = $_POST['query'];
$result = $dbc->query($query);
The non-English characters just become rubbish in database, like
ID column1
1666 ä½ å¥½å•Šå•Šå•Š
I checked that the php file receives the characters fine, the problem should come from Mysql. All charset is utf-8.
I am new to mysql, please let me know if you may need more info.
Thank you in advance.
column's collation set to utf8_general_ci
More information : https://dev.mysql.com/doc/refman/5.7/en/charset-applications.html
Add this line into your config.inc.php in PHPMyAdmin
$cfg['DefaultCharset'] = 'utf8';
$cfg['DefaultConnectionCollation'] = 'utf8_general_ci';
Since phpMyAdmin works expected, it sounds like your application is at fault here.
Perhaps you could clarify what you mean when you wrote "php file receives the characters fine" -- how did you determine that? The way I read it, you can create the proper characters from your application and they're displayed correctly in the database through phpMyAdmin, but when you try to display it through your application it shows gibberish. In that case it seems the portion of the application that retrieves and displays the data is at fault.
Regardless, there are many answers here about having gibberish characters, the best place to start is UTF-8 all the way through and you could also read more at Special characters in PHP / MySQL or Problem with PHP and Mysql UTF-8 (Special Character). Finally, even thugh it's off the Stackoverflow network, the phpMyAdmin wiki covers this pretty well also.
As a hint, most of the time I see this issue it's caused by not issuing SET NAMES (or using an equivalent function) when setting up the MySQL connection from your PHP script.
I have a website, with arabic content which has been migrated from a different server. On the old server, everything was displaying correctly, supposedly everything was encoded with UTF-8.
On the current server, the data started displaying incorrectly, showing نبذة عن and similar characters.
The application is build on the CakePHP Framework.
After many trials, I changed the 'encoding' parameter in the MySql connection array to become 'latin1'. For the people who don't know CakePHP, this sets MySql's connection encoding. Setting this value to UTF8 did not change anything, even after the steps described below.
Some of the records started showing correctly in Arabic, while others remained gibberish.
I have already gone through all the database and server checks, confirming that:
The database created is UTF-8.
The table is UTF-8.
The columns are not explicitly set to any encoding, thus encoded in UTF-8.
Default Character set in PHP is UTF-8
mysql.cnf settings default to UTF-8
After that, I retrieved my data and looped through it, printing the encoding of each string (from each row) using mb_detect_encoding. The rows that are displaying correctly are returning UTF8 while it is returning nothing for the rows that are corrupt.
The data of the website has been edited on multiple types, possibly with different encodings, this is something I cannot know for sure. What I can confirm though, is that the only 2 encodings that this data might have passed through are UTF-8 and latin1.
Is there any possible way to recover the data when mb_detect_encoding is not returning anything and the current dataset is unknown?
UPDATE: I have found out that while the database was active on the new server, the my.cnf was updated.
The below directive was changed:
character-set-server=utf8
To
default-character-set=utf8
I am not sure how much this makes a difference though.
Checking the modified dates, I can conclude to a certain degree of certainty that the data I could recover was not edited on the new server, while the data I couldn't retrieve has been edited.
Try to fix the problem from DB side .. not from php or DB connection
I advice you to go to your old server and export your DB again with character set UTF8
then after import it to a new server .. be sure that you can see the arabic characters inside the tables(with phpmyadmin)
if your tables looks fine ..
then you can move to check the next
DB connection
php file encoding
the header encoding in html
as I know if the problem from the DB .. there is no way without export the data again from the old server
Edit:
if you do not have access to your old DB please check this answer it can help you
You were expecting نبذة عن? Mojibake. See duplicate for discussion and solution, including how to recover the data via a pair of ALTER TABLEs.
I had a similar problem with migrating database tables encoded with utf8 from a public server to localhost. The resolution was in setting the localhost server encoding using PHP
$db->set_charset("utf8")
right after the mysqli connection.
Now it works properly.
I want to save chinese characters in mysql db, charset is set to UTF8 via connecting to db, also the field's charset is utf8, and collation - utf8_general_ci,
But instead of the word it shows squares. I use sqlyog.
There is one thing, if I make request and echo the word in the browser if shows the right chinese word.
So, I am wondering why it shows the correct word in browser, when in db it is like squares and vice versa.
I am afraid that maybe via exporting or importing in the future I can have some data lose.
Thanks
Your data might be stored correctly in the DB, but read wrongly by sqlyog.
I haven't used sqlyog, but this problem might be because of the way sqlyog connects to MySQL - look for parameters in sqlyog connection to DB that are related to character set and make sure they are also utf8
I had a similar problem when I had to insert Latin characters to the database, I used mb_convert_encoding($str, 'utf8', 'HTML-ENTITIES') and it got stored correctly in the database and wen I had to show it in the html page I just had the encoding=utf-8
We imported a website from another server to our server. The code and database is 100% the same.
But the text on the website seems to have a wrong encoding.
Example:
In the database the word "Australië" is "AustraliĂŤ" while on the website its shown as Australi??.
I can fix the ?? with adding mysql_set_charset("utf8",$this->db); after the database connection.
But then its shown like in the database like "AustraliĂŤ" wich is incorrect. I tried different encodings in apache, after database and in meta tags.
The easiest way would be to change the data in the database but there is to much data in it to do this.
Anyone has a solution for this problem? Have been searching and trying a lot off things for hours.
You could try to:
set the MySQL connection collation to uft8_general_ci in the database
run SET NAMES 'utf8' and SET COLLATION_CONNECTION=utf8_unicode_ci in your PHP files
make sure all your PHP files are saved with UTF-8 encoding and do not feature a BOM
make sure the cells in your table are utf8_general_ci
make sure that MySQL charset is UTF-8 Unicode (utf8)
This is what I have. With this setup I see all characters in the database (phpMyAdmin) as they really appear on the website itself.
I have encountered a similar issue when I had a mismatch of encodings, i.e. I was saving data to a UTF-8 database by a ISO-8859-1 encoded site...
Hope this helps you.