What I'm sending as EOL characters with the QWK networking is chr(227). The spec seems to indicate that:
"For unclear reasons, new-lines sequences are normally represented by the character 0xE3 (227). In UTF-8 encoded messages, Synchronet uses ASCII 10 (LF)t o represent new-lines in QWK message bodies."
So... what should I do to make these avatar messages parse on systems other than Vert (until everyone updates to a new version)? I think I'm following the spec and the spec says that Synchronet converts to LF, not CR/LF.
I could change it to send CR/LF in the QWk packet but that is against the specification.
--- TRACKER1 wrote ---
On 2/24/22 08:44, the doctor wrote:
I can't speak for how Synchronet is handling this...
I have been looking into this as well, planning on cataloging the information into a couple services as well. My plan was to look for "json-begin" and "json-end" in the message and plucking what's in
Per the JSON spec, it *should* be UTF8 encoded, and any white-space characters outside quoted strings should be ignored. Since you can
escape any character outside the 7-bit ASCII range (as well as quotes)
per JS encoding (\x## \u#### \###), I suggest doing so for any
interchange messages that include higher characters (and control chars),
and (re)encoding any non-utf8 character sets to their Unicode
As to message bodies, I think that terminal based message conventions is
the combination of CRLF (\r\n), since \r will move the cursor to the beginning of the line and \n will move the cursor down one line. (IIRC)
That's just my own opinionated take on this one, and what I've been
doing so far.
|Nodes:||10 (0 / 10)|