Text 6663, 85 rader
Skriven 2013-02-19 16:33:48 av mark lewis (1:3634/12.42)
   Kommentar till text 6649 av Sergey Dorofeev (2:5020/12000)
Ärende: LOL!
============
 SD> orig.message to echo FIDONEWS on 19 Feb 13  09:40:25
 ml>> you are also missing conversion *from* UTF-8 to other character
 ml>> sets as well ;)
 ml>
 ml> where is the blank line i specifically leave in between quotes
 ml> and my text
 ml> in the above??

 SD> I've deleted it manually.

oh... i have seen quoters that actually remove it and shouldn't... i was hoping
that yours was not one of those ;)

 SD>> Message always can be converted back to original encoding.
 ml> where is the original encoding stored when a message is converted 
 ml> to UTF-8?

 SD> In the message metadata: at the same level as message itself. 

[trim

oh... that's some kind of sql database or such... the option to store the
original character set and the local character set is not available in the
"standard" message base format used by most(??) systems... definitely not BBS
systems... MSG doesn't offer such a place unless the tosser specifically adds
another control line to kludge in the storage... HMB has the same limitation
but this leads to even less space for actual message text... SQU and JAM may be
able to store this info with custom fields but again, the tosser needs to
handle this since it stuffs the messages into the message base... i don't know
enough about goldbase, or synchronet's message base format... and there are
numerous others, too... so this is definitely not something that is available
globally...


 ml> but that's also not what i was pointing at... what happens if you
 ml> convert from CP437 to UTF-8 and then back to CP850? some 
 ml> characters are not available in CP850 so how do you represent them?

 SD> It is actual only for gateways, when you are forced to hold fixed
 SD> encoding on export. Surely it is lossy. But in normal message
 SD> processing it is never needed. 

then one of us is missing something... take the CP437 ALT-148 'ö' for
instance... if you translate is to your local character set and it is now
ALT-365 (for example), how is that going to be translated to someone using
CP850 when reading from your message base? are you going to convert it back to
the original CP437 and then convert it over to CP850? if so, why convert it to
the local page in the first place? why not just store it as it is and convert
only for display purposes?

then we get to the reply... are you going to emit it back out in the original
CP437 format or your local character set format? i would say in your local
character set format since the entire message, included quotes, should have
been converted but then we come back to old-school systems and the inability of
converting from UTF-8 (for instance) to CP437... i haven't had time to work on
transliteration tables but i believe it can be done even though others say not
and point out that german's ability to go from "ö" to "oe" is quite different
for others... i'm just a single spoken language individual... i just want to be
able to read the posts without a bunch of graphical gibberish and i want to do
this using my existing old school BBS and all the software i have been using
since i set up this BBS years ago... i'm not the only one with this desire,
either... i do not want to stiffle innovation but i also do not, more
importantly, loose what we already have and thus possibly loose many long time
systems and participants who rely on our old school systems for their contact
and conversations with others...

 SD>> That is placed inside of binary header.
 ml> ok... that's the one i thought you were thinking of... we are 
 ml> talking only about display purposes, right? not actually 
 ml> converting the original time to local time and storing it back in 
 ml> the message?

 SD> I think about keeping universal timestamps in metadata for purpose
 SD> of indexing (to have messages ordered by time written, not
 SD> arrived).

understand... i would assume that to be another field instead of modifying the
original existing data and taking a chance on loose it somehow... personally, i
would keep all of the original data as received and use additional fields for
the modified data based on the original control lines and header information...

)\/(ark

--- 
 * Origin:  (1:3634/12.42)