Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:18812
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <43268C01.20006@zend.com>
Date: Tue, 13 Sep 2005 12:21:21 +0400
User-Agent: Thunderbird 1.4 (X11/20050907)
MIME-Version: 1.0
To: Andi Gutmans <andi@zend.com>
CC: Andrei Zmievski <andrei@gravitonic.com>, 
	php-dev <internals@lists.php.net>,
	Dmitry Stogov <dmitry@zend.com>
References: <43215A91.8050409@zend.com> <9CF57DC5-A18B-4264-B20B-8552B0BB66F1@gravitonic.com> <6.2.3.4.2.20050912175136.04449320@localhost>
In-Reply-To: <6.2.3.4.2.20050912175136.04449320@localhost>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] unserialize() & unicode issues
From: antony@zend.com (Antony Dovgal)

Even if the class name is in Unicode, we can try to convert it to ASCII 
and fail only in the case when we can't find its class entry in the list.

So, I don't see any need in markers and other fairly major changes.

On 13.09.2005 04:54, Andi Gutmans wrote:
> Not coming with a solution, but I believe this would be a bad idea. I 
> do think some people will be using IS_UNICODE strings when 
> unicode_semantics=off, mainly for existing applications. They may 
> want to serialize Unicode strings even though their classes are 
> IS_STRING. It might make sense to raise an error though if a "class" 
> is used, but if it's just a value or a hash key, then those are valid 
> in unicode_semantics=off.
> 
> Andi
> 
> At 06:44 AM 9/9/2005, Andrei Zmievski wrote:
>>Yes, serialization is a problem. I would actually advocate putting a
>>marker in the serialized file that indicates what the value of
>>unicode_semantics switch was during the serialization, and if the
>>value is different during deserialization, refuse to load it or start
>>a new session. One really should not be changing that switch on a
>>whim in-between sessions.


-- 
Wbr, 
Antony Dovgal