On Wed, 2007-09-05 at 11:15 -0600, Richi Plana wrote: > On Wed, 2007-09-05 at 12:59 -0400, Dan Williams wrote: > > Right; it is an NM issue. If NM crashes or misbehaves with a weird > > SSID, we need to fix it. > > > > As specified in the 802.11 standard, the ESSID is a 32-byte byte array, > > there are no restrictions made as to what content that 32-bytes may > > contain. It is up to the program to attempt to coerce that value into > > something to present to the user. > > Since no semantics has been proposed, then it stands to reason that one > can just assume 1 byte = 1 character and a straight "byte value = > Unicode value" conversion should be adopted, right? (No codepage > conversions). > > Come to think of it, if they're just a generic 32-byte byte array, why > even convert them to strings? They only make sense if they happen to > contain alphanumeric and some symbolic characters (which isn't even a > convention or restriction). Alright, maybe it's useful for displaying to > humans when they just happen to be alphanumeric. Forget I asked. Well, it's a really tricky problem. I'd personally do: try UTF-8 validation try validation from the encoding in LANG fall back to a lot of ? for unprintables For example, if I live in Shanghai, I should be able to make my AP SSID some native character like 虚. However, if I live in Central Europoe and for some reason I use ISO 8859-15 (or whatever it is) I'd probably like my ň to show up. I believe NM should try at least a few ways of parsing the SSID (not too many) and just fall back to ? in the end. This is what it currently does, but apparently somewhat badly. Dan -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
