[dev] [commits] Horde branch master updated. 76152d6a2976549c96ae0aec5b20c4669b8a68bf

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>
>>>   Remove all external charset conversion API for prefs.  Charset
>>>   conversion, if needed, should be done entirely within the storage
>>>   driver (prefs now assumes all in-memory prefs are in UTF-8).
>>
>> I don't see how this is supposed to work. This is how we used to do  
>> charset conversion with prefs in Horde 2, and it failed miserably.  
>> Chances for failure are fewer now, because we don't need to care  
>> about different UI charsets anymore, but if you convert the  
>> serialized data, instead of converting before the serialization,  
>> you end up with invalid serialized strings in the storage.
>
> Very confused.  Why would you end up with invalid serialized  
> strings?  Once a string is serialized, it makes no difference  
> whether the charset is converted - as long as we convert the charset  
> back when unserializing.
>
> In other words, why does it matter if you call  
> Horde_String::convertCharset() before serializing vs. after  
> serializing?  It shouldn't matter.

It matters because the string length can change during charset  
conversion. PHP's serializer uses the string's octet length not the  
number of codepoints. Thus you end up with a broken serialization  
string in the database if you change the charset after the  
serialization.

> This pseudocode demonstrates how Horde_Prefs works now:
>
> =====
>
> $data = array('août');
>
> // Serialize in app code
> $a = serialize($data);
>
> // Call $prefs->setValue($a):
> $a = Horde_String::convertCharset($a, 'UTF-8', 'ISO-8859-1');
>
> // $a stored in backend
>
> // ...

In the backend should be stored a valid serialized string, but it isn't:

> // Retrieve in backend.
> $b = $a;

unserialize($b);

PHP Notice:  unserialize(): Error at offset x of y bytes

> // Call $prefs->getValue($a);
> $b = Horde_String::convertCharset($b, 'ISO-8859-1', 'UTF-8');
>
> // Unserialize in app code
> $a = unserialize($a);
>
> if ($a == $data) {
>     print "SAME";
> }
>
> // prints "SAME"
>
> =====
>
> Maybe things were broken in Horde 2 because of inconsistent charsets  
> of the strings or something similar.  But if we now guarantee (or  
> demand) that input into Horde_Prefs must be UTF-8, this should  
> remove all ambiguities/confusion.
>
> michael
>
> -- 
> ___________________________________
> Michael Slusarz [slusarz at horde.org]
>
>
>
> -- 
> Horde developers mailing list - Join the hunt: http://horde.org/bounties/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org
>



Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/