| FILTER_SANITIZE_NUMBER_FLOAT non/sense [message #177007] |
Wed, 15 February 2012 18:57  |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Hi,
please shed some light on this, it looks like nonsense to me:
#------------------
strobel@s114-intel:~> php -a
Interactive shell
php > echo filter_var('456.999', FILTER_SANITIZE_NUMBER_FLOAT);
456999
php > echo filter_var('456,999', FILTER_SANITIZE_NUMBER_FLOAT);
456999
php >
#------------------
/Str.
|
|
|
|
| Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense [message #177009 is a reply to message #177007] |
Wed, 15 February 2012 20:05  |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(M. Strobel)
> please shed some light on this, it looks like nonsense to me:
>
> #------------------
> strobel@s114-intel:~> php -a
> Interactive shell
>
> php > echo filter_var('456.999', FILTER_SANITIZE_NUMBER_FLOAT);
> 456999
> php > echo filter_var('456,999', FILTER_SANITIZE_NUMBER_FLOAT);
> 456999
> php >
> #------------------
This filter has some options you can use (see manual for details):
$ php -r "echo filter_var('456.999', FILTER_SANITIZE_NUMBER_FLOAT,
FILTER_FLAG_ALLOW_FRACTION);"
456.999
$ php -r "echo filter_var('456,999', FILTER_SANITIZE_NUMBER_FLOAT,
FILTER_FLAG_ALLOW_THOUSAND);"
456,999
Micha
--
http://mfesser.de/blickwinkel
|
|
|
|
| Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense [message #177010 is a reply to message #177009] |
Wed, 15 February 2012 21:48 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 15.02.2012 21:05, schrieb Michael Fesser:
> .oO(M. Strobel)
>
>> please shed some light on this, it looks like nonsense to me:
>>
>> #------------------
>> strobel@s114-intel:~> php -a
>> Interactive shell
>>
>> php > echo filter_var('456.999', FILTER_SANITIZE_NUMBER_FLOAT);
>> 456999
>> php > echo filter_var('456,999', FILTER_SANITIZE_NUMBER_FLOAT);
>> 456999
>> php >
>> #------------------
>
> This filter has some options you can use (see manual for details):
>
> $ php -r "echo filter_var('456.999', FILTER_SANITIZE_NUMBER_FLOAT,
> FILTER_FLAG_ALLOW_FRACTION);"
> 456.999
>
Oh. The concept of float without fraction is new to me. I would read in an integer
instead.
> $ php -r "echo filter_var('456,999', FILTER_SANITIZE_NUMBER_FLOAT,
> FILTER_FLAG_ALLOW_THOUSAND);"
> 456,999
>
> Micha
>
Hm, it is still messed up, in the default setup it eats points and commas.
/Str.
|
|
|
|
| Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense [message #177011 is a reply to message #177010] |
Wed, 15 February 2012 22:48 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(M. Strobel)
> Oh. The concept of float without fraction is new to me. I would read in an integer
> instead.
>
>> $ php -r "echo filter_var('456,999', FILTER_SANITIZE_NUMBER_FLOAT,
>> FILTER_FLAG_ALLOW_THOUSAND);"
>> 456,999
>>
>> Micha
>>
>
> Hm, it is still messed up, in the default setup it eats points and commas.
Correct. These chars are optional, hence the options. From the manual:
| FILTER_SANITIZE_NUMBER_FLOAT [...]
| Remove all characters except digits, +- and optionally .,eE.
If you need these chars, you have to use one or more options.
Micha
--
http://mfesser.de/blickwinkel
|
|
|
|
| Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense [message #177014 is a reply to message #177011] |
Thu, 16 February 2012 11:53 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Michael Fesser schrieb:
>>> $ php -r "echo filter_var('456,999', FILTER_SANITIZE_NUMBER_FLOAT,
>>> FILTER_FLAG_ALLOW_THOUSAND);"
>>> 456,999
>> Hm, it is still messed up, in the default setup it eats points and commas.
> Correct. [...]
I consider this a very strange definition of "correct". The point (pun
intended) of floats is precisely to be able to have a decimal point. It
is absolutely ridiculous to filter that out by default. Do you have to
explicitly allow "@" when filtering e-mail addresses?
From the manual:
>
> | FILTER_SANITIZE_NUMBER_FLOAT [...]
> | Remove all characters except digits, +- and optionally .,eE.
^^^^^^^^^^^^^^^^
I would consider that appropriate when filtering for numbers in general,
but certainly not when explicitly dealing with floats. Is there a
rationale for this WTF?
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
| Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense [message #177015 is a reply to message #177014] |
Thu, 16 February 2012 12:34 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 16.02.2012 12:53, schrieb Thomas Mlynarczyk:
> Michael Fesser schrieb:
>
>>>> $ php -r "echo filter_var('456,999', FILTER_SANITIZE_NUMBER_FLOAT,
>>>> FILTER_FLAG_ALLOW_THOUSAND);"
>>>> 456,999
>>> Hm, it is still messed up, in the default setup it eats points and commas.
>> Correct. [...]
>
> I consider this a very strange definition of "correct". The point (pun intended) of
> floats is precisely to be able to have a decimal point. It is absolutely ridiculous
> to filter that out by default. Do you have to explicitly allow "@" when filtering
> e-mail addresses?
>
--cut
> Greetings,
> Thomas
I read this as "correct, it is messed up".
So we seem to agree this is ridiculous and unusable.
I wondered if there was some hidden secret - none so far.
/Str.
|
|
|
|
| Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense [message #177016 is a reply to message #177015] |
Thu, 16 February 2012 12:46 |
Captain Paralytic
Messages: 204
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Feb 16, 12:34 pm, "M. Strobel" <sorry_no_mail_h...@nowhere.dee>
wrote:
> So we seem to agree this is ridiculous and unusable.
Ridiculous maybe, but why is it unusable? If you apply the correct
options it will do what you want. In my mind that makes is usable!
|
|
|
|
| Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense [message #177017 is a reply to message #177015] |
Thu, 16 February 2012 12:49 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(M. Strobel)
> I read this as "correct, it is messed up".
It was meant as "correct as defined in the manual".
> So we seem to agree this is ridiculous and unusable.
It might be ridiculous, but why is it unusable? Just define the options
you need.
> I wondered if there was some hidden secret - none so far.
I could imagine one. The meaning of the separators in a float number
depends on the locale. Here in Germany for example the meaning is
reversed. So IMHO it makes sense to force the developer to think about
this potential issue and explicitly define the behaviour of this filter.
OK, most likely not the strongest reason ...
Micha
--
http://mfesser.de/blickwinkel
|
|
|
|
| Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense [message #177019 is a reply to message #177017] |
Thu, 16 February 2012 13:22 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Michael Fesser schrieb:
> It might be ridiculous, but why is it unusable? Just define the options
> you need.
Technically you are right. It is usable. Just as a toothbrush is usable
to clean the floor of a building. Possible, but awkward.
>> I wondered if there was some hidden secret - none so far.
>
> I could imagine one. The meaning of the separators in a float number
> depends on the locale. Here in Germany for example the meaning is
> reversed. So IMHO it makes sense to force the developer to think about
> this potential issue and explicitly define the behaviour of this filter.
Indeed, that could be a reason. But then it would have been better to
make the "option" mandatory: you *have* to specify some value, if not --
error. Then the programmer would be forced to deal with the issue. The
way it is now, however, it's just a source of confusion, frustration and
hours of debugging. (Sure, just RTFM, but who in their right mind would
expect FILTER_SANITIZE_NUMBER_FLOAT to swallow up decimal separators?)
On the other hand I seriously question the concept of a server side
locale in the context of the world wide web. If locale must be, then it
ought to be the client's locale.
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
| Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense [message #177020 is a reply to message #177019] |
Thu, 16 February 2012 14:16 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Thu, 16 Feb 2012 14:22:08 +0100, Thomas Mlynarczyk wrote:
> On the other hand I seriously question the concept of a server side
> locale in the context of the world wide web. If locale must be, then it
> ought to be the client's locale.
Perhaps, but that just means you should use the client's locale when
validating things like dates and numbers on the server. Of course this
assumes you know the client's locale.
You still need to do your validation server side. You can't trust client
side validation.
(Jerry may be posting a similar comment as I write this)
Rgds
Denis McMahon
|
|
|
|
| Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense [message #177021 is a reply to message #177020] |
Thu, 16 February 2012 15:36 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 16 Feb 2012 14:16:02 GMT, Denis McMahon wrote:
> On Thu, 16 Feb 2012 14:22:08 +0100, Thomas Mlynarczyk wrote:
>
>> On the other hand I seriously question the concept of a server side
>> locale in the context of the world wide web. If locale must be, then it
>> ought to be the client's locale.
>
> Perhaps, but that just means you should use the client's locale when
> validating things like dates and numbers on the server. Of course this
> assumes you know the client's locale.
which client? And how would PHP know if by "client", you mean the far
end of an http connection?
> You still need to do your validation server side. You can't trust client
> side validation.
very true.
--
34. I will not turn into a snake. It never helps.
--Peter Anspach's list of things to do as an Evil Overlord
|
|
|
|
| Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense [message #177022 is a reply to message #177020] |
Thu, 16 February 2012 16:32 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Denis McMahon schrieb:
> On Thu, 16 Feb 2012 14:22:08 +0100, Thomas Mlynarczyk wrote:
>
>> On the other hand I seriously question the concept of a server side
>> locale in the context of the world wide web. If locale must be, then it
>> ought to be the client's locale.
>
> Perhaps, but that just means you should use the client's locale when
> validating things like dates and numbers on the server. Of course this
> assumes you know the client's locale.
True. The only reliable way to do this would be to simply ask the client
and then maybe store their locale in a cookie. My point was that any
"server locale" is completely useless since there is in general no
reliable correlation between the server's and the client's location.
> You still need to do your validation server side. You can't trust client
> side validation.
I never said the contrary. Nor was I referring to anything "done
clientside". I just meant that the server's locale is of no use to the
client who possibly uses a different locale.
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
| Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense [message #177023 is a reply to message #177021] |
Thu, 16 February 2012 16:38 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Peter H. Coffin schrieb:
> which client? And how would PHP know if by "client", you mean the far
> end of an http connection?
Precisely. The client could be anyone and anything located anywhere in
the world. So what sense does it make to set a specific locale on the
server?
>> You still need to do your validation server side. You can't trust client
>> side validation.
>
> very true.
I never said the contrary and did not address the subject of validation
at all. I simply meant that when writing portable PHP code, having to
take care of different server locales may be extra work without any
benefit to the end users whose locales may be different from the
server's anyway.
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
| Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense [message #177024 is a reply to message #177022] |
Thu, 16 February 2012 17:02 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 16.02.2012 17:32, schrieb Thomas Mlynarczyk:
> Denis McMahon schrieb:
>> On Thu, 16 Feb 2012 14:22:08 +0100, Thomas Mlynarczyk wrote:
>>
>>> On the other hand I seriously question the concept of a server side
>>> locale in the context of the world wide web. If locale must be, then it
>>> ought to be the client's locale.
>>
>> Perhaps, but that just means you should use the client's locale when validating
>> things like dates and numbers on the server. Of course this assumes you know the
>> client's locale.
>
> True. The only reliable way to do this would be to simply ask the client and then
> maybe store their locale in a cookie. My point was that any "server locale" is
> completely useless since there is in general no reliable correlation between the
> server's and the client's location.
---cut
> Greetings,
> Thomas
>
That's a good point, the question about the client side locale seems to be unsolved,
but not discussed very often. You could use the HTTP Accept-Language header, but I
did not see it mentioned very often in the web.
/Str.
|
|
|
|
| Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense [message #177034 is a reply to message #177024] |
Fri, 17 February 2012 11:25 |
Captain Paralytic
Messages: 204
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Feb 16, 5:02 pm, "M. Strobel" <sorry_no_mail_h...@nowhere.dee>
wrote:
> Am 16.02.2012 17:32, schrieb Thomas Mlynarczyk:
>
>> Denis McMahon schrieb:
>>> On Thu, 16 Feb 2012 14:22:08 +0100, Thomas Mlynarczyk wrote:
>
>>>> On the other hand I seriously question the concept of a server side
>>>> locale in the context of the world wide web. If locale must be, then it
>>>> ought to be the client's locale.
>
>>> Perhaps, but that just means you should use the client's locale when validating
>>> things like dates and numbers on the server. Of course this assumes you know the
>>> client's locale.
>
>> True. The only reliable way to do this would be to simply ask the client and then
>> maybe store their locale in a cookie. My point was that any "server locale" is
>> completely useless since there is in general no reliable correlation between the
>> server's and the client's location.
>
> ---cut
>
>> Greetings,
>> Thomas
>
> That's a good point, the question about the client side locale seems to be unsolved,
> but not discussed very often. You could use the HTTP Accept-Language header, but I
> did not see it mentioned very often in the web.
How does Language help with Locale?
When I am VPNed into a server that is located in Belgium, Google keeps
asking me if I want to switch the google I am using. I am still in the
UK and I still want English, but the IP address from which my request
is coming is still a Belgium one.
When I am remoted into an actual machine that is in Belgium, the
language of the machine is set to French, but I am in the UK.
|
|
|
|
| Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense [message #177040 is a reply to message #177034] |
Fri, 17 February 2012 17:19 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 17.02.2012 12:25, schrieb Captain Paralytic:
> On Feb 16, 5:02 pm, "M. Strobel" <sorry_no_mail_h...@nowhere.dee>
> wrote:
>> Am 16.02.2012 17:32, schrieb Thomas Mlynarczyk:
>>
>>> Denis McMahon schrieb:
>>>> On Thu, 16 Feb 2012 14:22:08 +0100, Thomas Mlynarczyk wrote:
>>
>>>> > On the other hand I seriously question the concept of a server side
>>>> > locale in the context of the world wide web. If locale must be, then it
>>>> > ought to be the client's locale.
>>
>>>> Perhaps, but that just means you should use the client's locale when validating
>>>> things like dates and numbers on the server. Of course this assumes you know the
>>>> client's locale.
>>
>>> True. The only reliable way to do this would be to simply ask the client and then
>>> maybe store their locale in a cookie. My point was that any "server locale" is
>>> completely useless since there is in general no reliable correlation between the
>>> server's and the client's location.
>>
>> ---cut
>>
>>> Greetings,
>>> Thomas
>>
>> That's a good point, the question about the client side locale seems to be unsolved,
>> but not discussed very often. You could use the HTTP Accept-Language header, but I
>> did not see it mentioned very often in the web.
>
> How does Language help with Locale?
>
> When I am VPNed into a server that is located in Belgium, Google keeps
> asking me if I want to switch the google I am using. I am still in the
> UK and I still want English, but the IP address from which my request
> is coming is still a Belgium one.
>
> When I am remoted into an actual machine that is in Belgium, the
> language of the machine is set to French, but I am in the UK.
>
When you are walking the street in France you must be prepared to be addressed in
French.
When you are on a french server you must read the french messages.
But anyway, we are talking about client locale in HTTP and HTML, you are talking
about remote logins.
/Str.
|
|
|
|
| Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense [message #177046 is a reply to message #177034] |
Fri, 17 February 2012 19:35 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(Captain Paralytic)
> On Feb 16, 5:02 pm, "M. Strobel" <sorry_no_mail_h...@nowhere.dee>
> wrote:
>>
>> That's a good point, the question about the client side locale seems to be unsolved,
>> but not discussed very often. You could use the HTTP Accept-Language header, but I
>> did not see it mentioned very often in the web.
>
> How does Language help with Locale?
>
> When I am VPNed into a server that is located in Belgium, Google keeps
> asking me if I want to switch the google I am using. I am still in the
> UK and I still want English, but the IP address from which my request
> is coming is still a Belgium one.
>
> When I am remoted into an actual machine that is in Belgium, the
> language of the machine is set to French, but I am in the UK.
But this has nothing to do with the HTTP Accept-Language header, which
depends on browser settings. If some services rely on the IP address and
try to geolocate them, it's their fault and you should complain there.
Micha
--
http://mfesser.de/blickwinkel
|
|
|
|
| Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense [message #177090 is a reply to message #177034] |
Mon, 20 February 2012 09:46 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/17/2012 12:25 PM, Captain Paralytic wrote:
> How does Language help with Locale?
>
> When I am VPNed into a server that is located in Belgium, Google keeps
> asking me if I want to switch the google I am using. I am still in the
> UK and I still want English, but the IP address from which my request
> is coming is still a Belgium one.
>
> When I am remoted into an actual machine that is in Belgium, the
> language of the machine is set to French, but I am in the UK.
>
Hi Captain,
Annoying, isn't it?
I use the following to keep Google's overactive help in check (a little):
http://www.google.com/ncr
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense [message #177091 is a reply to message #177040] |
Mon, 20 February 2012 12:31 |
Captain Paralytic
Messages: 204
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Feb 17, 5:19 pm, "M. Strobel" <sorry_no_mail_h...@nowhere.dee>
wrote:
> Am 17.02.2012 12:25, schrieb Captain Paralytic:
>
>
>
>
>
>
>
>
>
>> On Feb 16, 5:02 pm, "M. Strobel" <sorry_no_mail_h...@nowhere.dee>
>> wrote:
>>> Am 16.02.2012 17:32, schrieb Thomas Mlynarczyk:
>
>>>> Denis McMahon schrieb:
>>>> > On Thu, 16 Feb 2012 14:22:08 +0100, Thomas Mlynarczyk wrote:
>
>>>> >> On the other hand I seriously question the concept of a server side
>>>> >> locale in the context of the world wide web. If locale must be, then it
>>>> >> ought to be the client's locale.
>
>>>> > Perhaps, but that just means you should use the client's locale when validating
>>>> > things like dates and numbers on the server. Of course this assumes you know the
>>>> > client's locale.
>
>>>> True. The only reliable way to do this would be to simply ask the client and then
>>>> maybe store their locale in a cookie. My point was that any "server locale" is
>>>> completely useless since there is in general no reliable correlation between the
>>>> server's and the client's location.
>
>>> ---cut
>
>>>> Greetings,
>>>> Thomas
>
>>> That's a good point, the question about the client side locale seems to be unsolved,
>>> but not discussed very often. You could use the HTTP Accept-Language header, but I
>>> did not see it mentioned very often in the web.
>
>> How does Language help with Locale?
>
>> When I am VPNed into a server that is located in Belgium, Google keeps
>> asking me if I want to switch the google I am using. I am still in the
>> UK and I still want English, but the IP address from which my request
>> is coming is still a Belgium one.
>
>> When I am remoted into an actual machine that is in Belgium, the
>> language of the machine is set to French, but I am in the UK.
>
> When you are walking the street in France you must be prepared to be addressed in
> French.
>
> When you are on a french server you must read the french messages.
>
> But anyway, we are talking about client locale in HTTP and HTML, you are talking
> about remote logins.
No, I am talking about client locale. The client I am using is located
in the UK. The ip address that sites see is in Belgium. If sites make
an assumption that the client request that is presenting an IP address
that is based in Belgium requires them to address a user using Belgium
conventions, then they are wrong.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]