php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #44118 [PATCH] MySQL: Set connection charset via php.ini option
Submitted: 2008-02-14 13:00 UTC Modified: 2013-02-06 11:27 UTC
Votes:4
Avg. Score:4.5 ± 0.5
Reproduced:4 of 4 (100.0%)
Same Version:1 (25.0%)
Same OS:2 (50.0%)
From: slava_reg at nsys dot by Assigned: mysql (profile)
Status: Wont fix Package: MySQL related
PHP Version: 5.2.5 OS: any
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: slava_reg at nsys dot by
New email:
PHP Version: OS:

 

 [2008-02-14 13:00 UTC] slava_reg at nsys dot by
Description:
------------
Hi,

As I'm tired of patching various user-installed php-engines to work correctly with newer MySQL versions (4.1.x +) that require connection character set to be specified, I decided to solve the problem at the php level.
So, I patched both mysql and mysqli extensions (based on an idea found somewhere in internet).
Result is available at:

http://bubble.nsys.by/projects/patches/php/php-5.2.5-mysql-client-charset.patch

The patch introduces two more php.ini directives:
mysql.client_charset and
mysqli.client_charset

As those directives are optional, the patch shouldn't break any existing functionality, but it could *really* help users who's native language is not latin and who want to use some php-scripted engine with mysql 'out-of-the-box'.

Best,
Vladislav Bogdanov



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-01-01 23:55 UTC] jani@php.net
-Package: Feature/Change Request +Package: MySQL related
 [2011-01-06 16:19 UTC] uw@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: mysql
 [2011-01-06 16:19 UTC] uw@php.net
Not sure if this is really needed. It can be done in user land. Its a bit of a convenience feature. Not many votes for it... Andrey, Johannes...?
 [2011-01-31 11:52 UTC] johannes@php.net
-Status: Assigned +Status: Wont fix
 [2011-01-31 11:52 UTC] johannes@php.net
The application has to know the encoding being used, else some strange things might happen. We have seen the trouble in having this globally configurable when Gentoo decided to use Utf-8 for their MySQL installations by default instead of MySQL's default. I doubt you can make an application Utf-8 comaptible by just setting such a low-level switch (it won't affect the HTTP Content-type header or HTML forms, thus receiving data in a wrong encoding from the user, not re-encode it etc.)
 [2011-02-24 14:15 UTC] cavo at ynet dot sk
This is not about making application utf8 compatible. You can do this by "set names" query. But it may be redundant. For example: All my database is in utf8 encoding. All my pages have content-type utf8. All form posts from clients are in utf8. All strings I process in application are utf8. But what do I need to do right after I connect to database? - "set names utf8;" Why? Because if I don't, db will re-encode all strings to latin1. And PHP don't care. If I have 100 new connections to db per second, I need to 100 times run that query. Why if client and server could negotiate encoding in those 2 obliged packets? ( http://bugs.php.net/bug.php?id=54086 ). It's ok to set latin1 as default character set used by client to not affect existing applications (I believe mostly for those, who actualy don't know, what are they doing..). But I think it's very useful to have option to set encoding manualy via configuration option or in connect functions like: mysql_connect('localhost', 'user', 'pwd', true, MYSQL_CLIENT_ENCODING_UTF8);

Or am I somwhere wrong?

http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol#Client_Authentication_Packet
http://dev.mysql.com/doc/refman/5.5/en/server-options.html#option_mysqld_default-character-set
http://dev.mysql.com/doc/refman/5.5/en/server-options.html#option_mysqld_character-set-client-handshake
http://bugs.php.net/bug.php?id=54086
 [2011-10-18 12:58 UTC] andrey@php.net
mysqli has this. You can create a connection with mysqli_init() or just new mysql() and then call mysqli_options() or $link->options and set the charset to be used. It will be negotiated during the client-server handshake and there will be no additional query like SET NAMES. mysqli_options() works before connections is established, later it has no effect.
 [2013-02-06 03:09 UTC] shane dot bester at oracle dot com
I compiled my server with default charset of utf32.  Now I cannot connect at all, 
therefore cannot execute any SET NAMES command.  So, this needs fixing.

PHP Warning:  mysqli_connect(): (HY000/1231): Variable 'character_set_client' 
can't be set to the value of 'utf32' in X line Y
 [2013-02-06 03:15 UTC] shane dot bester at oracle dot com
in my above case, i can connect only if i start server with --skip-character-set-
client-handshake option
 [2013-02-06 11:27 UTC] andrey@php.net
1. AFAIK the MySQL parser can't use UTF32 this is why SET NAMES doesn't work
2. Executing SET NAMES is the most improper way to change character set
3. The proper way is to use mysqli_options(), which is mysqli only
4. ext/mysql is deprecated and won't get changed
5. Example
$c=mysqli_init();
$c->options(MYSQLI_SET_CHARSET_NAME, "utf8");
$c->connect(....);
during handshake utf8 will become the charset to be used to talk to the MySQL parser.  Or maybe in the future MySQL will have a parser that accepts UTF16 and UTF32. By using mysqli_options() there is no additional round-trip to the server and the client library knows which character set is really in use, thus mysqli_real_escape_string() will correctly.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 18 00:01:28 2024 UTC