#3 ISO-8859-1 characters serialization error

[JLM]

I got a pb when passing strings and arrays with
ISO-8859-1 chars (which I call "latin_strings" below).

-- Passing latin_strings as a parameter --
When passing directly latin_string as parameters, I got
unexpected strings :
example:
I pass
יי
to my class method
and the resulting string is
יי";

-- Passing latin_strings in an array parameter --
Here the error is stronger :
you got a server error (javascript alert by default):
[Server Error] unserialize failed at offset (x) of
(x-1) bytes ...

Take a look at the autocompletion example script :
http://xmlrpccom.sourceforge.net/scriptserver/scriptserver/examples/autocomplete.php
Type י for first character to view the javascript error.

[Harry Fuecks]

Logged In: YES
user_id=569780

Interesting.

What ScriptServer does (in Javascript) it calculate the
length a string would have, in bytes, if it was encoded as
UTF-8, athough the actual encoding it leaves up the browser.

The problem is PHP's unserialize() which only deals in
bytes, while Javascript will count a single multibyte
character as having a string lengh of 1. PHP's serialization
format requires the string length (byte count in fact).

It think it may be possible to solve this by messing with
the response charset, to tell the browser to send utf8 but
last time I tried, worked fine with Firefox but not with IE.

Would be interested in anyone's thoughts on the subject.

[Harry Fuecks]

Logged In: YES
user_id=569780

Updated the Javascript client code to use only UTF-8 (and
send the relevant HTTP headers) - it's in CVS and on the
Sourceforge website.

Problem now seems to be machine specific (locale?) like it
works for me but not on Sourceforge (box I'm testing on
locally, right now, is Win 2000 + PHP 5.02 with German as
the locale).

If I end the following string to the autocomplete field;

Ge

This gets converted to UTF-8 and what PHP is sent (the
serialized string) on my box looks like;

s:4:"Geä";

Which is fine - strings reported length and the actual
length match. Believe that's how iso-8859-1 interprets the
UTF-8.

But on Sourceforge get;

s:4:"Ge¤";

Which is a problem - the actual string is 5 bytes but the
encoding says 4. Is that because SF uses US-ASCII? Not sure.

What does suck is this is locale specific and can't think of
a way round that right now. Will be a problem for users as
they'll need to modify their locales at least.