<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body>Sounds like a plan. Again, that Unicode substitution I do is only for local screens, so that the user doesn't get an uninterpretable rectangular block for a non-printable character.
<div><br></div><div>I'll make the change in my next build.</div><div><br></div><div>Andrew, KA2DDO</div><div>author of YAAC</div><br><br>-------- Original message --------<br>From: "Iain R. Learmonth" <irl@hambsd.org> <br>Date: 5/8/20 10:42 (GMT-05:00) <br>To: aprssig@lists.tapr.org <br>Subject: Re: [aprssig] Escaping \r\n in packets for APRS-IS <br><br>Hi,<br><br>On 08/05/2020 15:37, spam8mybrain wrote:<br>> Uh, oh. Not cool. I just checked my APRS-IS and SSL-APRS-IS port drivers<br>> in YAAC, and I send the packet as-is byte-for-byte, assuming it is only<br>> one line with no embedded control characters.<br><br>Ooops.<br><br>> Hmmm... in one of my displays, I replace all the ASCII control<br>> characters (byte values 0x00 through 0x1F) with their corresponding<br>> display glyphs in Unicode (\u2400 through \u241F), so they can be<br>> interpreted properly by the user. But that doesn't fix I-gating.<br><br>That would break MIC-E packets, I'm going with what Dire Wolf and Xastir<br>do which is to treat either a \r or \n as the end of the packet if<br>found, and then do the normal checks before gating.<br><br>It's only \r and \n that have special meaning to the server, all other<br>characters are fine.<br><br>Thanks,<br>Iain MM0ROR.<br><br>-- <br>https://hambsd.org/<br><br>_______________________________________________<br>aprssig mailing list<br>aprssig@lists.tapr.org<br>http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org<br></body></html>