AW: [Openinteract-dev] Small i18n issue

[<And...@Be...>]

.. DBD::Oracle is even worse: if you have a LANG environment with =
UTF8, then
the NLS_LANG Oracle stuff breaks and leads to weird error messages...

Mit freundlichen Gr=FC=DFen
Andreas Nolte=20
Leitung IT
-------------------------------------------------
arvato direct services
Olympiastra=DFe 1
26419 Schortens
Germany
http://www.arvato.com/
and...@be...
Telefon +49 (0) 44 21 - 76-84002
Telefax +49 (0) 44 21 - 76-84111



-----Urspr=FCngliche Nachricht-----
Von: ope...@li...
[mailto:ope...@li...]=20
Gesendet: Mittwoch, 8. September 2004 11:56
An: ope...@li...
Cc: Kutter Martin; 'ope...@li...'
Betreff: Re: [Openinteract-dev] Small i18n issue



> I've been able to track this down to a charset problem.
> LDAP expects directoryString attributes to be in UTF-8 encoding. The=20
> perl-ldap interface (Net::LDAP) does not provide UTF-8 conversions by =

> default, so these are to be done by the application using Net::LDAP.=20
> This is no big deal - just a
>
>  use Encode;
>  $value =3D decode($charset, $value);

I had a similar problem with DBD::mysql and UTF-8. DBI has no general =
policy

for UTF-8, so it has to be implemented by DBD:s themselves. DBD::mysql =
does=20
nothing to that issue. If you store UTF-8 strings in the database and=20
retrieve them back, these strings do not get marked as UTF-8. Later it =
might

happen that your UTF-8 strings get encoded as UTF-8, because Perl =
didn't
mark=20
those as UTF-8 already =3D) Encode module helps fixing this problem for
example=20
in SPOPS::DBI::MySQL (define a post_fetch_action() that converts all =
data=20
fields).

I wonder when you are able to write utf-8 compatible software without
mocking=20
all the internals on several layers... It has been around so many years =
and=20
still many module writers ignore it. It also wasn't until mysql 4.x =
when
they=20
included UTF-8 support in character type fields.

> The problem is, that the only available solution to get the charset=20
> used in the request is to grab it from the underlying Apache::Request =

> or CGI::Request handle - not really easy and not really portable:
>
>  my $contentHeader =3D CTX->request->apache->headers_in()->{=20
> Content-Type };

I noticed the same thing. I also found another way to set it:

CTX->response->content_type( 'text/html; charset=3Dutf-8' )

CTX->response->charset() would be nice to have.

Greetings,

- Teemu


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick
_______________________________________________
openinteract-dev mailing list ope...@li...
https://lists.sourceforge.net/lists/listinfo/openinteract-dev