-3

i have a script with a form where im uploading strings into my database. before upload, i want to capitalize first letters. the string can contain foreign chars like éáőú. im using uft8 by default everywhere, and my script is working just fine, every time with no exception. BUT when i open phpmyadmin, even if i dont do anything in it, somehow changes my simple script, and the conversion to uppercase wont work anymore, 

string 'aáeéoő' (length=9)

becomes this:

string 'A�e�o�' (length=9)

and it only works again if i restart wamp.

im using ucwords, and strolower on the string, and as i said it is working perfectly. is it possible when i open up phpmyadmin, it changes the character coding of php ?

Ninet9
  • 163
  • 2
  • 11
  • 3
    `$_POST` has no relation to a DB.. – chris85 Mar 20 '17 at 01:53
  • i didnt mention database at all ! – Ninet9 Mar 20 '17 at 01:54
  • 1
    What are you doing with phpmyadmin?? `phpMyAdmin is a free and open source tool written in PHP intended to handle the administration of MySQL or MariaDB with the use of a web browser` – chris85 Mar 20 '17 at 01:54
  • Check the exact bytes of those strings, may be that might give some clue. Other than that - `ucwords` is not designed to work with multibyte encodings. – zerkms Mar 20 '17 at 01:54
  • well, still the question why is it working perfectly, until i open the phpmyadmin in a different window ? – Ninet9 Mar 20 '17 at 01:57
  • chris , why i shouldnt ??? actually doing some sql querys, but i just open it up, and messes my script up – Ninet9 Mar 20 '17 at 01:58
  • You are showing `$_POST`, that has no relation to phpmyadmin, unless you are inserting the data to a db then outputting it later? – chris85 Mar 20 '17 at 01:59
  • chris you are not getting it. i have firefox opened in two different window, i the first one i using my app, uploading names etc, while im working on some other things in the second opened window on phpmyadmin. still the question is how can it affect my running script only when open up phpmyadmin. two diff computer i have the same problem – Ninet9 Mar 20 '17 at 02:02
  • I don't know it sounds like an incomplete question to me. I dont see how you have `$_POST` interacting with `phpmyadmin`. – chris85 Mar 20 '17 at 02:05
  • I'm betting on that you're trying to do a db-related operation and not passing UTF-8 to the connection. You see correct characters in one window, but when it reaches the db, it gets like that. I don't think you're telling us everything and the question lacks code/detail. – Funk Forty Niner Mar 20 '17 at 02:08
  • Possible duplicate of [UTF-8 all the way through](http://stackoverflow.com/questions/279170/utf-8-all-the-way-through) – Funk Forty Niner Mar 20 '17 at 02:10
  • fred, im getting this problem before it gets to the database !! – Ninet9 Mar 20 '17 at 02:10
  • why in the world are you using `ucwords` and `strtolower` in `$name = ucwords(strtolower($_POST['form_newname']));` – DarkSideKillaz Mar 20 '17 at 02:11
  • @chris85 there's something in between they haven't mentioned/showed us. – Funk Forty Niner Mar 20 '17 at 02:12
  • 1
    @Fred-ii- Yes, defiantly something not posted that is the cause. – chris85 Mar 20 '17 at 02:13
  • 1
    php and phpmyadmin are two totally different animals. I can't see how your var_dump has anything to do with phpmyadmin. – Funk Forty Niner Mar 20 '17 at 02:13
  • @DarkSideKillaz that actually makes sense. Make everything lowercase, then capitalize the first letters. – chris85 Mar 20 '17 at 02:14
  • ok ppl. i input those chars to the form, i try to capitalize first letters, and works just fine. but as soon i open up phpmyadmin, and reenter the same damned chars to my app in the other opened window, the encoding changes until i restrart wamp. i can re enter these chars 1000times, and always get the desired results, but as soon i open phpmyadmin, it wont work anymore.i dont know how to explain it better – Ninet9 Mar 20 '17 at 02:20
  • @chris85 k then he should use `ucfirst($data);` would `strtolower` or `ucwords` have a problem with different symbols – DarkSideKillaz Mar 20 '17 at 02:21
  • Your answer is most likely [here...](http://stackoverflow.com/questions/279170/utf-8-all-the-way-through) go through that, or get on Team Viewer. There isn't anything I can add to this question, good luck; sincerely. – Funk Forty Niner Mar 20 '17 at 02:23
  • @DarkSideKillaz I think they all are multi-byte unsafe. The `ucfirst` manual has the same example, http://php.net/manual/en/function.ucfirst.php. You need to lowercase to normalize. – chris85 Mar 20 '17 at 02:27
  • If restarting WAMP fixes it I'd say the issue lies there. I have no experience with WAMP. – chris85 Mar 20 '17 at 02:34

1 Answers1

0

If the problem is with database interactions, see the original answer, below.

If it's not the database connection that's the causing issue, then likely phpmyadmin is causing some global setting in the web server environment (e.g. some shared library is being reloaded with new settings, or a change to the path is causing functions to be referenced in different modules)... something is getting dynamically changed in the web server environment when phpmyadmin is executed. And that's impacting the application.

For investigating this, I suggest using phpinfo to dump/display/capture the PHP environment settings. Temporarily add that to the script in the app, and save that snapshot.

Start phpmyadmin, or whatever is causing the problem, ...

Then run the script in the app again, and dump/display/capture the PHP environment settings, and compare that to the environment from the first snapshot.

Likely, something is going to be different, something to do with characterset conversions, e.g. causing iconv to be used instead of mbstring or vice versa, something to do with characterset conversions. Or with conflicting/overwriting HTTP headers.

I'd investigate the HTTP headers as well as the entire page source from both before and after starting phpmyadmin.

Another possibility is that its not the server at all, its wonkiness with the client web browser.

I suggest running your app in one browser, whichever browser you are using for your app.

And then start phpmyadmin from an entirely different browser. For example, use Chrome for phpmyadmin if you are using Firefox for your app script. And see if the problem appears in the app.

This will help narrow down whether issue is with the server (apache), or with the browser.

If it's the database that's causing the issue...

ORIGINAL ANSWER

Sounds to me like starting phpmyadmin is causing execution of SET GLOBAL character_set_client, SET GLOBAL character_set_session, and/or SET GLOBAL character_set_results statements, changing some system variable that can be modified dynamically.

The next time the app connects to the database, the new MySQL session inherits the values of the system variables from the global settings.

Restarting mysqld fixes the problem, because the global variable is back to the original setting, or the default. And those values are what the app is expecting.

After the global setting are changed, the app isn't expecting those new settings for the MySQL connection/session.

For investigating this, I would add a query to the app to get the settings of the session variables, e.g. 

SHOW VARIABLES LIKE 'character%'

and dump/display/capture the return from that.

The do whatever you do with phpmyadmin that causes the problem in the app, and then run the app again, and dump/display/capture the return from the SHOW VARIABLES LIKE 'character%' again.

I suspect that when those are compared, there is going to be a difference.

If there is a difference, then

  • figure out what is causing phpmyadmin to execute those statements, and change it so it doesn't do that any more.

That is only a partial solution, because the app is still vulnerable to any other session issuing SET GLOBAL system_variable statements. To insulate the application:

  • modify the app to specifically set the system variables for the session, e.g. character_set_client, character_set_connection, character_set_results.

The old school pattern for doing that was for the app to issue a SET NAMES statement right after the connection is established.

But check the interface library which you are using, to see what the recommended pattern is. For example, for mysqli_, the recommendation is to not use SET NAMES and to instead use mysqli_set_charset http://php.net/manual/en/mysqli.set-charset.php

This is all just a guess. It's not possible to make a definitive diagnosis from the information provided.

Reference: https://dev.mysql.com/doc/refman/5.7/en/charset-connection.html

spencer7593
  • 106,611
  • 15
  • 112
  • 140