International character handling problem

Hi,

I’m facing the same “international character handling” problem discussed in

http://gossamer-threads.com/lists/rt/users/19748?search_string=character .

As described there, RT & Apache go well for some time after apache restart,
but, due to an unknown reason, they fail again in handling international
characters (tickets created on email receive, portuguese language). The
referred discussion thread is not conclusive.

Is there a documented final solution for this problem? (couldn’t find it in
the discussion list).

Thanks for any help

Fabio Cruz

My setup is:
RT 3.0.10
RedHat 9.0
MySQL v4.0
Apache 2.04
Perl v5.8.0

Upgrade your perl up to 5.8.3 or higher.

F�bio S�rgio Cruz wrote:

Upgrading perl doesn’t always solve the problem. We are still seeing lots of issues when EUC-KR is sent to RT. We get total corruption and we are on perl 5.8.3, rt 3.2.2.

Richard Ellis wrote:

Upgrading perl doesn’t always solve the problem. We are still seeing lots of issues when EUC-KR is sent to RT. We get total corruption and we are on perl 5.8.3, rt 3.2.2.
PERL 5.8.3 is MAJOR requirment if you don’t want to see random
corruptions.

Richard, don’t confuse Fabio, please. He has unsupported perl version
and we know that that perl version has bug and corrupts attachments.

Richard, if you have problem please create new thread on ML that
describe your problem as required in Request Tracker Wiki.
Send orig messages that are corrupted by RT with full bug report info to
rt-devel or rt-bugs and it would be fixed.

			Best regards. Ruslan.

We are still seeing lots of issues when EUC-KR is sent to RT. We get
total corruption and we are on perl 5.8.3, rt 3.2.2.

Please send us mail that gets corrupted by RT so that we can add it to
RT’s test suite. Ideally, as a patch which adds failing tests.
Failing that, please encapsulate the original email message by
uuencoding it or dumping it in a tarball or gzipping it.

j