>> I see... So it is the terminal - or whatever functions as its >> equivalent - and only the terminal that determines the encoding of the >> message at hand.
RS> Or rather, the message content created with that terminal. If the RS> content is just plain ASCII, regardless of the terminal that created RS> it, then the message will fly the ASCII charset flag. In Synchronet, a RS> CP437 terminal cannot be used to created UTF-8 content, so messages RS> created by such a terminal will either be ASCII or CP437 encoded.
Understood.
>> RS> The only encodings Synchronet supports for message text are >> RS> ASCII, CP437, and UTF-8. >> >> Hmmm... That leaves out a big part of Fidonet. These days the >> majority, maybe the vast majority is writen in a language that uses >> the Cyrillic alfabet and the encoding is CP866.
RS> True, that's the state of things.
Well, at least those needing more that CP437 can use UTF-8.
>> >> So what happens in that case if the terminal does not support >> >> UTF-8? >> >> RS> The message text would be converted to CP437 before being >> RS> quoted and the response would be in CP437. >> >> And now I come back to my previous question: what happens if it >> does not fit into CP437? That can easely happen. A Euro sign '¿' >> can be composed in UTF-8 but it does not fit into CP437.
I see that the EURO sign is translated into an inverted question mark.
RS> When a CP437 terminal user quotes a UTF-8 message that contains RS> untranslatable UNICODE codepoints without a CP437 equivalent, they're RS> translated to character that indiciates it was untranslatable. By RS> default, that character is the upside down question mark.
Check.
Next question: Can Synchonet deal with a UTF-8 encoded nodelist?
