I have an image that is base64 encoded. What is the best way to decode that in Java? Hopefully using only the libraries included with Sun Java 6.
I would like to only have to use the core java libraries
Ryan P
2009-01-22 16:03:31
+1 - the core Java libraries don't cover everything that you might possibly do; rather than reinvent the wheel, pull in code that's already written and has a high usage
kdgregory
2009-01-22 16:05:46
If you want to do it in the core Java library, download the source of Commons codec and see how they do it. It's open source.
Bill the Lizard
2009-01-22 16:07:15
This is the correct answer for the original question before I edited to include the core Java libraries. As I said in the accepted answer this is for an experiment and have to get approval for a new library and is not worth the time if the experiment does not get approved as a real project.
Ryan P
2009-01-22 16:25:35
+14
A:
Specifically in Commons Codec: class Base64 to decode(byte[] array) or encode(byte[] array)
Yuval A
2009-01-22 16:01:02
You can link the text 'Commons Codec' to the project page. That way this answer would be better than Kevin's :)
Toto
2009-06-02 17:19:27
+16
A:
No need to use commons--Sun ships a base64 encoder with Java. You can import it as such:
import sun.misc.BASE64Decoder;
And then use it like this:
BASE64Decoder decoder = new BASE64Decoder();
byte[] decodedBytes = decoder.decodeBuffer(encodedBytes);
Where encodedBytes is either a java.lang.String or a java.io.InputStream. Just beware that the sun.* classes are not "officially supported" by Sun.
EDIT: Who knew this would be the most controversial answer I'd ever post? I do know that sun.* packages are not supported or guaranteed to continue existing, and I do know about Commons and use it all the time. However, the poster asked for a class that that was "included with Sun Java 6," and that's what I was trying to answer. I agree that Commons is the best way to go in general.
MattK
2009-01-22 16:05:37
-1 - this is internal Sun code, is NOT part of J2SE (it, not portable), and may disappear at any time -- Sun explicitly says to NOT use their internal libraries in user code
kdgregory
2009-01-22 16:08:41
The main issue is the consequence of your disclaimer: the class can be removed, the package name can change... silently.
Nicolas
2009-01-22 16:15:58
Right, it's a toss-up between short-term expedience and long-term maintainability. It's included with Java 6, which is what the poster asked about, though it could certainly go away in a later rev of Java 6. If that happens, I'd agree that Commons should be used in its place.
MattK
2009-01-22 16:17:49
This is for a short term project and is just a experiment and don't want to go through the process of approval for a new library. So this is the correct answer to this question.
Ryan P
2009-01-22 16:23:47
Bzzt. In a professional environment, using an unsupported, undocumented feature is never the correct decision. And in a corporate environment, "experiments" become "production code" with no chance to fix the hacks.
kdgregory
2009-01-22 17:03:51
In a research department where that code is marked as experiment and when it is marked always gets scrapped it is the correct decision.
Ryan P
2009-01-22 20:17:12
sun.misc.BASE64Decoder has been shipped with the JRE since at least 1.1. Why won't sun just put it (and BASE64Encoder) in the java.util package?
Jason Day
2009-05-14 20:30:52
No idea, Jason. There's four or five other implementations in the JDK. Perhaps JDK7?
Tom Hawtin - tackline
2009-05-14 21:04:07
We just had the same trouble using getBytes() -> toString() and lost some (not all) byte-values during conversion. Pointing us to Base64 classes (we used the Apache implementation) with it's encode/decode methods saved our day.
Gerhard Dinhof
2010-02-25 11:21:24
@Jason: You're not the first with that idea, it has been submitted 11 (!!) years ago: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4235519
Kees Kist
2010-09-07 10:23:19
+5
A:
As an alternative to sun.misc.BASE64Decoder or non-core libraries, look at javax.mail.internet.MimeUtility.decode().
example : Encode/Decode to/from Base64
RealHowTo
2009-01-23 15:09:46
+2
A:
As of v6, Java SE ships with JAXB. javax.xml.bind.DatatypeConverter has static methods that make this easy. See parseBase64Binary() and printBase64Binary().
Jeremy Ross
2010-01-13 03:42:00
However, it seems that the `printBase64Binary(..)` method doesn't do the MIME version of Base64 ( http://en.wikipedia.org/wiki/Base64#MIME ), while the private Sun and the Commons implementations use this. Specifically, for String bigger than 76 characters, newlines are added. I didn't find how to configure JAXB's implementation for this behavior... :-(
KLE
2010-03-18 10:25:29
however, the sun implementation will ignore newlines. So they are compatible.
Esben Skov Pedersen
2010-04-20 09:52:35
+1
A:
No matter what type of app your using (experiment or not), it's just as simple as creating a single Base64.java file in your utils package using the code here:
http://migbase64.sourceforge.net/
Look at the performance charts and notice the difference: 4-5 times as fast.
javacoder
2010-03-26 01:44:11