I need to input content in 10 languages in MYSQL database (problem ones are: Chinese, Russian, Arabic) and client should be able to read and edit them through phpMyAdmin as well as admin area.
I have used utf8-bin, utf8_unicode_ci, utf8_general_ci, but the characters does not show properly in phpMyAdmin. In addition I need to consider the search and sort problems and as I can't understand the above languages I am worrying that some characters might be escaped or mapped incorrectly.
Which UT8 is the best in this case?
Is it normal for phpMyAdmin to display characters as '動力å“牌çµåˆå“牌與科技'?
How can I make phpMyAdmin display the content in human readable way?
There is nothing wrong with your database it seems (unless the database's contents is also UTF-8 mojibake, being double-mojibaked on the way to your browser); the output example you have included looks like that your browser's encoding to interpret the phpMyAdmin page in is incorrect, most likely some ISO-8859 variant. Check and make sure that your browser's encoding is UTF-8.
The different collations specify different rules for sorting and searching, but the encoding is still the same. If you are storing multiple languages in the database, use utf8_general_ci.
Related
In my codeigniter project I am using MySQL as database. It's collation is 'latin1_swedish_ci'. Now I need to scale my website to store 'Polish', 'German', 'French', 'Ukrainian', 'Dutch' in addition to 'English'. But I don't know which collation to be used. I found different answers for different language in web. But I need a general one. Please help me to find out a solution.
(Alvaro's answer is good; I am adding some notes.)
If you are using MySQL 5.5 or 5.6 and have VARCHAR(255), see this for some issues you might run into.
ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4;
(for each table) is probably the simplest way to convert to UTF-8. Caution: test it separately from production, and test that the Western European text does not get mangled. If you get gibberish or question marks, see this
In converting to CHARACTER SET utf8mb4, the preferred COLLATION is utf8mb4_unicode_520_ci. (With MySQL 8.0, there is a better one.)
utf8mb4 will let you handle all the languages of the world, so this should be the last 'conversion' necessary.
Before caring about collation, you need to migrate to a Unicode compatible encoding first. As the name suggest, Latin-1* is designed for Latin script and cannot encode all Polish characters and, of course, none of the Cyrillic script. The obvious choice in 2019 is UTF-8, which corresponds to utf8mb4 in MySQL terminology.
Beware though that this may not be trivial. If your application assumes single byte encodings any text manipulation feature may need to be reviewed and maybe fixed. For instance, the € symbol has a length of 1 byte in Windows-1252 but it's 3 bytes in UTF-8. Let's say you have code that strips it from a string like '29.92€'. If your application removes the last byte, code that was working flawlessly in a single-byte encoding will no longer be valid in a multi-byte encoding because one byte isn't one character any more. Or, even in MySQL itself, some as simple as regular expressions wasn't multibyte safe until MySQL 8.0.4.
Once you address this, you need to pick a proper collation. Since you're mixing languages you need a general purpose Unicode one. Here's a good overview.
(*) MySQL is actually lying to you. When it says Latin-1 it actually means Windows-1252.
Whilst doing some checking for a client to see if their site was still functioning well I found a random page that contained a bunch of weird characters like ¿½.
I think this has to do with the tables having a latin1 encoding instead of utf-8. But seeing as no other pages are affected that use the same table could there be another error. I did check if the text itself was safe and making sure it was just clean text.
So I have 2 questions, the main one being is it safe to just update this one table to utf8 and if not what causes this error and wondered why would this only affects one certain page.
(Side note the website is built using typo3)
Ofcourse I have live example's the links are:
Site 1: With weird text characters
Site 2: Same table, but no weird characters
Ultimately the client connecting to the database decides how their encodings are handled; that's known as the connection encoding. Whatever encoding the text is stored as in MySQL, it will be converted on the fly to/from the client's connection encoding. As such, just changing the underlying column's storage to utf8 doesn't affect anything.
However, that in itself also won't "fix" anything. The characters will still be garbage. You'll also have to convert the actual characters to the correct data. Otherwise you'll just have "¿½" stored encoded as utf8 instead of "¿½" stored encoded as latin1. And changing those characters will likely affect any other client which has been doing it wrong so far, so the client side needs to be fixed at the same time.
I have a MySQL database that is storing Persian data and information.
the information are names and I want to sort names by alphabet. but MySQL don't know Persian language, and some other right to left languages.
How can I sort them?
and my other problem is with phpmyAdmin, phpmyAdmin can't show Persian language data and show some character instead of that
About the first question; as fancyPants said, use the proper collation and you should be fine. Sorting is handled by collations and there is a utf8 Persian collation available.
About your second problem:
Almost certainly what is happening is that you're improperly storing the data. As Sid M said, knowing what you've tried and how your system is running would be a big help, but these questions almost always end up being misconfigured or poorly written software. phpMyAdmin and MySQL can deal just fine with multiple character sets. Presumably, you'll want to use utf8.
Set up your database and tables properly, then make sure your client application is configured properly (likely using SET NAMES 'UTF8' or mysql_set_charset('utf8'), but read the links for more detail than is worth including here).
See https://wiki.phpmyadmin.net/pma/Garbled_data and How to display UTF-8 characters in phpMyAdmin? for starters and SQL injection that gets around mysql_real_escape_string() for way more information than you probably wanted to learn :)
I'm having problems storing Swedish characters in my MySQL database. I want to store them in my table called users with the collation utf8-bin. Even though I'm using utf8, the characters å ä ö gets stored as Ã¥ ä ö and I don't know why. Retrieving the data and echoing it gives me the same output, with the weird characters instead of å ä ö. Any help is appreciated.
Call
mysql_set_charset("utf8");
After connecting and before making any queries.
Your database charset is just for storage, not for transmission between app and database.
There are several places, where you have to pay attention to the encoding.
Database: you already use an utf8 collation, so that's fine
Database connection: use mysqli_set_charset to set the charset of the connection, if you're using mysqli. Other database drivers have similar functions.
Output encoding of the page: You can use HTTP headers or meta tags. If you want to be on the safe side, specify both.
You should make sure that the database connection uses the Swedish encoding and the encoding of the page output is correct as well. Different encoding causes many of these problems. Read more about character encodings here.
There are several parameters that you have to consider here. For this to work well now and in the future. ALL different interactions with the text has to be in same encoding. Even within db (for joins to work well etc).
The encoding of the data beeing inserted (set in header of page and / or utf_8 encoding when inserted).
The encoding in db tables, (i would recommend utf8_swedish for all)
The encoding of the page viewing results from db (set this in header)
The encoding of the page beeing edited. Its possible to open documents in different encoding. This is a big issue if you are not familiar with it. Open and save documents in right encoding.
There use to be a problem concerning the connection encoding to, set this correct, but today it is a smaller problem than a couple of years ago, because of changes.
A couple of notes. Are you sure your data is stored like that, or just presented wrong, via for instance phpmyademin? Try to print with print utf8_encode($text)
Or, utf8_decode() function, that gives you some insight...
Diacritic signs http://img98.imageshack.us/img98/3383/dijakritickiznakovi.gif
So, symbols belows display title should be displayed that way.
UTF-8 entities are listed below HTML (utf-8) title (here is list: LINK)
And last line shows what is stored in my database.
Collation of db table is utf8_unicode_ci.
I suppose that symbols in db shouldn't be as they are in my case?
They are displaying correctly on page when loaded from database, but they all of them are not displayed by utf-8 table from given link. Even if I see them correctly maybe someone other won't?
Setting the MySQL table charset is not enough - you should also take care to set the correct charset for the client, the connection and the results, which defaults may differ from server to server making your database less than portable: the same database content might be displayed differently moving to another server.
I've been storing slovenian text into MySQL for some time now and this is what works for me:
the first thing you do after connecting should be to issue a "SET NAMES utf8" query
make sure that the strings you're storing are utf-8 to start with: if you're taking them from a web page form make sure the page is UTF-8
be careful what tools do you use to browse/edit the database contents online: PhpMysqlAdmin is definitely unsafe.
Hope this helps.
You appear to be trying to store HTML-encoded strings in your database. Don't do that, it will only break your ability to do string operations like searching reliably. You should be able to store raw UTF-8 encoded characters as bytes in your database.
You don't say what environment you're using to read the database or how you get the ‘incorrect’ string at the bottom (which is UTF-8 bytes read using ISO-8859-1 encoding). If they appear in your web page (and you're specifying UTF-8 in the headers and/or <meta> tag), you're presumably pretty much there.