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

At 4:24 PM +0100 1/3/08, Nisse =?utf-8?Q?Engstr=C3=B6m?= 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. Cheers, tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.com