Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #4824 > unrolled thread

FILTER_SANITIZE_NUMBER_FLOAT non/sense

Back to article view | Back to comp.lang.php

Contents

  FILTER_SANITIZE_NUMBER_FLOAT non/sense "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-02-15 19:57 +0100
    Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense Michael Fesser <netizen@gmx.de> - 2012-02-15 21:05 +0100
      Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-02-15 22:48 +0100
        Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense Michael Fesser <netizen@gmx.de> - 2012-02-15 23:48 +0100
          Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-02-16 12:53 +0100
            Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-02-16 13:34 +0100
              Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense Captain Paralytic <paul_lautman@yahoo.com> - 2012-02-16 04:46 -0800
              Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense Michael Fesser <netizen@gmx.de> - 2012-02-16 13:49 +0100
                Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-02-16 14:22 +0100
                  Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense Denis McMahon <denismfmcmahon@gmail.com> - 2012-02-16 14:16 +0000
                    Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense "Peter H. Coffin" <hellsop@ninehells.com> - 2012-02-16 09:36 -0600
                      Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-02-16 17:38 +0100
                    Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-02-16 17:32 +0100
                      Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-02-16 18:02 +0100
                        Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense Captain Paralytic <paul_lautman@yahoo.com> - 2012-02-17 03:25 -0800
                          Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-02-17 18:19 +0100
                            Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense Captain Paralytic <paul_lautman@yahoo.com> - 2012-02-20 04:31 -0800
                          Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense Michael Fesser <netizen@gmx.de> - 2012-02-17 20:35 +0100
                          Re: FILTER_SANITIZE_NUMBER_FLOAT non/sense Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-02-20 10:46 +0100

#4824 — FILTER_SANITIZE_NUMBER_FLOAT non/sense

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.

[toc] | [next] | [standalone]

#4826

.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

[toc] | [prev] | [next] | [standalone]

#4827

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.

[toc] | [prev] | [next] | [standalone]

#4828

.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

[toc] | [prev] | [next] | [standalone]

#4831

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)

[toc] | [prev] | [next] | [standalone]

#4832

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.

[toc] | [prev] | [next] | [standalone]

#4833

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!

[toc] | [prev] | [next] | [standalone]

#4834

.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

[toc] | [prev] | [next] | [standalone]

#4836

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)

[toc] | [prev] | [next] | [standalone]

#4837

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

[toc] | [prev] | [next] | [standalone]

#4838

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

[toc] | [prev] | [next] | [standalone]

#4840

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)

[toc] | [prev] | [next] | [standalone]

#4839

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)

[toc] | [prev] | [next] | [standalone]

#4841

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.

[toc] | [prev] | [next] | [standalone]

#4851

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.

[toc] | [prev] | [next] | [standalone]

#4857

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.

[toc] | [prev] | [next] | [standalone]

#4908

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.

[toc] | [prev] | [next] | [standalone]

#4863

.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

[toc] | [prev] | [next] | [standalone]

#4907

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web