• More Questions

    From the doctor@VERT/QBBSTEST to Digital Man / echicken on Thursday, February 24, 2022 15:44:00
    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
  • From Tracker1@VERT/TRN to the doctor on Friday, April 01, 2022 21:36:03
    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
  • From the doctor@VERT/QBBS to TRACKER1 on Wednesday, April 06, 2022 14:59:00
    --- 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