I'm trying to read AADHAAR QR code, a govt ID card in India. The user manual says -
Scanned data contains the following data fields in given sequence, which is embedded in byte array with the delimiter of byte value ”255” -
referenceId
name
date of birth
My question is,
What does it mean ?
Can someone explain with an example?
Decoding the Aadhaar QR code consists of several steps outlined in Unique Identification Authority of India (UIDAI) in chapter 3.2:
The first few steps are:
Convert the base10 value of Secure QR code into Big Integer.
Convert the Big Integer into byte array.
Decompress the byte array.
Read the value of byte array from index 0 to till first delimiter value "255" and convert this byte array value into string with encoding "ISO-8859-1". We will get the Email_mobile_present_bit_indicator_value as 0, 1, 2 or 3.
Once you have the decompressed array, you can simply search for the first element in the array containing -1, which is how the byte value 255 looks in Java as Java uses signed integer for bytes. The bytes before the -1 can be converted to a string.
These two steps are then repeating several times with the remaining data in the array to extract further values.
Extracting the photo and the signature are slightly different as they are not strings but binary data. Again, the steps are described in the referenced document.
Related
I need to solve the problem:
I have 10 different bytes(2^8) and each byte value range is 0 to 255. It needs to encode into 3- bytes(2^24) length. Later I need to retrieve the original values from encoded 3-byte values.
I tried Cantor and Szuszik functions but the encoded value is exceeding the 3 Byte length.
Is there any other alternative way to solve this problem in Maths or Computer Science/binary logic?
I have text file which contains over 1kk integer numbers. I want to read the n-th number in constant time. I'm not allowed to put all integers in the array. I heard that there is a technique which operates with bytes, so I could just write method "getNthInteger(int nth, int elementLengthInBytes)" or something like that. Please give me reference to this technique, any help is appreciated!
You convert each integer to an array of bytes of some length L, then write the bytes to the file. L must be exactly the same for each integer. Then to read integer N, read L bytes starting from byte N*L.
For example:
You can write an integer to a file as 4 bytes with java.io.RandomAccessFile.writeInt(int).
You can read the Nth integer with:
java.io.RandomAccessFile.seek(n*4);
int i = java.io.RandomAccessFile.readInt();
Replace java.io.RandomAccessFile with an actual object of type java.io.RandomAccessFile.
I have a file that contains integer values of different bit lengths (4 bytes, 2 bytes), but I don't know the layout of these values in the file (i.e. whether a value is a 4 bytes or 2 bytes integer). For example, a file may have two 4-byte integers followed by five 2-byte integers, and another file may have three 2-byte integers first and then four 4-byte integers. Is there a way to read such values?
I want to write code that takes such a file and reads a value irrespective of its byte size. Right now I am using DataInputStream, and by knowing the layout of the values, using some viewer in advance to read the values. But in this manner everything is hard coded, and my code is not generic.
Your going to have to "parse" or "read" or "do something" with the viewer data and use the refactored viewer info as file format definition info during the reads.
I have numbers written as ASCII codes each of 2 bytes which wastes a lot of the space. I want to convert those number to their corresponding ASCII code to save the space.
Any idea?
If you mean characters, Java uses two bytes per character as part of its Unicode support. If you give ASCII values, Java will make the upper byte zero. You won't save a thing.
If you mean floats or doubles or ints, the bytes per value are fixed there as well.
You're barking up the wrong tree. I don't think this will save you anything no matter what you do.
You're better off writing C or C++ if you need that kind of optimization, not Java.
My first thought is that this is an imagined optimization that isn't supported by data. The only application that would justify something like this would be scientific computing on a large scale. Even that wouldn't justify it, because you'll need more precision than a byte per value.
You can use the parse methods on the default types' class. For example, if these numbers are integers and are stored as string "34", you can use Integer.parseInt("34") which returns you a single int whose value is 34. Similarly for Double, Float and Long.
Do you want to convert the Hex number to bytes? If so, this is your answer:
Convert a string representation of a hex dump to a byte array using Java?
If you want to convert number to byte -> http://snippets.dzone.com/posts/show/93
Convert the two digit ASCII string to a byte. When you need the ASCII back just convert it to a string. The following code shows how to do this for "95".
public class Main {
public static void main(String[] args) {
byte b = Byte.parseByte("95");
String bString = "" + b;
}
}
If you need to change the way they are stored in a file, just read the two digit text numbers in as strings and write them out to another file as bytes.
I'm currently writing a very small Java program to implement a one-time-pad, where the pad (or key) itself is generated as a series of bytes using a SecureRandom object, which is seeded using a simple string with the SHA-512 algorithm.
Generating the one-time-pad hasn't caused any problems, and if I supply the same seed string each time, as expected I get the same sequence of psuedo-random numbers, making the decryption process possible as long as the person decrypting has the seed string used to encrypt.
When I try to encrypt a file, the program reads in the data 64 chars at a time (except for the end of file, which is generally an odd number), and generates 64 bytes (or matching amount) of psuedo random bytes. XOR is performed between the elements of both arrays, the resulting char array containing the cipher characters is written to file, and the process repeats until all text in the file has been read.
Now, because Java treats all primitives as signed numbers (the data type byte ranges from -128 to 127, not 0 to 255) this means that the XOR operation can (and does) result in some negative values (-128 to -1). It seems that Java does not recognise these values as valid ASCII, and simply writes a ? (question mark) to the file for any negative values. When it comes to reading from the file to decrypt the cipher text, the negative value that resulted in the ? to be written to file is lost, replaced with 63, the valid ASCII code for a question mark.
This means that XORing this value is useless, without the original value there is no way to produce the plaintext. Incidentally, if I reproduce the behaviour of encrypting some data and then decrypting the data immediately after, in the same program run, and printing status along the way, there are no problems. Only if the data is written to file is the information lost.
I should also mention that I did try adding 128 to each encryption XOR result, and then subtracting it before performing the decryption XOR (to put each value in a valid ASCII range), but the ? problem still showed up because there are 31 ASCII codes from 128 to 159 that I'm unable to read and appear as ?
I've been banging my head off the wall on this for a while now, any help is appreciated.
Cheers.
This is very confused. If you are processing a char array, the elements are 16 bits wide, they are unsigned, and not all values are valid. So (a) you cant possibly be having a problem with signs or bytes, and (b) you shouldn't be doing that at all. You should be reading the file into a byte array, XOR-ing, and writing out the byte array directly to the output file. No Readers or Writers, no chars, no Strings.
I guess the problem is in the way you write the file. Write directly the converted byte array to a FileOutputStream and do not try to convert it to string first. For reading, do the same thing, read it to a byte array.