Can the Card Name (i.e. the cardholder name, not the card type) contain non-ASCII characters?
Example: "JOSÉ GONZÁLEZ".
The character set that is used does not allow for diacritics. In brief, it only allows uppercase ASCII characters.
The restriction ultimately comes from the historical way in which banking cards encode data onto the magnetic stripe (as defined in ISO 7811). The data is encoded in a 7 bits per character format known as ITU-T.50
The cardholder name is encoded with up to 26 characters, each within the range from hex 20-5F. You can see the table for this here: http://www.zytrax.com/tech/ia5.html
Magnetic stripe can store even punctuation symbols like ! " * # % & ( ) ^ : ; < > = ? [ / ] _
But in practice cardholders names uses only:
Range of English uppercase letters
Apostrophe (') for names like "Gareth O'Hare"
Minus (-) for double names like "Alexandru-Cristian"
Dot (.) for honorific prefixes like "MR.", "MRS.", "MISS.", "MS.", "DR.", "THE."
Dot (.) for initials like "Jimmy L. Morgan", "J.P. Teron"
Indeed, only ASCII characters are allowed. But other manipulation is allowed. One can print the name on the first or the second line. One can choose with or without dots and so on.
So, you can't make the customer happy with diacrits (thinks Norwegian and German names). But you can the customer let choose between full firstname of only one character (e.g. JOSE GONZALES or J. GONZALES). It helps to make the customer happy.
Chip cards (aka smart Cards, EMV cards) contain and can return a plethora of different values including "Cardholder Name" (tag 5F20) and "Cardholder Name Extended" (tag 9F0B). EMV Co. says that both of these tags should follow ISO 7813 but I've already seen one card (an "NH Card" from Korea Air) in which tag 5F20 contained lowercase characters. Pandora's box has been opened!
The credit card processors I've used in the past only allowed ASCII in the cardholder name, but you should check with your credit card processor to see what their requirements/restrictions are.
Related
In the past, we've used ZPL to create Code39 barcodes with a TAB character encoded in the middle using something similar to the following:
*USERNAME$IPASSWORD*
The $I in the middle gets translated to a TAB by the barcode scanners we use.
Now we have a need to do the same thing, but using Code128. With Code39, all the text needs to be uppercase (unless you're using Code39Extended, which supports lowercase letters). Because some of the data that is going to be encoded will be lowercase, we need to use Code128 B for most of the barcode, switching to Code128 A in the middle to encode the TAB character, then back to Code128 B for the final part.
Looking through the "ZPL II Programming Guide", it should be as easy as:
>:username>7{TAB}>6PA55w0rd
The >: at the beginning sets the subset to B, the >7 changes the subset to A, and the >6 changes the subset back to B. The problem I'm having (and haven't found a solution after almost a week of searching) is: How do I encode a TAB character using only text?
Use the ^FH (field hexidecimal encoding) command immediately prior to your field data. Based on your example:
^FH_^FD>:username>7_09>6PA55w0rd^FS
Where the underscore '_' is used as the escape character and 09 is the hex value for tab.
Also note that if the chosen escape character appears in the user name or password, you will need to escape it as well.
I tried what Mark Warren suggested, but unfortunately, it didn't work. It did, however, get me looking back through the ZPL II Programming Guide and I found the following, which I had overlooked before:
Code 128, Subsets A and C are programmed in pairs of digits, 00 to 99, in the field data string.
...
In Subset A, each pair of digits results in a single character being encoded in the bar code...
So, since 73 equates to a TAB in Subset A, I tried the following:
>:username>773>6PA55w0rd
And it worked!
Im trying to work out how to put an input mask on initials which will allow for initials that are two/three letters on.
I have tried entering >L?L< but this only allows three letter initials to be entered and not two letter initials.
Is there another symbol I should be using other than '?' that means that the user does not have to enter a character in that place?
I would suggest >LL?
> forces everything to uppercase
L is a required character
? is an optional character
I am trying to come to terms with how a barcode is decoded and generated by a scanner.
A note from the client says the following generated bar code consists of extra characters:
Generated Code: |2389299920014}
Extra Characters: Apparently the first two and last three characters are not part of the bar code.
Question
Are the extra characters attached by the bar code reader (therefore dependent on the scanner) or are they an intrinsic part of the barcode?
Here is a sample image of a barcode:
http://imageshack.us/a/img824/1862/dm6x.jpg
Thanks
[SOLVED] My apologies. This was just another one of those cases of 'shooting your mouth off' without doing proper research.
Solution The code is EAN13. The prefix and suffix are probably scanner dependent. The 13 digits in between are as follows (first digit from the left) Check Sum (Next 9 digits) Company Id + Item Id (Last 3 Digits ) GS1 prefix
It's hard to answer without understanding what format you are trying to encode, what the intended contents are, and what the purported contents are.
Some formats add extra information as part of the encoding process, but it does not become part of the content. When correctly encoded and decoded, the output should match the input exactly.
Barcodes encode what they encode and there is no data that is somehow part of the barcode but not somehow encoded in it.
EAN-13 has no scanner-dependent considerations, no. The encoding and decoding of a given number is the same everywhere. EAN-13 encodes 13 digits, so I am not sure what the 13 digits "in between" mean.
You mention GS1, which is something else. A family of barcodes in fact. You'd have to say what specifically you are using. The GS1 encodings are likewise not ambiguous or scanner-dependent. You know what you want to encode, you encode it exactly, it's read exactly.
When I get data from some website, sometime the data is encode in utf8 but look like this:
Thỏ , Nạt
The accent mark is seperated from character when in fact these string must be:
Thỏ, Nạt
I don't know what is the problem here and how to correct it. Can someone help me with this
The first sample string contains two Vietnamese characters in decomposed form. The first one of them is “ỏ”, consisting of simple letter “o” followed by U+0309 COMBINING HOOK ABOVE.
The second sample string has those characters in precomposed form. The first one of them is “ỏ” U+1ECF LATIN SMALL LETTER O WITH HOOK ABOVE.
The decomposed and precomposed form are defined to be “canonical equivalent” and are normally expected to result in the same rendering (though this does not always happen). They are not identical, however; in programmatic comparison of characters and strings, they are very much different.
Mostly Latin letters with diacritics, such as “é” and “ä”, are used in precomposed form only, since that’s what keyboard drivers, online keyboards, character picking utilities, etc., normally produce. However, Vietnamese keyboard drivers often work so that some diacritic marks are entered after entering a base character, and the diacritic is thus produced as a combining character, i.e. the letter (like “ỏ”) is then in decomposed form.
One way of dealing with this issue, recommended in many contexts, is to convert your strings to Normalization Form C (NFC). This would put these characters into precomposed form. Note, however, that conversion to NFC removes some other distinctions, too (but this is not relevant if the text is in Vietnamese only and does not contain special symbols).
It remains a mystery why the first sample string has a space character before the comma.
I'm using the mini_fb gem in ruby to create an ad group:
response = fb_ads.create_ad_groups_with_image('adgroup_specs' => adgroup_specs)
If the ad text contains certain characters, such as ∑, this fails with the following error:
The text contains an invalid character. Ads may only contain alphanumeric characters, punctuation, and spaces. Note that line breaks and = are not allowed.
However, there are many other characters, such as π, ö é, î, ä, å, ç, è, and ø, that are accepted just fine. Is there a list somewhere of what characters Facebook accepts in its ads, or a quick API call that I can make to check whether a string will pass?
The Facebook Ads system allows ad titles and body text in most languages around the world. However the symbol you've pasted in above is in a Unicode range dedicated to mathematical symbols. It isn't allowed in the body or title of a Facebook ad. The character you entered (Unicode U2211) has a good alternate in the Greek alphabet range of Unicode at U03A3. Entering HTML entities is not going to render like you want.
I don't have a link for you, but it is very likely that Facebook only supports/allows extended ASCII characters in their ads. That would include the characters you listed, but the "sum" character you listed is not within extended ascii. Have you tried using html entities for the "special" characters you need?