What is the format of a Windows Phone Advertising ID string? What is the typical length? - windows-phone-8

What are examples of the Device ID unique to Windows Phones?
As I do not have a Windows phone, I cannot look up any values myself.
Specifically I'm wondering about the typical length of Advertising IDs that Windows uses that are similar to IDFAs/AppleIDs/AndroidIDs/GooglePlay/UDID/etc.
For example, IDFAs are strings that are 36 characters in length and have the format XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX, where X = hexedecimal digit.
What is the similar format used by Windows Phones for unique IDs for advertisers?

The documentation simply states:
The advertising ID is represented as an alphanumeric string. When the advertising ID feature is turned off, this is an empty string.
The actual length of the string does not appear to be documented at present.

Related

Substring when inserting data from magnetic scanner to MS Access input field

I working on MS Access application to store customers data.
All data are stored in SQL DB.
One of input field is used to store ID number of card with magnetic strip.
Instead of typing long number I purchased usb magnetic scannert.
Scanner works but after I scan card it giving me card number with not wanted char on front and back of string, example #1234567890123456789012345-1-1-1#.
How can I get rid of additional char, leaving only 25 characters between 2nd and 26th char.
You can use
strData = Mid(strData,2,25)
after reading the data.
Also I would recommend to create a procedure for recognizing of scanner input. Use Form_KeyPress form event and start buffering symbols when first received symbol is # until you receive last character. After this you can set focus to scanner input field and display only required characters from received string. In this case you can scan the data independent of current focus and show to the user only meaning characters. I can provide example for regular laser scanner with AIM service codes (3 service characters at the begining)

Why does using using the emoji's like 😄 in chrome url caused the url to point to a random looking string?

I was basically trying to navigate to "😄.com" and found chrome to redirect to "http://xn--i28h.com/"
If you append anything before that string lets say "123😄.com" it points to http://xn--123-9h33b.com/ ie the last characters got changed!
Tried to verify this behaviour on safari and it does not changes the URL.
Can anyone help me understand what those last digits after -- could represent ?
It's called Punycode. This is how non-ascii characters in domain names are represented using ascii range.
More info: https://www.w3.org/International/articles/idn-and-iri/

incremental id as alphanumeric code

I need to show id as alphanumeric code url friendly and not more than 8 chars. And this code shouldn`t be stored, but should be decodable to the original id value.
Something like ENCODE/DECODE pair, but url friendly. How can I do this?
One possibility is to use a 64-bit hash code. Algorithm in this stackoverflow post:
Lightweight 8 byte hash function algorithm

Box Net: What is the pattern used and characters allowed during serach

I need to test the working of Box Net search in my application. For this I need more information about the search pattern. I see search results are compared with both file title and content.
Search is showing different behaviour when I have file names with special characters? Will search work when I have special characters as file names?
Following is the query I am using
boxSearch = client.getSearchManager().search(searchFileName, boxDefaultRequestObject);
Can you share me the pattern used during search and characters allowed and in what character combination results are seen?
Here are some resources on search:
https://support.box.com/hc/en-us/articles/200519888-How-do-I-search-for-files-and-folders-in-Box-
Box's search returns folder/file names and content, and it also accepts booleans. Just don't use mixed case (aNd is NOT okay, while AND or and is okay).
Box also accepts special characters in uploads and search. See the description here, as this was a fairly recent product update that came in mid-2013.
Additional special character support – Box will add support for more types of special characters across the Box website, desktop and mobile apps. Once the change is live, Box products will support almost all printable characters (except / \ or empty file names; also will not support leading or trailing spaces on files and folders).

Internationalization: Are IP Addresses entered in the same format for all cultures?

I know that IPv4 addresses are written using the dot-decimal notation. What I don't know is if each of the numeric characters entered for an IP Address is always an Arabic numeral (such as 1,2,3...) or if a non-ASCII numeral character is generally accepted for IP Address input?
For instance, if I had a IPv4 address input field localized for a Chinese culture, would it be reasonable for me to only expect Arabic numerals to be entered for each octet? Should I also expect non-ASCII characters that are also numeric?
This field would be purely for IP Address entry and would not accept host names.
Unicode and ASCII characters are the same for numerics. So yes, IP address should be the same format for all cultures.
The dotted-octet format is an international standard, this should not deviate based on culture.
a. The dot notation for numeric IP addresses is just shorthand / easy read for a direct binary equivalent.
b. It's a programmatic identifier, not a URI/text based field - so no question of internationalization.
So yes, arabic numerals all the way.
I think you would be in trouble the day you could type C# (or anything else) in another language and still have it work seamlessly. Ex. HelloWorld() and नमस्तेविश्व() -- Hindi
But so will we all :)
EDIT: Saw the comment about decimal points - don't let it be an input. Again since it's a programmatic identifier, so decimals are a fixed part of the notation.
IP Address format is standardized and must be the same for all cultures, since network devices actually depends on this exact format. So the obvious answer is, yes you might expect regular numbers and dots only.
There are some other conventions as well, for instance you might use octal IP Addresses, but frankly, I don't see any reason to accept anything but typical IP Address format.