Page 1 of 1

Problem special characters saved with php and read in delphi

Posted: Sun 12 Apr 2009 16:47
by fisad
I have some tables in mysql server where save information with special characters like ('á, 'e, 'i'...' å'ä'ö...'). Whit PHP code not problem for get good result. But from Delphi, with query component connected to mysql server, the information is showing wrong like 'Å/n' not 'í'.
I know php code with stripslashes and others for to correct this, but I don't know if is possible in slq statement for Delphi 2007 query component. I use MyDac components but they don't have procedure or code for get good result.

I don't have any problem to read data from data base table from mysql server with Delphi application. When I write data to server from Delphi application, I can to use special characters and to save to data base and retry display not problem for show correct information.
My problem is with old data saved in data base from my web page, this information was saved with stripslashes and other php code from php script, when I read and write information from mysql data base with php script from my web page, I use php code for transformation of special characters and the result is ok, but I need same from Delphi application, here aren't problem with character set, the basic problem is read information saved from web page.
For example: From web page, I save data like 'información' or 'frånskild' and when read this from web page I can see 'información' and 'frånskild' but, from the other hand, when I make same from Delphi application, I save 'información' and 'frånskild' and when I read, the result show 'información' and ´frånskild', not problem. But , but, If I read data saved from my web page, Delphi application show incorrect display.

Can help me?, Anybody.

Posted: Mon 13 Apr 2009 13:31
by Dimon
This problem is connected with php converting data to Utf8, but not with MyDAC.
Most probably the problem is that the php application converts data twice.
To solve the problem execute the "SET NAMES 'utf8'" query right after connecting to the db.

Posted: Mon 13 Apr 2009 14:17
by fisad
I connect to server and
I execute query for "SET NAMES 'utf8'" before query for data tables and the result is wrong

For clear understand

Posted: Mon 13 Apr 2009 15:03
by fisad
php code display case information with htmlspecialchars and mysql_escape_string functions and save case information with mysql_escape_string.

If I work only from Delphi, not problem, but when I save some special characters from delphi application to data base and read that information from web page, the special characters are show wrong. From delphi not problem for read that information ok.

MyDac is for work with mysql data base from delphi, only?

For now, I can't get good display from web page with information saved from delphi application.

One way solved!!

Posted: Mon 13 Apr 2009 17:02
by fisad
I implement an encodeUTF8 function before post data to server and I can read good data from web page.

Now, I need implement another way function decodeUTF8 for data read from server before show in data components, but I don't like to modify source of your library.

The problem is in data decode from server to delphi application.

Posted: Tue 14 Apr 2009 13:14
by Dimon
This problem is arised because the php application converts data twice. To be sure you can try to open the MySQL table using ADO or BDE and check the result.
Please, make sure that you execute the "SET NAMES 'utf8'" query in your php application.

Problem Solved

Posted: Wed 15 Apr 2009 02:28
by fisad
I try four way, AnyDac, MyDac, Zeos and Mysql forum library implementation, but all get wrong display, not wrong data, only bad component display.

The better solution for me was implement two functions in delphi, one for decodeUTF8 from Dataset for correct display in components and grid, and another encodeUFT8 for changed fields to save data from delphi application to server.

This way is independent from type of work with php code and Character sets of mysql server. I can use any type of special characters and don't have any problem anymore.

Thanks a lot for your assistans y help.

Posted: Wed 15 Apr 2009 06:58
by Dimon
It is good to see that this problem has been solved. If any other questions come up, please contact me.