Back Of Driver's License Barcode Generator
Join GitHub today
Roxanne: Best Answer. Different states have different methods of encoding data on the driver's license, some have the data located in a magnetic stripe and some have the data encoded in a PDF417 barcode. Data is stored on the magstripe according to the American Association of Motor Vehicle Administrators. Drivers' licenses also include a 2D barcode, which is easily read with a 2D Barcode Scanner. The data stored on the magnetic stripe of a driver's license includes the following: State or Province.
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.
Sign upHave a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
commented Mar 14, 2016
I used Mobile Vision API to detect US Driver Licenses. I am able to scan the DL PDF417 barcodes and I see that driverLicense object is set within Barcode object. However for some states (Eg. FL, NC) the driverLicense object is NULL. When I checked the valueFormat in Barcode object it is set to 12 (Barcode.DRIVER_LICENSE) for working scenario and set to 7 (Barcode.TEXT) for non-working scenario. Could you confirm whether this is an issue with BarcodeScanner APIs? Sample code is as follows. |
commented Mar 15, 2016
The DL/ID parser is fairly simple and doesn't work perfectly on IDs from all states, unfortunately. There might be some jurisdiction-specific fields that are tripping it up, or they might not be using a fully spec-compliant encoding. We'd like to improve it -- if you'd like to help, the anonymized raw text of the non-working cards would be helpful in diagnosing the problem. However, if you aren't comfortable sharing it (or just aren't sure how to completely remove all identifying information) that's okay too! |
commented Mar 15, 2016
If you can't share the raw values, it would be helpful to know where the first occurrence of 'DL' appears in the values that won't parse. Normally, it would be at index 21 (e.g. '@n rANSI 636045030002DL'). |
commented Mar 15, 2016
Sure, here is the raw data from the scanner. I used the sample license from internet for FL state. |
commented Mar 15, 2016
Sample FL DL.PDF |
commented Mar 15, 2016
I got the NC state info and removed the personal info. Let me know whether this helps. This is from a valid NC state DL. @ |
commented Mar 15, 2016
Here is the NJ state DL which is working fine, 03-21 17:53:57.419 28002 28431 D BarcodeScannerActivity: Barcode Format: 2048 |
commented Mar 17, 2016
Thanks, this is very helpful (though in the future, it would be great to get an escaped literal string that preserves special characters, e.g. '@n rANSI [..]r'). The FL and NC licenses both violate the AAMVA spec in a couple ways, so we're going to make our parser more lenient for future releases. |
commented Mar 17, 2016
Thanks for the update. Could you confirm the timeline for the release with improved parser? |
commented Mar 17, 2016
We don't have a timeline to announce, but I expect a new release within a couple of months. |
referenced this issue Mar 17, 2016
ClosedPDF417 and Driver License Scan not detected #11
commented May 11, 2016 • edited
edited
Oregon license sticker (the owner moved and received a sticker from the DMV to replace the barcode with new street address information). |
commented May 11, 2016
Wow. That doesn't even attempt to follow the specs -- unfortunately, our parser won't recognize that text as DL/ID data without the leading '@n r(ANSI AAMVA)'. It also doesn't contain the required directory information. |
commented May 11, 2016
It's pretty bad. I'm just going to write a super lenient fallback for the case where despite best efforts the |
commented May 11, 2016
Actually, please disregard the earlier sample I posted; I'm not sure why, but escaping the string correctly and dumping it on a single line made the prefices and suffices I was expecting show up. These samples are also from Oregon and don't register as driver's licenses, even though they do have the
(Yes, the format of the date |
commented May 12, 2016
Thanks for the examples! However, it appears that the process of redacting personal information may have changed the length of some fields (our updated parser fails on the snippets you provided). The large block of numbers in DL/ID data is a bunch of offsets, which means you must take care not to add/remove any characters when sanitizing it. |
commented May 12, 2016 • edited
edited
Ah, my mistake. These should match the original byte positions:
|
commented May 12, 2016
Unfortunately, both of those examples are badly broken. The first claims to contain a DL block starting at offset 39 with length 285 ('DL00390285') that overruns the entire string. The second declares a block ('DL00390192') that extends partway into the next ZO block. |
commented Sep 9, 2016
Doesn't detect barcode in this sample image which contains data for a NY passport. Tried the barcode reader sample on a Nexus 5. |
commented Sep 9, 2016
Thanks for the sample. The raw contents ('@ nnnANSI') are unfortunately wildly incompatible with the specification, which says entries begin with '@n rANSI'. However, I suspect that many sample drivers licenses are produced manually and are full of errors that don't occur 'in the wild'. Real New York licenses decode fine with our parser. |
commented Sep 10, 2016
Thanks for the explanation @pchx |
commented Nov 21, 2016
The latest version of our Barcode API (part of Google Play Services 10.0) makes the DL/ID parser more lenient; it should handle a wider range of licenses now (there may still be some remaining edge cases, however). |
commented Nov 22, 2016
Cool @pchx. Let me test it out this week. Thanks for the heads up. |
commented Feb 4, 2017 • edited
edited
Pdf417 Barcode Generator Driver's License
Hello @pchx. I was wondering when does length start, i understand that it starts before 0180 and ends at the bottom? |
commented Jan 15, 2018
Not sure if this thread is still alive but Im trying to parse some drivers license at work. The issue Im running into is that the data from the scanner is coming back as one line with no return characters to separate the data fields. Anyone else run into this issue? |
commented Sep 19, 2018
Can someone fill me in on the exact format including the /n and /r? Also, what is the diamond character with the questionmark in it? Anyone know? |
commented Sep 20, 2018
@emottau I would suggest to refer to AAMVA DL spec (Table D.1 — 2D symbols header format). Also, if you see any issue in parsing please open new issue as this is closed. |
commented Jun 11, 2019
/n is line feed that separates the individual data objects in the record. /r is carriage return that as far as I can tell helps locate beginning and end to the record. For example in the Arizona DL AAMVA 2D barcode the record is ended with (nnr) this is the only occurrence of this pattern so I can easly know when the record is completely read. The diamond is actual what's called a record separator 'rs'. When decoding the buffer it has no clue what it is. In javascript I was able to use it to denote the start of the record in an Arizona DL using this code: str.includes('u001er'+'ANSI') record separator, carriage return and 'ANSI' is the beginning of the record. |
commented Jun 11, 2019
My guess it could be your bar code scanner is programmed to trim any spaces and hidden characters as it outputs . Try factory reset on the scanner. |