Hello Tex,
Wednesday, September 14, 2005, 1:07:26 PM, you wrote:
TT> Bear with me, I don't know about how PHP uses the serialized info, but if
TT> your goal is to minimize the overhead for unicode data when
no, now we're discussing the following issues:
1) should serialize format be portable between unicode and non-uniocde modes
(Andrei says that no, for example)?
2) if yes, should it contain data in the fixed encoding (unicode), so that
serialize() in non-unicode mode will do conversion, or in the script
encoding (so, no conversion in serialize() is required, but we need to
specify data encoding somehow)?
now we have following ways of implementing serialize() in php6:
1) non-portable way: no conversion at all; serialize data created in
unicode mode won't be unserialized in non-unicode mode and vice versa
2) quasi-portable way: no conversion at all; we will just unserialize what
we get; but if we unserialize data in a script with different encoding,
it can malfunction
3) unicode way: store all encoding-specific data in unicode (so, convert
them if serialize() is called in non-unicode way); downconvert to script
encoding in unserialize() is called in non-unicode way (so, you can see a
double conversion in this particular case)
4) varying encoding way: store all data as-is, but also store script
encoding; if we call unserialize() in a script with different encoding,
convert them (double conversion can still occur, but not so often)
ps: sorry for mistakes, i'm writing in a hurry
--
Best regards,
val mailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
