[ic] ic-utf8 readfile/writefile patch

[Stefan Hornburg]

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