Re: addslashes(): Is it multi-byte safe?

On 2003.Mar.1, at 21:14 Asia/Tokyo, Jean-Christian Imbeault wrote:

Moriyoshi Koizumi wrote:

That's the case as long as the browser precisely sends form contents as EUC-JP encoded strings and no automagical encoding conversion is performed there by mbstring module (I mean output_handler=mb_output_handler in ini settings). Then you have to prepare the page contents to be encoded in EUC-JP.

Ok, no output_handler=mb_output_handler in my php.ini :) I am using the recommended php.ini (not the default) and it has these settings by default: ;mbstring.language = Japanese ;mbstring.internal_encoding = EUC-JP ;mbstring.http_input = auto ;mbstring.http_output = SJIS ;mbstring.encoding_translation = Off

You need to un-escape these in php.ini (take out the semi-colons) and turn the encoding translation on if you want it to work. Then the form input will be converted to EUC before your script gets it and you won't have problems with addslashes(). But be careful if you already have a DB full of SJIS encoded Japanese. You'll probably want to convert it to EUC before you switch this on to avoid a big mess.

I see that mbstring.encoding_translation = Off ... and a phpinfo() shows that I have compiled with: --enable-mbstring-enc-trans But it also says:

                               Local Global

mbstring.encoding_translation Off Off I had assumed taht my compile time option would overide the php.ini setting but I guess I was wrong? If I want all encoming data will be translated to internal_encoding I guess I need to change this pnp.ini setting?

But it's very probable that clients send form contents in UTF-8 when GET method is used..

In which case I am safe :) But then again anyone who would want to try an SQL injection attack might try and send some SJIS ... better safe than sorry :) Jc -- PHP Internationalization Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php