Does anybody know if there is a way to get the raw binary data of a QR code using the android vision API ?
The QR codes I am reading have binary data (including NUL characters) in them but are built with 8 bit encoding so the full binary data block is there.
The Barcode object returned very helpfully has the string "Unknown encoding" in the rawValue field, instead of my binary data ?
Thanks for any ideas!
To answer my own question, it seems both the android vision and zxing libraries convert the bytes to utf8 if the encoding is not specified in the QR code (or left at default). I thought that the default encoding was ISO8859-1 but the libraries don't assume that.
The QR code was generated using libqrencode in linux. Setting the ECI header to 1 in the QR code when generated causes the android libraries to preserve the binary data.
So, reading the byte array with barcodes.valueAt(0).displayValue.getBytes("iso-8859-1");
returns the exact encoded bytes.
Related
We are being able to do the following.
In VBA 6/ VBA 7:
Refer a 32 bit zlibwapi.dll (VBA 6) or 64 bit zlibwapi.dll (VBA 7).
Invoke compress() or compress2() methods to generate compressed
streams
Invoke uncompress() and uncompress2() methods to decompress
compressed streams
In Java 8 (JDK 1.8 on Tomcat 8)
Have a simple java program that compresses data using the new
Deflater() instance
Have a simple Java program that decompresses using Inflater()
instance
We are failing when VBA sends out the compressed stream for Java Servlet to uncompress or when Java Servlet sends out compressed response data for VBA to decompress.
We are aware of following facts.
there are 3 formats provided by ZLib (raw, zlib and gzip).
The methods in zlibwapi.dll namely compress() and compress2()
generates compressed bytes in zlib format. This has been mentioned
in a similar thread at
Java decompressing array of bytes
Inflater() instance on Java side allows to uncompress zlib format
data as per a code sample posted at
Compression / Decompression of Strings using the deflater
Java 8 has zlib version 1.2.5 integrated as part of java.utils.zip
package.
We have ensured that we are using zlibwapi.dll version
1.2.5 on VBA side as well.
We have tried to use Hex editors to compare byte streams of compressed data independently generated by VBA and Java as well. We notice some difference in the generated compressed data. We think it is this difference that is causing both the environments to misunderstand each other.
Additionally, we think that when communication occurs, there has to be some common charset that governs the encoding/decoding scheme between both the endpoints. We have even tried to compare the hex code of byte stream generated by VBA and communicated across to Java Servlet.
The bytes seem to be getting some additional 0 bytes inserted in
between the actual set of compressed bytes while communication
occurs. This happens on VBA side. May be because of some unicode interpretation.
Whatever bytes get communicated across to Java appear entirely
different in their representation.
We need to fix our independently working code to communicate with one another and compress and decompress peacefully. We think there are 2 things to address - Getting format to match and using a charset that sends bytes as is. We are looking for any assistance from experts on this front that can help us find correct path to the possible solution. We need answers for
Does compress2() or compress() really generate zlib format?
Which charset will allow us to send bytes as is (if there are 10
bytes, we want to send 10 bytes. Not 20). If its unicode, 0 bytes
get inserted in between (10 bytes become 20 bytes because of this).
Yes.
Don't send characters. Send bytes.
I am working on understanding some ground concepts in embedded Systems. My question is similar to understand hexedit of an elf .
In order to burn compiler output to ROM, the .out file is converted to HEX (say intel-hex). I wonder how the following informations are preserved in HEX format:
Section header
Symbol tables, debug symbols, linker symbols etc.
Elf header.
If these are preserved in HEX file, how they can be read from hex file?
A bit out question but how the microcontroller on boot knows where .data .bss etc. exists in HEX and to be coppied to RAM?
None of that is preserved. A HEX file only contains the raw program and data. https://en.wikipedia.org/wiki/Intel_HEX
The microcontroller does not know where .data and .bss are located - it doesn't even know that they exist. The start-up code which is executed before main() is called contains the start addresses of those sections - the addresses are hard-coded into the program. This start-up code will be in the HEX file like everything else.
The elements in points 1 to 3 are not included in the raw binary since they serve no purpose in the application; rather they are used by the linker and the debugger on the development host, and are unnecessary for program execution where all you need is the byte values and the address to write them to, which is more or less all the hex file contains (may also contain a start address record).
Systems that have dynamic linking or self-hosted debug capabilities (such as VxWorks for example) use the object file file.
With respect to point 5, the microcontroller does not need to know; the linker uses that information when resolving absolute and relative addresses in the object code. Once filly resolved (linked), the addresses are embedded in the code directly. Again where dynamic loading/linking is used the object file meta-data is required and such systems do not normally load a raw hex file or binary.
I want to create a hex dump of a binary file in Mac OS X.
In all apps in Mac OS, when you navigate to /Contents/Resources/, there is a file (or more) with the same name as the app.
I want to write an application in Objective-C that can read that file and convert it to some kind of a hex dump, like terminal's hexdump.
Does anybody know a way to create such a hex dump using Objective-C? (or perhaps an open source hex editor, written in objective-c?)
Thanks in advance.
Hex Fiend is embeddable, if it's an editor that you're after.
Use NSData to read the file as raw data, then display the bytes however you want (for example, using a format string).
I'm trying to upload a compiled program to a microcontroller.. well my problem is not in programming or uploading things.. my problem is what to upload u.u
The program is in C and was compiled with SDCC.
The mcu is an AT89S8252 by ATMEL.
I built a simple parallel port programmer following MCU protocols for serial programming as stated in its datasheet.
So far so good.. but.. what shoud I upload to the mcu??
when compiling, SDCC generates a lot of text reports.. and then an .ihx.. I suspect I should not upload this file directly but post-process it in some way to get the actual raw bytes to upload??
any help will be highly appreciated =)
Is the .ihx file an Intel hex format file by any chance ? If it is you don't have too much more work to do before you can put your programmer to work. Intel hex format is just a specialized text format. Google Intel hex format to find what it looks like. There's a page on Wikipedia for example. Compare that to your .ihx file. If you get a match you should be able to find something to convert it to a raw binary format, ready to push down to your MCU. If you can't, you should be able to write something to do the job in an hour or so, it's very simple. I could possibly email you a tool I have written previously if you are really stuck. Good luck.
Your .ihx file is an Intel hex file I reckon. That, or the similar Motorola S-record format, is usually a good format for programmer software to read. Those formats contain the data to program, as well as the address that the data should be written to. It is more useful than a binary file, which contains no address information.
What software are you using to drive the parallel programmer, and does it accept Intel hex format or Motorola S-record files? Or, do you mean you're writing your own?
You can open an Intel hex file in a text editor and make some sense of its contents. There are many references that explain the format. E.g. Intel HEX in Wikipedia.
Is there any way to (easily) modify a string in a Mach-O binary? I want to extend the length of a pre-existing string.
https://sourceforge.net/projects/machoview
Extending the string will not be an easy task with manual editing, but at least you can get a picture about the Mach-O file structure.
This will not be an easy procedure, you cannot just go and change a string in textedit and hope it works because mach-o binaries work with encoded bytes and if 1 byte is out of order, the binary will not be executed properly. If you really wish to modify a string inside a fully assembled mach-o binary file without disrupting its delicate code you will need lots of knowledge and understanding of how mach binaries work. You will need to be able to modify it in single bytes and replacing its encoded numbers and offsets. Hopper for Mac might be able to help you understand the architecture of a mach-o binary. but if you need to replace a string with a different string with the exact same length, you might be able to simply replace its bytes so that the binary still reads it at the same length. but you will need a hexadecimal modifying application to do that.