@MSGID: 2:280/5555 640319a0
@REPLY: 327.fidoutf8@1:103/705 28667e7f
@TID: FMail-W32 2.2.0.0
@RFC-X-No-Archive: Yes
@TZUTC: 0100
@CHRS: UTF-8 4
Hello Rob,

On Thursday March 02 2023 17:02, you wrote to me:

 >> All three of your messages have non-ASCCI characters. They all have
 >> the degree character `┬░` in the sign off, or whatver you call it.
 >> In the last message it is also present in the message test before
 >> the "--" (two dashes).

 RS> Ah, true. But in the message I posted using a UTF-8 terminal, that
 RS> would have been a UTF-8 encoded "degree" symbol instead of a
 RS> CP437-encoded one (as would have been in the other messages, including
 RS> this one).

The message I am respondig to, is indeed encoded in CP437.

So let me get this straight:

 1) If the message that is responded to, is encoded in CP437,
Synchronet answers in CP437. Yes?

So what happens if the response does not fit into CP437?

 What happens if the original message is encoded in a one byte
encoding other than CP437?

 2) If the message that is responded to is encoded in UTF-8,
Synchronet answers in UTF-8 if the terminal theis used supports UTF-8. Yes?

So what happens in that case if the terminal does not support UTF-8?

 >>  RS> Norco, CA WX: 42.0┬░F, 79.0% humidity, 0 mph NE wind, 0.15
 >> inches RS> rain/24hrs

My software translates the CP437 encoded degree sign into UTF-8 as you can see.

 >> Considering that the CHRS kludge applies to the entire message, I
 >> think it is more logical to look at the entire message including
 >> header, footer en origin lines to determine the encoding.

 RS> Synchronet does exactly that.

OK. :-)


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
 * Origin: Nieuw Schn├╕├╕rd (2:280/5555)
SEEN-BY: 50/109 154/10 203/0 221/6 240/5832 280/464
5003 5555 301/1 310/31
SEEN-BY: 341/66 410/9 460/58 467/888 712/848
5001/100 5005/49 5015/46 5019/40
SEEN-BY: 5020/715 736 830 848 1042 4441 12000
5030/49 1081 1474 5054/8
SEEN-BY: 5058/104 5064/56
@PATH: 280/5555 5020/1042 4441