[aprssig] Please,standardize UTF-8 for APRS

[Joel Maslak - N7XUC]

Sorry, brain misfire on my part. I was thinking of a different  
encoding scheme.

On Dec 17, 2009, at 7:38 AM, "Lynn W. Deffenbaugh (Mr)" <ldeffenb at homeside.to 
 > wrote:

> UTF-8 is identical to ASCII for the ASCII values 32 through 126  
> (space through tilde).  If that's a normal equal sign (ASCII 61  
> 0x3D) there should be no changes.  Is there something special about  
> = that I don't know?
>
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and now  
> Win32!
>
> Joel Maslak - N7XUC wrote:
>> Will this change the preferred way of sending some characters like  
>> = ?
>>
>> On Dec 16, 2009, at 5:30 PM, "Robert Bruninga" <bruninga at usna.edu>  
>> wrote:
>>
>>>> Currently APRS-1.0.1 protocol says:
>>>> US-ASCII, 7-BIT CHARACTERS.
>>>> For us that is completely inadequate.
>>>
>>> In cleaning up old email, there were hundreds of emails back in
>>> September on the topic of expanding the APRS spec to UTF-8 to
>>> include all other languages in text messaging.  In the hundreds
>>> of emails it is hard for me to remember the conclusion.
>>>
>>> But I have asked all authors to investigate and to date, no one
>>> that I can remember said that transmitting a non USA ASCII
>>> message in UTF-8 resulted in a failed packet.  Of course the
>>> text displayed gyberish on non-compatible systems, but at least
>>> they displayed that a "message" was received.  I expect gyberish
>>> in old systems, but we must identify broken packets that do not
>>> get parsed at all.
>>>
>>> So I have added to the APRS1.2 addendum that future systems may
>>> use UTF-8 in text message fields and STATUS fields or at least
>>> make sure that receipt of same does not break the packet for
>>> display in some form.  www.aprs.org/aprs12.html
>>>
>>> We need to find and document all existing clients and systems
>>> that fail a packet that contains UTF-8 text.  An example of a
>>> "failed" packet would be a POSITION packet that has a UTF-8
>>> text, and that text causes the client to ignore the POSITION.
>>> These such incompatibilities must be documented as we move on...
>>>
>>> Bob, WB4APR
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> aprssig mailing list
>>> aprssig at tapr.org
>>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at tapr.org
>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig