Hi guys,

I've been looking at this (because I wrote the code back in the mists of time).

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.

Thanks,

Mark


---
* TARDIS BBS - Home of QUARKware * telnet bbs.cortex-media.info

On 2/24/22 08:44, the doctor wrote:

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.

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 between.

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
corresponding values.

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.
--
Michael J. Ryan - tracker1@roughneckbbs.com

---
þ Synchronet þ Roughneck BBS - roughneckbbs.com

--- 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
between.

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
corresponding values.

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.

Thanks for the information. I will trying doing what you suggest for
unicode characters. I've more or less got it working now, it was really
a problem caused by the more dusty bits of code (that i wrote like 15 or
more years ago) and me not remember what I did or why. (:


---
"No matter where you go, there you are..."


---
* TARDIS BBS - Home of QUARKware * telnet bbs.cortex-media.info