php-general Digest 18 Mar 2013 15:09:07 -0000 Issue 8168
Topics (messages 320625 through 320630):
PHP 5.4.13 and PHP 5.3.23 released!
320625 by: Stas Malyshev
significance of escape character in string in PHP
320626 by: Norah Jones
320627 by: Ken Robinson
320628 by: Sebastian Krebs
320630 by: Matijn Woudt
Re: variable type - conversion/checking
320629 by: Samuel Lopes Grigolato
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
The PHP development team announces the immediate availability of PHP
5.4.13 and PHP 5.3.23. These releases fix about 15 bugs, including fixes
for CVE-2013-1643 and CVE-2013-1635. All users of
PHP are encouraged to upgrade to PHP 5.4.13. PHP 5.3.23 is recommended
for those wishing to remain on the 5.3 series.
The full list of changes are recorded in the ChangeLog on
http://www.php.net/ChangeLog-5.php
For source downloads of PHP 5.4.13 and PHP 5.3.23 please visit our
downloads page at http://www.php.net/downloads.php
Windows binaries can be found on http://windows.php.net/download/
Stanislav Malyshev Johannes Schlüter
PHP 5.4 Release Master PHP 5.3 Release Master
--- End Message ---
--- Begin Message ---
I am having an string which was have few ' (single quote) and few " (double
quotes) and was not able to insert into the mysql database. I have replaced
them with \' and \" and everything is fine.
Though this are fine now but don't understand the working and I could have
missed few corner cases also. Please suggest the working and also if there is
some better way to achieve this.
--- End Message ---
--- Begin Message ---
On 18.03.2013 09:10, Norah Jones wrote:
I am having an string which was have few ' (single quote) and few "
(double quotes) and was not able to insert into the mysql database. I
have replaced them with \' and \" and everything is fine.
Though this are fine now but don't understand the working and I could
have missed few corner cases also. Please suggest the working and
also
if there is some better way to achieve this.
You should be using either mysql_real_escape_string or
mysqli_real_escape_string (preferably the later) depending on how you're
accessing the DB.
Ken
--- End Message ---
--- Begin Message ---
2013/3/18 Ken Robinson <kenrb...@rbnsn.com>
>
>
> On 18.03.2013 09:10, Norah Jones wrote:
>
>> I am having an string which was have few ' (single quote) and few "
>> (double quotes) and was not able to insert into the mysql database. I
>> have replaced them with \' and \" and everything is fine.
>> Though this are fine now but don't understand the working and I could
>> have missed few corner cases also. Please suggest the working and also
>> if there is some better way to achieve this.
>>
>
> You should be using either mysql_real_escape_string or
> mysqli_real_escape_string (preferably the later) depending on how you're
> accessing the DB.
You shouldn't use ext/mysql at all!
Use prepared statements with PDO_MYSQL or MySQLi
>
>
> Ken
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
github.com/KingCrunch
--- End Message ---
--- Begin Message ---
On Mon, Mar 18, 2013 at 2:19 PM, Sebastian Krebs <krebs....@gmail.com>wrote:
> 2013/3/18 Ken Robinson <kenrb...@rbnsn.com>
>
> >
> >
> > On 18.03.2013 09:10, Norah Jones wrote:
> >
> >> I am having an string which was have few ' (single quote) and few "
> >> (double quotes) and was not able to insert into the mysql database. I
> >> have replaced them with \' and \" and everything is fine.
> >> Though this are fine now but don't understand the working and I could
> >> have missed few corner cases also. Please suggest the working and also
> >> if there is some better way to achieve this.
> >>
> >
> > You should be using either mysql_real_escape_string or
> > mysqli_real_escape_string (preferably the later) depending on how you're
> > accessing the DB.
>
>
> You shouldn't use ext/mysql at all!
> Use prepared statements with PDO_MYSQL or MySQLi
>
>
And here comes the flame war again...
--- End Message ---
--- Begin Message ---
Sorry if I'm missing something, there's a lot of replies after my first
post on this thread.
Is there something wrong with the "floor()" approach? I liked the regex
solution but isn't it more expensive and more verbose than just doing a
well commented "is_numeric" plus "floor/ceil" math?
Just trying to understand the motivations behind the preferences.
Thanks.
On Sun, Mar 17, 2013 at 7:17 PM, Matijn Woudt <tijn...@gmail.com> wrote:
> On Sun, Mar 17, 2013 at 10:20 PM, Maciek Sokolewicz <
> maciek.sokolew...@gmail.com> wrote:
>
> > On 16-3-2013 19:20, Matijn Woudt wrote:
> >
> >> On Sat, Mar 16, 2013 at 6:52 PM, Maciek Sokolewicz <
> >> maciek.sokolew...@gmail.com> wrote:
> >>
> >> Hi,
> >>>
> >>>>
> >>>> I have tried to find a way to check if a character string is possible
> to
> >>>> test whether it is convertible to an intger !
> >>>>
> >>>> any suggestion ?
> >>>>
> >>>> BR georg
> >>>>
> >>>>
> >>> All responses in this thread have been very nice; but you could also
> try
> >>> a
> >>> much simpler 2-step check:
> >>>
> >>> 1. is_numeric
> >>> 2. if true > check if there's a decimal character in the string:
> >>>
> >>> if(is_numeric($str) && false === strpos('.', $str)) {
> >>> // it's an int for sure
> >>> } else {
> >>> // might be a number, but it's definitly not an int
> >>>
> >>> }
> >>>
> >>>
> >> Wrong. is_numeric will accept 1e1, which is a float, so you would need
> to
> >> check for e or E too.
> >>
> >> - Matijn
> >>
> >> Although in theory I agree, indeed any e* number is treated as a
> > floating point number. However, considering the exponent and the base are
> > forced to be integer numbers (due to exclusion of decimal points), in the
> > real number system, you will *always* end up with a natural number, i.e.
> > integer. Regardless of your input.
> >
> > So as a result, the input could always be interpreted as an integer,
> > without any precision-loss using the method above.
> > - Tul
> >
>
> Except... that it might not fit in an 32 or 64 bit integer, which would
> lead to precision loss.
>
> - Matijn
>
--- End Message ---
