Re: First stupid post of the year. [SOLVED]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, January 3, 2008 11:39 am, tedd wrote:
> At 4:24 PM +0100 1/3/08, Nisse Engström wrote:
>>On Wed, 2 Jan 2008 19:36:56 -0500, tedd wrote:
>>
>>>  To find out, I did put the operation through FireFox and reversed
>>> the
>>>  POST/GET operations to get a look at the string -- it is:
>>>
>>>  %C2%A0%C2%A0%C2%A0Z%C2%A0%C2%A0%C2%A0  < where Z is the value
>>> passed.
>>>
>>>  Now, C2 (HEX) is a linefeed (194 DEC)
>>>
>>>  And, A0 (HEX) is a non-breaking space (160 DEC;) which is a &nbsp;
>>
>>Not quite. <A0> is non-breaking space in *some* character
>>encodings, such as the ISO-8859-... encodings. It may
>>be different in other encodings. In UTF-8, it is <C2 A0>,
>>which is exactly what you're seing.
>
> Well considering that UTF-8 encompasses/includes all of the code
> points found ISO-8859, then I think that both encodings would
> reference the same character. After all, if they didn't then what's
> the point of Unicode?
>
> Now, one can argue how many bytes are needed to represent a character
> in what encoding, but that doesn't change the character. In the end,
> I believe that <A0> is the same regardless of what charset or
> encoding you're using.
>
> I just don't understand where C2 comes from or why it's there. I
> would think that <00 A0> would be more appropriate.
>
>>  > Therefore, if I simply use:
>>>
>>>  $submit = str_replace( chr(194), '', $submit );
>>>  $submit = str_replace( chr(160), '', $submit );
>>>
>>>  This is the solution.
>>
>>Hardly.
>
> If you mean my solution doesn't work, then you are mistaken -- for
> works for me.
>
>
>>  > Now, why does a POST operation add in C2's?  I'll leave that for
>>>  another post. :-)
>>
>>I haven't had time to look at the code, but perhaps you
>>need to specify a character encoding for the page.
>
>
> That's a valid point. Not only the encoding that's declared for the
> page via it's html DOCTYPE, but also what encoding was used to
> actually save that file on the server.
>
> This entire encoding process is more involved than it looks, or so it
> appears to me.

Perhaps you should be taking a whitelist approach to filtering input?...

:-)

In other words, only allow specific characters combinations you expect
to see, and ignore any other goofy characters that were encoded from
&nbsp;

Or, possibly, try using just spaces and not &nbsp; for the value -- I
suspect that the browsers will NOT collapse the spaces in the VALUE
since it's data, not HTML content...

-- 
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux