REPLY: 2:280/464.113 5cc9d172   
   MSGID: 1:3634/12.73 5cc9e15a   
   PID: GED+LNX 1.1.5-b20180707   
   CHRS: CP437 2   
   TZUTC: -0400   
   TID: hpt/lnx 1.9.0-cur 07-09-15   
      
    On 2019 May 01 17:03:46, you wrote to me:   
      
    ml>> FWIW1: there are two places where 0x8d may be acted on...   
    ml>>   1. the tosser may strip by ignoring completely and skipping   
      
    MK> I am not sure what you mean by that   
      
   there are two ways to "ignore" something when processing it...   
      
     1. a. read in data   
        b. find character to ignore   
        c. ignore it and do not write it to the output (aka skip)   
      
     2. a. read in data   
        b. find character to ignore   
        c. ignore it and write it to the output (true ignore)   
      
   a lot of code does #1 when it should do #2...   
      
    MK> but if the end result is what Nancy shows in her quotes of the   
    MK> trailing 0x8d in the 4 utf8 characters then that would be the "may   
    MK> strip" result which leaves only the leading byte ... or what I prefer   
    MK> it be called the masterbyte.  :::evil grin:::   
      
   hehehe... remember, though, that in nancy's case, she sees the characters after   
      
     1. they are originally written on a BBS   
        or imported into the BBS from offline mail   
     2. scanned out of the BBS to FTN packets   
     3. transferred across the wire   
     4. tossed in to the BBS from FTN packets   
     5. they're packed into her offline mail format   
     6. opened on her end and displayed in her reader   
      
   numbers 2, 4, 5, and 6 could result in her not seeing certain characters...   
   number 1 could if the import from the offline mail upload package filtered   
   them by ignoring them...   
      
    ml>>   2. the BBS may strip or convert to 0x0d while displaying the   
    ml>>      message or when packaging it for offline mail   
      
    MK> Which is what happened on at least one BBS according to Nancy, which   
    MK> matches with what Ozz's quote of the same message showed.  Either way that   
    MK> does not bode well since 0x8d is a well used trailing byte in utf8.   
      
   very true...   
      
    MK> Also worth mentioning is that two of the supported codepages, IBM848   
    MK> and IBM866, use 0x8d as the exact same character - "CYRILLIC CAPITAL   
    MK> LETTER EN" - while IBM850 uses 0x8d as the same character as IBM437 -   
    MK> "LATIN SMALL LETTER I WITH GRAVE".   
      
   there is that, as well...   
      
    MK> An interesting aside; U+040D known as "CYRILLIC CAPITAL LETTER I WITH   
    MK> GRAVE" will also work in the phrase, "It is all fun and games until   
   someone   
    MK> loses an Р  
   .", since the trailing byte happens to be 0x8d.  Although in   
    MK> this case the masterbyte :::snicker::: 0xd0 will survive but then it no   
    MK> longer is a valid utf8 character without it's needed trailing byte.   
      
   keep on with the poking... it may result in some real good for the network one   
   day ;)   
      
   )\/(ark   
      
   Always Mount a Scratch Monkey   
   Do you manage your own servers? If you are not running an IDS/IPS yer doin' it   
   wrong...   
   ... I'm the trombone joke in this echo (it was a joke why they let me play).   
   ---   
    * Origin:  (1:3634/12.73)   
   SEEN-BY: 1/120 123 15/2 18/0 200 116/116 123/0 25 50 115 150 755 135/300   
   SEEN-BY: 153/7001 7715 154/10 20 30 40 700 203/0 221/0 6 226/17 227/400   
   SEEN-BY: 229/354 426 452 1014 240/5832 249/206 317 400 261/38 280/464   
   SEEN-BY: 280/5003 310/31 317/3 322/757 340/800 342/200 393/68 396/45   
   SEEN-BY: 423/120 633/280 770/1 3634/0 12 15 27 50   
   PATH: 3634/12 154/10 280/464 229/426