Re: Please update wiki page of BarcodeContents in regard to WIFI

[Sean Owen]

I updated it. There is no real standard here, but to the extent there is, this is meant to mimic DoCoMo's MECARD and related formats. Field order does not matter. P is not used with nopass.

[herrhausb]

Am Freitag, 6. Juli 2012 23:56:50 UTC+2 schrieb Sean Owen:

I updated it. There is no real standard here, but to the extent there is, this is meant to mimic DoCoMo's MECARD and related formats. Field order does not matter. P is not used with nopass.

In a way you are defining the standard here. :-)

I am aware that you mostly deal with the reader side, but giving hints to people writing QR code generators certainly can't harm.

BTW: I think I have seen at least one app "Swift WiFi" that claims to generate QR codes for WPA-EAP connections. I wonder how they encode that type and the plethora of additional fields that can be configured there (including X509 certificates!). Unfortunately it will only generate QR codes for networks that it is currently connected to, and I don't have an WPA-EAP enabled network to test it with, but maybe you could get in touch with those guys and talk about the/a standard. The app is fairly new (25.6.2012) so they should be open for suggestions / changes.

BTW: For WPA wifis their generator implementation creates this example:

WIFI:S:"mynetwork";T:WPA;P:"mypass";;

As You see there are double quotes around SSID and password. I don't know how the DoCoMo MECARD suggests to handle double quotes or semicolon when they happen to be part of a value, but I smell trouble...

cheers -h.

[Sean Owen]

I don't know any more than what's on the wiki. As you say the 'standard' is fairly de facto. What kind of syntax do you see from the other app? Might as well call it official.

The quotes are fine, yes. I will describe this on the wiki.

[Sean Owen]

Actually quotes aren't optional -- they need to be specified for Android if the SSID or password is ambiguous and could be hex or ASCII.

[herrhausb]

Am Samstag, 7. Juli 2012 10:35:03 UTC+2 schrieb Sean Owen:

Actually quotes aren't optional -- they need to be specified for Android if the SSID or password is ambiguous and could be hex or ASCII.

Interesting. Does the MECARD standard describe what to do if a value contains ":" or ";;"?

What should happen if my SSID is "P:-)" or ";-)"
or my password contains ";", ":", or even doublequotes ?

[Ryan Strope]

The "Escape" character in DoCoMo MeCard is the YEN symbol

unicode HEX      00A5

it's used to escape ; : , and the YEN symbol itself

[Ryan Strope]

Here's the page with all the info

http://www.nttdocomo.co.jp/english/service/developer/make/content/barcode/function/application/common/

On Saturday, July 7, 2012 7:31:20 PM UTC-4, herrhausb wrote:

[Sean Owen]

Yes, you use the same syntax for escaping and yes that is already implemented.  The symbol is really backslash. I know it says ¥ but this is just what 0x5c is in some encoding prevalent in Japan. ¥ isn't encodeable in any QR code mode! (Well, without a special ECI segment.)

[Ryan Strope]

Ok I'll show my ignorance of unicode and QR codes for the sake of an explanation

QR-Codes support things such as VCARD and VEVENTS etc which all use a UTF-8 format.

So how can you say that QR codes can't encode the ¥? is it not a unicode character?

Yes granted it replaces the backslash in some fonts but if you're referencing it as the hex value of the unicode character instead of the literal \ or ¥ then it shouldn't matter right?

I figured this would be a good opportunity to get a small nugget of knowledge about unicode and QR codes.

[Sean Owen]

It can in UTF8 encoding. Actually Kanji mode probably could. But the 'normal' modes can't. I'm only noting that as all the more reason to understand this almost a typo. Other DoCoMo resources are clearer on the byte value used for escape which was clearly chosen because its backslash. The Yen symbol is not the escape character trust me.

[Ryan Strope]

Ok I get that but there are still fonts that have the YEN symbol in place of the \ Meriyo and Meriyo UI are two on my system there is actually 2 Yen symbols (though one is listed as the reverse solidus i.e \)

But are you saying that it is a literal \ or is it the unicode 005C?

Or does unicode automatically know to subsitute for say the YEN (Sudo \) symbol if we're decoding and sending the text output to a font that does not have the literal \

Sorry for the dumb question for some reason unicode gets me a bit confused from time to time,and from the research I did earlier this morning this exact issue (YEN vs \) is one of the "known issues" of unicode

[Sean Owen]

The most correct thing to say is that the character '\' is used for escaping. Yes, Unicode 0x5C, not 0xA5. Yen symbol happens to be 0x5C in some encoding. I don't know if it's a known issue or not, bigger than QR codes; I forget the details. I remember being puzzled on this 5 years ago and figuring out that it was definitely really backslash!

[Ryan Strope]

That makes sense, I'm pretty sure now that I think about it, in every high level language I've working in over the years \ has been the De-facto escape character.

I was more asking the question because of the work I'm doing on the parsing section of the C# code mainly because I was using the Unicode representation of 0x5C to represent the escape character instead of a literal \ in my regular expressions, and I wanted to be certain that was covering both cases (even if the second case is possibly an extremely rare one)

From what I read the Japanese were not as quick to adopt a standard representation for digital text so when unicode was released there was some overlap, the Yen and \ was one case, because many Japanese programers used the yen symbol a lot in their programing (pre unicode).  Thinking more about it that makes perfect sense since yen sits in the same place the \ does in the old ASCII table and the majority of the main stream programing languages expected ASCII 92 as the escape character and for them that was the yen key. Of course I'm just speculating but I can imagine how this could throw a wrench in the works

But all that aside you've been quite helpful with the information.

Thanks for the clarification.