Text 6584, 49 rader
Skriven 2013-02-18 19:34:24 av Kees van Eeten (2:280/5003.4)
   Kommentar till text 6571 av Sergey Dorofeev (2:5020/12000)
Ärende: LOL!
============
Hello Sergey!

 SD> The solution is to store messages in repository pre-converted to unicode.
 SD> It resolves all described problems.
 SD> However spawns new:
 SD> 1) incorrectly specified CHRS (requires manual recoding)
 SD> 2) more space
 SD> 3) unicode-aware reader

 The solution is not the problem, there are even more people who can think of
 one, as there are that are able to solve them.

 The main problem is a flawless transition, that is not organised as a
 big BANG.

 SD> I can say only one thing: please use the same charset as in body
 SD> (specified by CHRS) or use only ASCII letters. Anything other renders
 SD> automatic message processing impossible.

 As others have recounted, the header should be in the default characterset
 of the network. The message body can be encodes into anything your audience
 can read.

 SD> Yes, it requres more CPU cycles
 SD> to walk through kludges, but it is not critical flaw. In the same time
 SD> if
 SD> some other that CHRS encoding is used in name/to/subj, there is no way to
 SD> automatically parse message even if use Supercomputer.

 SD> And, I want to add. There is TZUTC kludge that is used to correctly
 SD> determine sender's local time. It goes after header (that contains
 SD> considered datetime field), but are there any doubts that it should be
 SD> applied to the field?

 I think that is up to what the software developer wants to present to
 the user. However I would not change anything in the original message.

 I have a database that was started in the end of the 90ties by among others
 Dirk Astrath. First I had a mirror, after his system crashed, I continued
 loding all echo messages, that passed my system. The priciple there is not
 to transcode any part of the original message. If you do, you will have a
 terrible time looking for duplicates. Another factor is, that altouh it
 is not used often in echomail, signed messages, cannot be checked to be
 original, if the message is transcoded.

Kees

--- FPD v2.9.040207  GoldED+/LNX 1.1.5
 * Origin: As for me, all I know is that I know nothing. (2:280/5003.4)