Is it possible to attach file to JSONObject in Java (and to JSON at all)?
For example, can I attach bitmap to 'image' field?
{'user_id':'5', 'auth_token':'abc', 'image': ???}
You can convert the bitmap (or any binary data) to text using base64 (which makes it a String) I wouldn't use one of the Base64 classes in the JVM unless you are fully aware that they are for internal use. (may not be available on all JDKs and could change in future versions)
You could copy java.util.prefs.Base64 if you don't have one in a library already.
refer the answer of BalusC
A bitmap is binary data. JSON is to be represented as character data. So you need to convert binary data to character data and vice versa without loss of information.
Yes you can send image by converting that image into characters data,
Related
I am writing an Android app that takes photos and uploads them.
The API requires a base 64 encoded string representing the jpg to upload.
The Camera API gives me a byte [].
How can I go about converting this byte array into a base64 encoded string, ensuring I keep jpg format?
Currently, I am trying String encoded = Base64.encodeToString(byteArray, Base64.NO_WRAP);
But this somehow is invalid, giving me a bunch of AAAAAAAAAs in the log rather than a real base64 encoded string.
Thanks for any help
EDIT:
Actually, when I log out the contents of encoded above, I get
/9j/4UVIRXhpZgAATU0AKgAAAAgACQEPAAIAAAAPAAAAegEQAAIAAAAJAAAAigESAAMAAAABAAEAAAEaAAUAAAABAAAAlAEbAAUAAAABAAAAnAEoAAMAAAABAAIAAAITAAMAAAABAAEAAIdpAAQAAAABAAAApIglAAQAAAABAAAGCAAABi5MRyBFbGVjdHJvbmljcwAAVlM5ODUgNEcAAAAAAEgAAAABAAAASAAAAAEAFIKaAAUAAAABAAABmoKdAAUAAAABAAABoognAAMAAAABAGQAAJAAAAcAAAAEMDIyMJADAAIAAAAUAAABqpAEAAIAAAAUAAABvpEBAAcAAAAEAQIDAJIEAAoAAAABAAAB0pIHAAMAAAABAAIAAJIJAAMAAAABAAAAAJIKAAUAAAABAAAB2pJ8AAcAAAIAAAAB4pKGAAcAAAIAAAAD4qAAAAcAAAAEMDEwMKABAAMAAAABAAEAAKACAAQAAAABAAAFAKADAAQAAAABAAADwKAFAAQAAAABAAAF6qQDAAMAAAABAAAAAKQEAAUAAAABAAAF4gAAAAAAAAABAAAAGAAAAMgAAABkMjAxNTowNjowNSAyMjoxMzoxOAAyMDE1OjA2OjA1IDIyOjEzOjE4AAAAAAAAAAABAAAHCAAAA+hBTENTSUlGMFUAAAAAAAAAAQAPJ3ECAA0UIBAHEhUAAElJRjEAAAAAAABsAOsAAACdANAATACD/w0AcAAbAHUBmf/U/yUAaQA3ATL//XULZK54T27mdYBtWXreaK56Z26XceFoWWIZVx94k3BJd19u2VIoTgNW8lfWU4NWklYvU5dXjFhlUI1R20b4QuFV/1n2VKhXAAAAAA0AAAAAAAAAAAA5AAAAAAAAAAAASUlGNAAAAAAAAAAAAAAAAABw0QAAAAAAAAAAAAAAAAAAAAAAAQkREgAJAQkACQoB7u4AAgEXARgxBAEJERIACQoB//9VSUY0AIACAAAAAAC1BAAAEg0AAFxJVGgAAAAAtQQAABINAABcSQ9oAAAAAGZ3AABJSUY1QldMQapsuXcCa2JwB48AAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAAABAAAAAQAAAAEAVUlGNQABABMAAAEAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAQBVSUY2QUxIQxeFAQDiGwAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAElJRjkAAAAAAAD/AAAAAAAAAP8AAAAAAEFMQ0UAVjQuNFJNMSAgICBGb2N1c0FyZWE9MDAwMDAwMDAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZAAAAGQAAgABAAIAAAAEUjk4AAACAAcAAAAEMDEwMAAAAAAAAgAFAAEAAAABAAAAAAAGAAUAAAABAAAGJgAAAAAAAAAAAAAD6AAHAQMAAwAAAAEABgAAARIAAwAAAAEAAQAAARoABQAAAAEAAAaIARsABQAAAAEAAAaQASgAAwAAAAEAAgAAAgEABAAAAAEAAAaYAgIABAAAAAEAAD6oAAAAAAAAAEgAAAABAAAASAAAAAH/2P/bAIQACAYGBwYFCAcHBwkJCAoMFA0MCwsMGRITDxQdGh8eHRocHCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0MgEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgBIAIAAwEiAAIRAQMRAf/EAaIAAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKCxAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6AQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgsRAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8AjjHNLCPlrrG0y0P/ACxAPtxVVtHth9wFfpXL7BmqxCOdfhG9Mg1LgHaTzVzU9LaCykeKTLcYBFU1zsTPXHNZyi47msJqWw9gNsfGetKV/eZ9BTiu6OM5IwTSnoD9KgoIkzKR6imsBn0qWJWE4ypGR6Uko56UcrBMYFBKe9XNuYxVZR/q8jjNXB908UDISPkH1qaIfJUbD92ccHNSQsAuDWtJ2ZnUV0TBar3K4CEdmqxvWoLlgUXnuK3k9DKK1JV5VfpSx/d/Gmx8qtKhwMe9cZ0j42xIP96ns21gc1CDiUf71OkOJOPxpAR3Dfvs+wpsjnyz6Uy5bEin1FGSYmzQMr78w5x6VXf/AI+STUhfEZFRStiYe4FAx+nHZq0a+rGun6Vy1thdXhP/AE0H611TCtI7GNTcYTTCaeaYaozGcUxgDTyKjNAGbqV09rGCgyScc9qwHuZ7iTBVnJ9K29YH7pPrVSzUeQMAZzQBBFZE4Mp/4CKsqixjCqBVuO1klG77q+pqykEUQ6bm9TTGUo7WSXBAwPU1cjtIouWO9vfpTnnCjriqz3JPCimBbaUKOOBVaS5HQc1WZmbqaTbQArys/Un6UzaakAxRQAwJSYp9IaYEZGO9NxUhppoAux8oPpVy1XKzD/YqpDzGv0q7ZffdfVDTJMmdcSVow8wofaqd0uHNXrbm3T6UIC9pXy6lAf8AaFddtrj7L5LuJvRwf1rtStJiKsyZiNUGStaRco30rPdaQFMr7Um2pytJsqkIiC04LUgSnBaoCMLShalCU8JQBEEpwSpQtOCe1AEQWnbamCU4J7UAQhM04JUwT2p4SmBBspRH7VY2e1KEpAYDR1E0dXCPaoXHtWpzoytVQf2fJ7AH9a58qAK6XU1zp0/+4a51h8ufSuav0OvD7MUL+5XjuRSxkB04pV5hHsaBgMp5rGHxI3lsbqqrIMgHimvbRMOUFTIMxr9Kdtr0rI47sxr23jiKlOOelERZo8lcH61b1GP5EPvV
But when it actually posts to the server (using Square's Retrofit library), I get hundreds of thousands of AAAAAs after this that break the server.
Despite this, though, the logged encoded string doesn't seem long enough to encapsulate all the data that would be associated with a photo from an LG G3.
Use
byte [] data = Base64.decode(base64str);
you would need to reference commons codec from your project in order for that code to work.
I'm using Jackson streaming API to deserialise a quite large JSON (on the order of megabytes) into POJO. It's working fine, but I'd like to optimize it (both memory and processing wise, code runs on Android).
The main problem I'd like to optimize away is converting a large number of strings from UTF-8 to ISO-8859-1. Currently I use:
String result = new String(parser.getText().getBytes("ISO-8859-1"));
As I understand it, parser originally copies token content into String (getText()), then creates a byte array from it (getBytes()), which is then used to create a final String in desired encoding. Way too much allocations and copying.
Ideal solution would be if getText() would accept the encoding parameter and just give me the final string, but that's not the case.
Any other ideas, or flaws in my thinking?
You can use:
parser.getBinaryValue() (present on version 2.4 of Jackson)
or you can implement an ObjectCodec (with a method readValue(...) that knows converting bytes to String in ISO8859-1) and set it using parser.setCodec().
If you have control over the json generation, avoid using a charset different than UTF-8.
message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
}
The above is a snippet from addrbook.proto file mentioned in Google Protocol Buffer tutorials.
The requirement is that, the application that is being developed will need to decode binary data received from a socket.For example,name, id and e-mail represented as binary data.
Now, id can be read as an integer. But I am really not sure how to read name and email considering that these two can be of variable lengths. (And unfortunately, I do not get lengths prefixed before these two fields)
Application is expected to read these kind of data from a variety of sources. Our objective is to make a decoder/adapter for the different types of data originating from these sources. Then there could be different types of messages from same source too.
Thanks in advance
But I am really not sure how to read name and email considering that these two can be of variable lengths.
The entire point of a serializer such as protobuf is that you don't need to worry about that. Specifically, in the case of protobuf strings are always prefixed by their length in bytes (using UTF-8 encoding, and varint encoding of the length).
And unfortunately, I do not get lengths prefixed before these two fields
Then you aren't processing protobuf data. Protobuf is a specific data format, in the same way that xml or json is a data format. Any conversation involving "protocol buffers" only makes sense if you are actually discussing the protobuf format, or data serialized using that format.
Protocol buffers is not an arbitrary data handling API. It will not allow you to process data in any format other than protobuf.
It sounds like you might be trying to re-implement Protocol Buffers by hand; you don't need to do that (though I'm sure it would be fun). Google provides C, Java, and Python implementations to serialize and de-serialize content in protobuf format as part of the Protocol Buffers project.
I have some data in bytes, and I want to put them into Redis, but Redis only accepts binary safe string, and my data has some binary non-safe bytes. So how can I convert these bytes into binary safe string so that I can save them to Redis?
Base64 works for me, but it makes data larger, any better idea?
UPDATE: I want to serialize my protobuf object to Redis, and the serialized data has '\x00', so when I read the data from Redis, I can not deserialize the data to object. Then I tried base64, it works fine, but with larger size.
So I want to figure out how to serialize binary data (protobuf object) to Redis safely and with smaller size
You could try ISO-8859-1 encoding. This uses a one to one mapping between bytes and chars.
This could still result in corruption depending on why Redis need this "binary safe" string. You may have to use base64.
The only safe way to serialize a binary object (such as a protobuf object) is to base64 encode it. Base64 has a 33% overhead but gives you the ability to safely convert from arbitrary binary data to text (such as for use in an xml file) and back.
I would like to know if there any difference between Java byte code and .NET byte code? If there any difference, shall I take hexadecimal values of that Java byte code and .Net byte code. Because, hexadecimal is independent of languages and it is universal specification.
Problem description
We are developing a mobile application in j2me and Java. Here I am using external finger print reader for reading/verifying finger print. We are using one Java api for reading/verifying finger print.
I capture the finger template and raw image bytes. I convert the raw image bytes into hex form and stored in a separate text file.
Here we using a conversion tool (developed in .NET) that converts the hex form into image. With the help of that tool we are trying to get the image from that text file. But we cannot get the image correctly.
The .NET programmer says the Java byte and .NET byte differ. Java byte ranges from -128 to 127. But .NET byte ranges from 0 to 255. So there is a problem.
But my assumption here is: the hex is independent of Java & .net. It is common to both. So, instead of storing byte code in text file, I plan to convert that byte code into hexadecimal format. So,our .NET conversion tool automatically convert this hexadecimal into Image.
I don't know whether I am going on correct path or not?
Hexadecimal is just a way to represent numbers.
Java is compiled to bytecode and executed by a JVM.
.NET is compiled to bytecode and executed by the CLR.
The two formats are completely incompatible.
I capture the finger template and raw image bytes .I convert the raw image bytes into hex form and stored in a separate text file.
OK; note, storing as binary would have been easier (and more efficient), but that should work
Here we using a conversion tool (developed in .NET) that converts the hex form into image.With the help of that tool we are trying to get the image from that text file.But we cannot get the image correctly.
Rather than worrying about the image, the first thing to do is check where the problem is; there are two obvious scenarios:
you aren't reading the data back into the same bytes
you have the right bytes, but you can't get it to load as an image
First; figure out which of those it is, simply by storing some known data and attempting to read it back at the other end.
The .NET programmer says the java byte and .NET byte differ.Java byte ranges from -128 to 127.But .NET byte ranges from 0 to 255.So there is a problem.
That shouldn't be a problem for any well-written hex-encode. I would expect a single java byte to correctly write a single hex value between 00 and FF.
I dont know, whether i am going on Correct path or not?
Personally, I suspect you are misunderstanding the problem, which makes it likely that the solution is off the mark. If you want to make life easier, store as binary rather than text; but there is no inherent problem exchanging hex around. If I had to pack raw binary data into a text file, personally I'd probably go for base-64 rather than hex (it will be shorter), but either is fine.
As I mentioned above: first figure out whether the problem is in reading the bytes, vs processing the bytes into an image. I'm also making the assumption that the bytes here are an image format that both environments can process, and not (for example) a custom serialization format.
Yes, Java byte code and .NET’s byte code are two different things that are not interchangeable. As to the second part of your question, I have no idea what you are talking about.
Yes they are different while there are tools that can migrate from one to an other.
Search google fro java bytecode IL comparison . This one from same search