On Thursday, September 18, 2003, at 05:24 PM, Nathan Ollerenshaw wrote:
On Thursday, September 18, 2003, at 04:44 PM, Brian Candler wrote:
=?utf-8?Q?=E6=97=A5=E6=9C=AC=E8=AA=9E=E3=81=AE=E3=83?=
BTW, I thought the 'Q' in the string meant Quoted printable ... which it plainly isn't, right? It should be a B, no? It should also be iso-2022-jp, but one step at a time :)
Oh, rechecked, this is correct.
One thing though, really long subjects I get something like
[...lines removed for brevity...] =?utf-8?Q?=AA=9E=E3=81=AE=E3=83=86=E3=82=B9=E! 3=83=88?= [...lines removed for brevity...]
What is happening is that sqwebmail is encoding the subject correctly in UTF-8, chopped up into =?utf-8?Q?.....?= sections. But, when the header parsing code kicks in to build the header out of this subject line, it chops it at the 991st character and inserts a "\n " which kills the encoding :/
Right now, in meatspace I'm in the process of moving to a new house, and I have little time to hack. After reviewing your message, I can tell you this:
A) UTF-8 is a proper superset of iso-2022-jp. There is absolutely nothing wrong with encoding Japanese test in UTF-8, provided that the actual unicodes are properly encoded, but the choice of the actual character set is completely irrelevant.
The way Apple mail handles it is to put a "\n " after each encoded section no matter what (whatever you call it), and sqwebmail can display that fine.
B) If this is all that needs to be done, it should be an easy fix. But... It will have to wait until I have some time.
C) As far as wrapping text in a middle of a multi-byte character, you'll just have to continue using UTF-8, which should not have this problem, until someone figured out what the problem is.
pgp00000.pgp
Description: PGP signature
