Viewed   62 times

When I'm trying to insert russian text into MySQL database it inserts it like: ????????????? ?? ????????
???????°???‹?? ?° ?‹???°??

So, I have two pages: registration.php and addUser.php. In each of them

 <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Database consist of 11 tables, each table has collation: utf8_general_ci, type: MyISAM. Each field in every table has Collation: utf8_general_ci.

When I'm writing to database directly in phpMyAdmin and then show this data to web-page. In English and Russian - all OK.

But when I'm full my form with personal data on registration.php and then going to addUser.php - all russian characters displayed like I wrote upper - on page and in database too.

    function AddNewUser($Name, $Surname, $FatherName, $Email, $Password, $Phone, $DegreeID, $RankID, 
$Organization, $Department, $Country, $City, $Address, $Job)
        //fetch data from database for dropdown lists
        //connect to db or die)
    $db = mysql_connect($GLOBALS["gl_kussdbName"], $GLOBALS["gl_kussUserName"], $GLOBALS["gl_kussPassword"] ) or die ("Unable to connect");

    //to prevenr ????? symbols in unicode - utf-8 coding
    mysql_query("SET NAMES 'UTF8'");

    //select database
    mysql_select_db($GLOBALS["gl_kussDatabase"], $db);
    $sql = "INSERT INTO UserDetails (
    //execute SQL-query
    $result = mysql_query($sql, $db);
    if (!$result) 
        die('Invalid query: ' . mysql_error());
    //close database  = very inportant


There also such information in phpMyAdmin:

auto increment increment    1
auto increment offset   1
autocommit  ON
automatic sp privileges ON
back log    50
basedir usrlocalmysql-5.1
big tables  OFF
binlog cache size   32,768
binlog format   STATEMENT
bulk insert buffer size 8,388,608
character set client    utf8
(Global value)  cp1251
character set connection    utf8
(Global value)  cp1251
character set database  cp1251
character set filesystem    binary
character set results   utf8
(Global value)  cp1251
character set server    cp1251
character set system    utf8
character sets dir  usrlocalmysql-5.1sharecharsets
collation connection    utf8_general_ci
(Global value)  cp1251_general_ci
collation database  cp1251_general_ci
collation server    cp1251_general_ci
completion type 0
concurrent insert   1

So I need to properly show, save and select russian text from database. Thanx! connect timeout 10 datadir usrlocalmysql-5.1data



Try calling mysql_set_charset('utf8'); after connecting to the database. I think it's similar to executing a SET NAMES query, but since the PHP manual says using that function over a SET NAMES query is recommended, I'd try it.

Also, when you display your content, you could try echo htmlentities($string, ENT_COMPAT, 'UTF-8');

Monday, November 28, 2022
  • mb_internal_encoding('UTF-8') doesn't do anything by itself, it only sets the default encoding parameter for each mb_ function. If you're not using any mb_ function, it doesn't make any difference. If you are, it makes sense to set it so you don't have to pass the $encoding parameter each time individually.
  • IMO mb_detect_encoding is mostly useless since it's fundamentally impossible to accurately detect the encoding of unknown text. You should either know what encoding a blob of text is in because you have a specification about it, or you need to parse appropriate meta data like headers or meta tags where the encoding is specified.
  • Using mb_check_encoding to check if a blob of text is valid in the encoding you expect it to be in is typically sufficient. If it's not, discard it and throw an appropriate error.
  • Regarding:

    does this mean I have to use all multi byte functions instead of its core functions

    If you are manipulating strings that contain multibyte characters, then yes, you need to use the mb_ functions to avoid getting wrong results. The core string functions only work on a byte level, not a character level, which is what you typically want when working with strings.

  • utf8_general_ci vs. utf8_bin only makes a difference when collating, i.e. sorting and comparing strings. With utf8_bin data is treated in binary form, i.e. only identical data is identical. With utf8_general_ci some logic is applied, e.g. "é" sorts together with "e" and upper case is considered equal to lower case.
Monday, November 21, 2022

Besides the other answer,

Firstly, this part of your query:

INSERT INTO test-table (id, name, lastname, radio, drop, check)

should read as

INSERT INTO `test-table` (id, name, lastname, radio, `drop`, `check`)

MySQL is interpreting your table as "test minus table". Use ticks, or rename it using an underscore test_table which is a safe seperator.

Then you're using two MySQL reserved words, "drop" and "check". Use ticks for those also.



See how MySQL is telling you where the syntax error begins?

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'drop, check)

and it would have shown you another one after that being

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'check)

Just to clarify, you are mixing MySQL APIs with

mysql_query("INSERT ...

which those mysql_ functions do not intermix with your present method. Use the same from connection to query

mysqli_query($connect, "INSERT ...

and of course the fact that you're open to SQL injection. Use a prepared statement:


You should also check for empty fields against your POST arrays such as !empty().

Sidenote: If an apostrophe or any other character is to be inserted that MySQL will complain about, then you must escape them. Either way, you should.

Plus, remember to add exit; after header. Otherwise and if you have more code below that, it may want to continue and execute.

header("location: indextest1.php");
Sunday, August 7, 2022
$str = "";

foreach ($_COOKIE as $key => $value)
    $str .= $key . ":" . $value . ",";

$str = substr($str, 0, -1);
Thursday, December 1, 2022


SET NAMES indicates what character set the client will use to send SQL statements to the server. That means that SET NAMES 'cp1251' tells the server “future incoming messages from this client are in character set cp1251.” It also specifies the character set that the server should use for sending results back to the client.


SET CHARACTER SET is similar to SET NAMES, but sets character_set_connection and collation_connection to character_set_database and collation_database. A SET CHARACTER SET x statement is equivalent to these three statements:

SET character_set_client = x;
SET character_set_results = x;
SET collation_connection = @@collation_database;

Do both commands need to be issued in order to make MySQL UTF-8 aware? Or is SET NAMES enough?

SET NAMES is enough.

Wednesday, September 14, 2022
Only authorized users can answer the search term. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :