Open nate1280 opened 5 years ago
Do you happen to have a sample of the raw barcode (with personally identifiable information removed/changed)? I wonder if Illinois just didn't follow the spec or if there is anything else off about the header.
Closing since I don't have example information to test this. Feel free to re-open if you can provide an anonymized example Illinois license as a test case for this issue.
I can verify that this is a genuine issue. I can't provide any sample barcodes (for privacy reasons), but we're seeing a lot of barcodes where the offset is "2901" and as a result our parsing is failing.
Edit: We don't actually use this library, but this issue was useful in confirming that this is a problem with how Illinois have implemented the AAMVA spec.
I can confirm this, here is an anonymized example (they also messed up the header and is missing the character between the \n and \r
@\n\rANSI 6360350201DL00290181DLDAAXXXX,XXXXXXXXX,Y\nDAQC9999999999\nDBA20201216\nDBB19941216\nDAG123 XXXXXXX DR\nDAIXXXXXXXXX\nDAJIL\nDAK999999999 \nDARD\nDASB \nDAT*****\nDBD20160112\nDBCF\nDAU505\nDAW113\nDAYBRN\n\r
When parsing an Illinois barcode that uses the 2003 AAMVA spec, I get an ArgumentOutOfRangeException thrown by the GetSubfileRecords.
Running through it manually, it attempts to parse the offset as Substring(23, 4) which results in "2901", this is incorrect, it seems it needs to be shifted left 2 characters to return "0029", with this offset it parses correctly.
https://github.com/c0shea/IdParser/blob/1002a17d267b0789014703bec5b2513a28a8adb7/IdParser/Barcode.cs#L202
I replaced the above with the following
And it seems to parse correctly now.