Hi, On 08/25/2015 02:09 PM, Rainer Weikusat wrote: > Considering that this enforces some kind of 'bastard URL-encoding' > (using + as prefix instead of %) for all other bytes, it's also going > make people who believe that UTF-8 would be a well supported way to > represent non-ASCII characters very unhappy.
1. This encoding is not about URLs but filenames. Your wording "bastard URL-encoding" is unclear to me, apart from that i would much prefer it if you could restrain yourself from using pejoratives when doing code reviews. However, should "+" for some reason turn out to be an undesireable escape character, it can be changed easily. 2. It is not safe to assume that SSIDs contain UTF-8. The relevant IEEE standard is botched. https://en.wikipedia.org/wiki/Service_set_%28802.11_network%29 "Note that the 2012 version of the 802.11 standard defines a primitive SSIDEncoding, an Enumeration of UNSPECIFIED and UTF-8, indicating how the array of octets can be interpreted." Imagining how many service sets still operate using the pre-2012 standard (and/or are botched implementations themselves that fail to recognize the issue), i think it is safe to assume that the character encoding of an SSID is "UNSPECIFIED" in the general case. Therefore, it is handled encoding-agnostic on a byte-per-byte basis, and this is what the code accomplishes. As i see it, when we have the main concerns of security of the installation under control, I will willingly contribute to evaluation of a (possible) scan result SSIDEncoding. Kind regards, T. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
