Re: Re: mysql_escape() issue (Was: [PHP-DEV] RFC: ext/mysql deprecation)
| From: | Rasmus Lerdorf | Date: | Fri, 16 Nov 2012 17:42:33 +0000 |
| Subject: | Re: Re: mysql_escape() issue (Was: [PHP-DEV] RFC: ext/mysql deprecation) | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-63932@lists.php.net to get a copy of this message | ||
On 11/16/2012 09:32 AM, Patrick ALLAERT wrote:
> 2012/11/16 Rasmus Lerdorf <rasmus@lerdorf.com>:
>> On 11/16/2012 02:18 AM, Patrick ALLAERT wrote:
>>> In eZ Publish CMS, we have recently removed [1] support for the mysql
>>> handler in favour of the mysqli one and as such, we have no more
>>> mysql_*() functions calls except for the above use case where we rely
>>> on mysql_escape().
>>
>> I suppose you mean mysql_real_escape_string() here. There is no
>> mysql_escape() function and mysql_escape_string() is already marked as
>> deprecated as of 5.3.
>>
>> -Rasmus
>
> Sorry, I meant mysql_escape_string().
> I missed the fact it was already deprecated and as such, we have an
> issue here in our code base since nor mysql_real_escape_string() nor
> mysqli_real_escape_string() fits our use case as we are using it when
> we have to generate an SQL file with queries to be executed on another
> box. Not having access to a database prevents us to have a link which
> is required by those functions.
But without a link you don't know which charset the db is in and
therefore you can't reliably escape a query. In your case you can do a
custom escape thing based on the fact that you might know the
destination charset, but PHP on its own can't.
-Rasmus