Live data from Hacker News

Comparing how different devices display the SSID “á̶̛̛̓̿̈͐͆̐̇̒̑̈́͘͝aaa”

hamptonmoore.com

1–10 of 60 posts

Re: Comparing how different devices display the SSID “á̶̛̛̓̿̈͐͆̐̇̒̑̈́͘͝aaa”

#2
Very cool. It's pretty interesting to see the various failure modes. Some seem straightforward (e.g., the font is missing the glyphs) while others seem to be parsing limitations.

As an aside, this finally convinced me to explore using additional SSIDs in creative ways with emojis.

Re: Comparing how different devices display the SSID “á̶̛̛̓̿̈͐͆̐̇̒̑̈́͘͝aaa”

#3
The 802.11 standards have always allowed up to 32 bytes which can be filled with any data, it does not have to be in a particular encoding. In 802.11-2012 there is a separate tag SSIDEncoding which can be used to specify if these bytes are in UTF-8 or "unspecified". If the UTF-8 option is set, the SSID should be interpreted as UTF-8.

It is not clear in this case if the router sets this flag or not. Either way there is no stipulation in the spec about how the UTF-8 characters should be displayed so many of these options are potentially valid.

Re: Comparing how different devices display the SSID “á̶̛̛̓̿̈͐͆̐̇̒̑̈́͘͝aaa”

#4
> Both the s8 and the Firestick are rendering the result in what I deem as the correct way with it showing the name just with some of the vertical characters cutoff.

At least one is doing a poor job, though, because the diacritics look nothing alike…

> After asking around on the Apple discord server someone said it might be using the Mac OS Roman character set. It turns out it which is strange because iOS used UTF-8 internally and not Mac OS Roman as that was phased out with the release of Mac OS X.

I would guess that some part of IOKit is passing a C or C++ string to CoreFoundation using an inappropriate function or using the “system encoding”. I can’t remember of the top of my head, but Mac OS Roman might also be encoding 0. In any case there’s certainly a convention going on there with a poor default or some sort of strange compatibility story.

(I’m actually curious if there is “supposed” to be an encoding for this. Perhaps Mac OS Roman is just as correct and more convenient?)

Re: Comparing how different devices display the SSID “á̶̛̛̓̿̈͐͆̐̇̒̑̈́͘͝aaa”

#6
post #3

The 802.11 standards have always allowed up to 32 bytes which can be filled with any data, it does not have to be in a particular encoding. In 802.11-2012 there is a separate tag SSIDEncoding which can be used to specify if these bytes are in UTF-8 or "unspecified". If the UTF-8 option is set, the SSID should be interpreted as UTF-8. It is not clear in this case if the router sets this flag or not. Either way there i…

Huh, I'm surprised emojis aren't more popular for SSIDs... can't wait until this knowledge spreads more and we'd have a vomit of color when we open the "Wireless Networks" menu.

OTOH for most people the SSID is "Linksys 4FBD" or similar...

Re: Comparing how different devices display the SSID “á̶̛̛̓̿̈͐͆̐̇̒̑̈́͘͝aaa”

#7
Fun story about one of the devices mentioned there that I worked on. We used to store the saved wifi creds in a file named exactly what the SSID was.

Some user managed to break things, and with their permission we gathered detailed wifi logs and found they were connected to an SSID that was an ASCII depiction of the equation: [redacted] plus [redacted] equals [redacted]. The issue was the forward slashes, presumably there to add [redacted]. Must have been an awkward customer service follow up when we told them to change their SSID while they waited for an update.

Re: Comparing how different devices display the SSID “á̶̛̛̓̿̈͐͆̐̇̒̑̈́͘͝aaa”

#10
post #3

The 802.11 standards have always allowed up to 32 bytes which can be filled with any data, it does not have to be in a particular encoding. In 802.11-2012 there is a separate tag SSIDEncoding which can be used to specify if these bytes are in UTF-8 or "unspecified". If the UTF-8 option is set, the SSID should be interpreted as UTF-8. It is not clear in this case if the router sets this flag or not. Either way there i…

The bytestring was truncated after 32 bytes, in the middle of a UTF-8 byte sequence. This means the resulting truncated string is not valid UTF-8 anymore. So my guess is that most devices decide "if it's not valid UTF-8, it must $LEGACY_ENCODING".
Post reply on HN