Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
base64 decode encode
Hi,
I am going through below site.
https://www.base64decode.org/
when we encode and decode. What are advantages and disadvantages of base64 and what are other alternatives for this? please advise
I am going through below site.
https://www.base64decode.org/
when we encode and decode. What are advantages and disadvantages of base64 and what are other alternatives for this? please advise
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Base64 encoding allows you to send a string in a safe and compatible format. It's useful if you need to send encrypted data where any given encrypted byte may be outside the set of acceptable characters for a URL.
Advantage: It ensures that the data will get to its destination complete, unaltered, and readable.
Disadvantage: It takes up more space than its unencoded counterpart.
The downside is generally considered irrelevant compared to the upside.
There aren't really any alternatives worth exploring. You can roll your own but that's totally reinventing the wheel. Base64 is accepted as a standard because it addresses the issue most efficiently. Almost all programming libraries include built-in base64 encoding routines. While I don't work with Java I'm certain it is no exception. You could incorporate the encoding directly into your code to avoid going through the website.
A quick Google search uncovered this snippet:
Advantage: It ensures that the data will get to its destination complete, unaltered, and readable.
Disadvantage: It takes up more space than its unencoded counterpart.
The downside is generally considered irrelevant compared to the upside.
There aren't really any alternatives worth exploring. You can roll your own but that's totally reinventing the wheel. Base64 is accepted as a standard because it addresses the issue most efficiently. Almost all programming libraries include built-in base64 encoding routines. While I don't work with Java I'm certain it is no exception. You could incorporate the encoding directly into your code to avoid going through the website.
A quick Google search uncovered this snippet:
// encode data on your side using BASE64
byte[] bytesEncoded = Base64.encodeBase64(str .getBytes());
System.out.println("ecncoded value is " + new String(bytesEncoded ));
// Decode data on other side, by processing encoded data
byte[] valueDecoded= Base64.decodeBase64(bytesEncoded );
System.out.println("Decoded value is " + new String(valueDecoded));
While I don't work with Java I'm certain it is no exceptionI'm afraid it is :( There are undocumented classes in the JRE but their use is not endorsed.
There are of course 3rd party libraries available
There are undocumented classes in the JRE but their use is not endorsed.
There are of course 3rd party libraries available
can you name some of popular 3rd party libraries and JRE classes?
tried below example
https://www.tutorialspoint.com/java8/java8_base64.htm
above gave below output
what is difference between
Base64 Encoded String (URL) :"
and
Base64 Encoded String (Basic) :"
and
Base64 Encoded String (MIME) :
when to use which one.
when we have to select UTF8, ASCII , CP1256 etc from dropdown of the site?
when we can encode and decode from that site any one can decode right? then how security of data transmission achieved?
https://www.tutorialspoint.com/java8/java8_base64.htm
package test;
import java.util.Base64;
import java.util.UUID;
import java.io.UnsupportedEncodingException;
public class HelloWorld {
public static void main(String args[]){
try {
// Encode using basic encoder
String base64encodedString = Base64.getEncoder().encodeToString("TutorialsPoint?java8".getBytes("utf-8"));
System.out.println("Base64 Encoded String (Basic) :" + base64encodedString);
// Decode
byte[] base64decodedBytes = Base64.getDecoder().decode(base64encodedString);
System.out.println("Original String: " + new String(base64decodedBytes, "utf-8"));
base64encodedString = Base64.getUrlEncoder().encodeToString("TutorialsPoint?java8".getBytes("utf-8"));
System.out.println("Base64 Encoded String (URL) :" + base64encodedString);
StringBuilder stringBuilder = new StringBuilder();
for (int i = 0; i < 10; ++i) {
stringBuilder.append(UUID.randomUUID().toString());
}
byte[] mimeBytes = stringBuilder.toString().getBytes("utf-8");
String mimeEncodedString = Base64.getMimeEncoder().encodeToString(mimeBytes);
System.out.println("Base64 Encoded String (MIME) :" + mimeEncodedString);
}catch(UnsupportedEncodingException e){
System.out.println("Error :" + e.getMessage());
}
}
}
above gave below output
Base64 Encoded String (Basic) :VHV0b3JpYWxzUG9pbnQ/amF2YTg=
Original String: TutorialsPoint?java8
Base64 Encoded String (URL) :VHV0b3JpYWxzUG9pbnQ_amF2YTg=
Base64 Encoded String (MIME) :Njg0Y2E2ZWEtNDdiYi00MzRiLTgwYjItMGI wZDM3NTdhZ DlkN2Y1ZmR hM2ItZjE4Y i00ZWQ2LWE 3
ZTQtMTljOTZlMDZmYzU3ZjU5MzU2NzktNDQw OC00YjkxLW E4NjktMDc2 MGI1MTQwZm I4OWIyOTlh
ZmUtYjdlYi00MmM5LWI2NjYtOWVhMzA2NjUz OTFhMmI2Nz ZiMjctMTI4 ZS00ZmU3LW JkYzctYTYx
NjI0N2U3MmMzYjU0NzZkYmYtN2U4OS00ZmJk LTg0NmYtZD MwOTFlZjEw ZWJhNTczZj MzZDgtNmYy
YS00ZTgzLThhY2YtNWM2ODk4OTgyYWM4ZjBk NzlhZGMtMz Q4Yi00NGE0 LWE4NTUtNT c4ODdmMTll
MDE2MzYwNzdlYWUtYjQ3Mi00ZjM1LTk3Yjkt Mjc3ZGJjYT A2NzcwOWM4 YTAwMDYtZD liZC00Mjdh
LWJlNmItMzA5YTk1ODViNDFk
what is difference between
Base64 Encoded String (URL) :"
and
Base64 Encoded String (Basic) :"
and
Base64 Encoded String (MIME) :
when to use which one.
when we have to select UTF8, ASCII , CP1256 etc from dropdown of the site?
when we can encode and decode from that site any one can decode right? then how security of data transmission achieved?
The Base64 javadoc (https://docs.oracle.com/javase/8/docs/api/java/util/Base64.html) does a pretty good job already at describing the differences between basic, URL and MIME encoders.
when we have to select UTF8, ASCII , CP1256 etc from dropdown of the site?That's totally up to you and it may depend on the text that you intend to encode. Note that once encoded, the decoder would need to know which encoding was used in order to properly return the original text again.
then how security of data transmission achieved?You're getting confused between encoding and encrypting. What we are talking about here is "encoding" and all that it is aiming to do is convert arbitrary binary data into printable characters. It is not intended to be used for any security related purposes. "Encryption" is the process of taking some input and making it hard/impossible to read by anyone else that does NOT have a key. The above code is NOT utilising encryption.
Base64 encoding allows you to send a string in a safe and compatible format. It's useful if you need to send encrypted data where any given encrypted byte may be outside the set of acceptable characters for a URL.
the above statements may be interpreted wrongly as if base64 would do safe encryption. base64 is neither safe nor is it an encryption (see above comment from mccarl). for encryption you should use a proved algorithm like AES-128 or AES-256 and a public key you got from the receiver. After you have properly encrypted data you may use base64 to encode the encrypted binary data into printable ASCII. on the receiver side, the data would be decoded from base64 and finally decrypted using their private key.
note, if using base64 for encryption it is worse than using a simple self-written scrambler because base64 is a known algorithm that can be easily decrypted by anyone with little efforts.
Sara
Thanks for clarifying Sara. I did not intend to imply that base64 was in any way an encryption method but reading back what I wrote it could certainly be interpreted that way. What I was really saying is that if you take a string like "Hello World" and encrypt it using a nice, strong algorithm you will end up with a series of bytes with values ranging all the way from 0 to 255. Many of those characters are non-printable and won't survive even being pasted into a text message. Many more are invalid for URLs (like these characters for example: %/,!? ... and many others). Base64 encoding will ensure that the only characters you're sending are both printable and URL safe.
Base64 is encoding, not encryption.
Base64 is encoding, not encryption.
Base64 is encoding, not encryption.
any further good reading related to these concepts. I am bit unclear still
This provides a fairly detailed technical explanation of base64 encoding.
http://www.hcidata.info/base64.htm
http://www.hcidata.info/base64.htm
a fairly detailed technical explanation of base64there is one problem with the explanation: it uses the term ASCII as it would be an 8-bit code (256 code numbers). ASCII however is 7 bit only (128 code numbers) and the 8-bit enhancement is called ANSI. the first 128 code numbers of ANSI from 0 to 127 are identical to ASCII.
gudii9, i would recommend you to read the good article Russ has found nevertheless. the ASCII/ANSI mismatch is not important for base64, since base64 handles 7-bit and 8-bit character codes same way. it is simply that with ASCII Texts the bit 7 (the highest bit of range 0 ... 7) is 0, while for the enhanced ANSI characters the bit 7 is 1.
the base64 encoding is very simple. it doesn't care for characters and their representation but only for byte arrays. a byte is an unsigned 8-bit number, so it has a range from 0 to 255 decimal (2^8 == 256). in binary representation it is a sequence of 8 bits where each bit either is 0 or 1. if a bit is 1 we say the bit (at position) n is set. bit 0 is the least significant bit, bit 7 the most significant bit. the meaning of this should get clear if you bring to mind how the decimal value of a byte was calculated:
decimal = bit0*1 + bit1*2 + bit2*4 + bit3*8 + bit4*16 + bit5*32 + bit6*64 + bit7*128
since any bitx is 0 or 1 we would get decimal 255 when all bits are set by (1+2+4+8+16+32+64+128) und we would get decimal 0 if no bit is set. a number like 13 is built from (1+4+8) and therefore bit0, bit2, and bit3 are set and all others are 0.
base64 now looks at all bytes of a given text. as bytes also were used for binary data, base64 can take any input with an arbitrary number of consecutive bytes what is called a byte stream or a byte array. as the smallest unit for any data buffer is a byte, we could handle any contiguous data buffer as a byte stream and thus we can encode it with base64.
if n == length of byte stream, base64 creates or uses an empty output stream of (n/3)*4 bytes, what means the decoded buffer is one third bigger than the input stream.
bas64 now takes 3 bytes from input stream - what is 3*8==24==4*6 bits. then it takes the first 6 bits, bit0 to bit5, and puts them to an empty byte (all bits 0). we now have 6 bits from input byte what is a number from 0 to 63 and base64 uses fixed ASCII string literal
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
(length 64 characters) to convert the result to a printable ASCII character, for example code 0 -> A, code 1 -> B, code 19 -> T, code 63 -> /.
because of this method the original character of the first input byte was completely different to the resulting base64 output character. base64 puts the calculated output character to the output stream. then it takes next 6 bits from input stream and does the same. after 3 input bytes base64 has created 4 output characters and would now repeat the algorithm with the next 3 bytes of the input stream until the input stream completely was encoded. at end of stream we have a little bit different handling if the length is not a multiple of 3.
decoding now does the inverse. the output stream now is input. base64 takes 4 ASCII characters from stream. each ascii character will be converted to the index it occurred in the "ABC..." literal. the result are 4 numbers each in the range of 0 to 63, which is a 6 bit number. the 4 numbers were added to build a 24 bit number, what decodes to 3 bytes of the decoded output stream.
Sara
BASE64 has an alphabet. It consists of exactly 64 specific characters, shown by Sara above. These are important because none of them are "control characters" (or "escape characters").
Control characters are like CR (carriage return) or LF (line feed). When you send a control character to a printer, the printer does some action like skipping to a new line. When you send a "printable" character to a printer, the printer prints that character. So the base64 character set is one that only prints. It never causes a new page to eject nor underlining nor a back space nor any other 'action' other than simple printing.
That doesn't sound too important, but different control characters can also cause other things to happen. When certain control characters are sent across certain networks, there are actions that can be caused in the network itself. For example, it can be possible for a control character sequence to cause a connection to close.
Let's say you want to send some image file across a network from one system to another. The image file can have any sequence of binary bytes in it, and some sequences will close the connection. That makes it very difficult ever to send image files from one computer to another.
Also, back in earlier days of DOS, Windows, etc., there was a
driver named ANSI.SYS. It only took a very short time back in those days for some people figure out that stuff like "ANSI bombs" were possible because of that driver and other similar ones. The driver supplied a number of enhanced console functions. For example, one control sequence would cause a "clear screen" action. If a message had that control sequence in it and the message was displayed on the screen, the console screen would be cleared.
That's not a particularly bad action, but another action turned off the display of characters so that the next characters never actually displayed on the screen. That allowed a message to be something like this:
(Not actually a true character-by-character example, but the three actions were actually possible and done. It was about that simple.)
When that message was displayed on the console, a command to delete the content of the C: drive would be automatically typed and the {Enter} key would cause the command to run.
If you sent a message like that through e-mail, the recipient could lose his/her C: drive by opening and reading the e-mail item.
For reasons like those, network protocols such as SMTP were originally defined to allow ONLY printable characters to be sent and received in messages. Other non-printable characters could be sent through the protocols, but only by the clients and servers, not as part of the messages themselves. Those controls included things like end-of-message and close-connection.
Eventually, things like attachments became wanted. Previously, FTP would be used to send files; but many files were thought to be too small (and too many of them) to always have to start FTP sessions.
But attachments often had sequences of bytes that would be interpreted as controls, so BASE64 was designed as a way of transforming (encoding) the bytes into values that weren't problems. What makes it useful is that the algorithm is reversible -- the encoded bytes are easy to return back to their original values. The is no password nor secret key needed.
Any server or client can send and receive base64-encoded messages, and everything comes out the same as it went in. Meanwhile, no control characters ever get sent through any network.
Control characters are like CR (carriage return) or LF (line feed). When you send a control character to a printer, the printer does some action like skipping to a new line. When you send a "printable" character to a printer, the printer prints that character. So the base64 character set is one that only prints. It never causes a new page to eject nor underlining nor a back space nor any other 'action' other than simple printing.
That doesn't sound too important, but different control characters can also cause other things to happen. When certain control characters are sent across certain networks, there are actions that can be caused in the network itself. For example, it can be possible for a control character sequence to cause a connection to close.
Let's say you want to send some image file across a network from one system to another. The image file can have any sequence of binary bytes in it, and some sequences will close the connection. That makes it very difficult ever to send image files from one computer to another.
Also, back in earlier days of DOS, Windows, etc., there was a
driver named ANSI.SYS. It only took a very short time back in those days for some people figure out that stuff like "ANSI bombs" were possible because of that driver and other similar ones. The driver supplied a number of enhanced console functions. For example, one control sequence would cause a "clear screen" action. If a message had that control sequence in it and the message was displayed on the screen, the console screen would be cleared.
That's not a particularly bad action, but another action turned off the display of characters so that the next characters never actually displayed on the screen. That allowed a message to be something like this:
- Set non-display.
- (Type)del c:/*
- {Enter}
(Not actually a true character-by-character example, but the three actions were actually possible and done. It was about that simple.)
When that message was displayed on the console, a command to delete the content of the C: drive would be automatically typed and the {Enter} key would cause the command to run.
If you sent a message like that through e-mail, the recipient could lose his/her C: drive by opening and reading the e-mail item.
For reasons like those, network protocols such as SMTP were originally defined to allow ONLY printable characters to be sent and received in messages. Other non-printable characters could be sent through the protocols, but only by the clients and servers, not as part of the messages themselves. Those controls included things like end-of-message and close-connection.
Eventually, things like attachments became wanted. Previously, FTP would be used to send files; but many files were thought to be too small (and too many of them) to always have to start FTP sessions.
But attachments often had sequences of bytes that would be interpreted as controls, so BASE64 was designed as a way of transforming (encoding) the bytes into values that weren't problems. What makes it useful is that the algorithm is reversible -- the encoded bytes are easy to return back to their original values. The is no password nor secret key needed.
Any server or client can send and receive base64-encoded messages, and everything comes out the same as it went in. Meanwhile, no control characters ever get sent through any network.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial