[ic] ic-utf8 readfile/writefile patch
Stefan Hornburg
racke at linuxia.de
Sun Mar 22 08:44:10 UTC 2009
David Christensen wrote:
> On Mar 21, 2009, at 7:11 PM, Peter wrote:
>
>> On 03/21/2009 05:51 AM, Stefan Hornburg (Racke) wrote:
>>> Stefan Hornburg (Racke) wrote:
>>>> Yes, it doesn't crash anymore :-).
>>>>
>>>> One problem that might be related to this issue is the delivery of
>>>> "binary"
>>>> content stored in a UTF8 database.
>>>>
>>>> Currently the files produced are corrupted, and the data in the db
>>>> is
>>>> definitely correct. And it works with UTF8 inactive (as per bug
>>>> #259).
>>>>
>>>> The code is as follows:
>>>>
>>>> my $data = $Db{transaction_documents}->field($td_code, 'content');
>>>> $data = $Tag->filter({op => 'decode_base64', body => $data});
>>> Putting at this point:
>>>
>>> Encode::_utf8_on($data);
>>>
>>> "solves" the problem.
>>>
>>>> $Tag->deliver({type => 'application/pdf', body => $data});
>>
>> This may "solve the problem" but it doesn't look like the right
>> solution
>> to me. If it's really "binary" data then the utf8 flag should be off
>> for it, not on and the data should not be treated as utf8 in any way.
>> Presumably this would contain something like a picture or a sound file
>> which should certainly not be utf8 encoded.
>
> Correct. I'll give the binary blobs some thought, not sure if it
> would need special handling or not. The issue comes in not from the
> internal representation, but because the server's output handle is
> apparently encoding to utf8 on the way out to the client, which should
> only happen when content-type is text.
In my case the field type is text (PostgreSQL), so it should certainly
be flagged as UTF8.
Regards
Racke
--
LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration
ICDEVGROUP => http://www.icdevgroup.org/
Interchange Development Team
More information about the interchange-users
mailing list