This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is the use of base 64 encoding?
I've seen many code fragments that base64 encode images before transmitting over HTTP protocol.
I am wondering why do we need it?
It's not necessary, but it enables you to embed images without performing additional HTTP requests (where, in some cases, it's not possible or permitted).
From the Wikipedia entry on Base64:
The term Base64 refers to a specific
MIME content transfer encoding. It is
also used as a generic term for any
similar encoding scheme that encodes
binary data by treating it numerically
and translating it into a base 64
representation. The particular choice
of base is due to the history of
character set encoding: one can choose
a set of 64 characters that is both
part of the subset common to most
encodings, and also printable. This
combination leaves the data unlikely
to be modified in transit through
systems, such as email, which were
traditionally not 8-bit clean.
And specifically regarding HTTP:
Base64 encoding can be helpful when
fairly lengthy identifying information
is used in an HTTP environment. For
example, a database persistence
framework for Java objects might use
Base64 encoding to encode a relatively
large unique id (generally 128-bit
UUIDs) into a string for use as an
HTTP parameter in HTTP forms or HTTP
GET URLs. Also, many applications need
to encode binary data in a way that is
convenient for inclusion in URLs,
including in hidden web form fields,
and Base64 is a convenient encoding to
render them in not only a compact way,
but in a relatively unreadable one
when trying to obscure the nature of
data from a casual human observer.
The HTTP protocol isn't guaranteed to be "8 bit clean", so it might mangle a binary stream.
Related
This question already has answers here:
What is base 64 encoding used for?
(19 answers)
Closed 8 years ago.
Hi my question is that does base64_encode does unique data every time we run the script?
Below is the code.
<?php
$id = 1;
echo base64_encode($id);
?>
If it does not provide the unique data every time then what is the point in encoding the string and passing in url. Does that make url safe??
Base64 encoding is not a method of encryption. It is used for encoding binary data into text, which makes it safer to transmit over the internet.
If you stream bits, some protocols may interpret it differently. Streaming text is much more reliable.
What is base 64 encoding used for?
If you need true encryption, you need to use something which hashes based on a salt you can hide from other users, such as the mcrypt library.
http://php.net/manual/en/book.mcrypt.php
base64-encoding does not provide unique data. Its purpose is to provide a compact representation of binary data in string form. In your example, you are encoding non-binary data, so it is not very practical. However, if you wanted to encode a string containing a newline and punctuation and pass it via the URL, you cannot send the binary data directly.
For example, if you had the string Hello, World!!\n there would be three punctuation marks, a space and a newline that all need to be URL-encoded. Doing that gives the result:
Hello%2C+World%21%21%0A
Which is 23 bytes long.
On the other hand if you were to base64-encode the same string, the result would be:
SGVsbG8sIFdvcmxkISEK
Which is 20 characters, or about 13% shorter. This adds up quickly if you've got a lot of non-alphanumeric characters or a large amount of data.
So the primary advantage of base64 encoding is its slightly more compact representation of certain data.
Base64 encoding is a way of representing data using only a limited set of characters. You use it when you need to store data in something such as a cookie that can't handle the data in its original format.
Base64 only uses 6 bits per character (2^6 = 64) to create textual data from image files. This causes an in-efficiency.
According to a wikipedia entry on Base64, this in-efficiency is to protect against 8 bit dirty things like email.
Is Ajax Posting 8 bit clean? If so, is there an alternative to using Base64?
php.net ( as does wikipedia ) claims a 33% in-efficiency for base64_encode..
Kind of. All JavaScript strings are UTF-16, not byte strings. If you're sending the data with send, then it will be encoded into UTF-8 before it is sent. As such, you can convert the bytes into Unicode code points, which will then be encoded into UTF-8. When it reaches the server, you'll have to decode the UTF-8 and then convert the code points back into bytes.
For 7-bit data, this will not expand the size of the data at all. For 8-bit data with the most significant bit always set, it will double the size of the data. For 8-bit data with the most significant bit set half of the time, it will increase the size of your data by 50%, which is worse than the Base64 33.3͞% increase.
On the other hand, using XMLHttpRequest Level 2 will allows you to send binary data by passing send an ArrayBuffer, Blob, or FormData. However, XMLHttpRequest Level 2 is only supported in newer browsers.
I think AJAX posting is the same as a generic POST requests in that aspect; that's why we need 'multipart/form-data' for sending files' content, for example. Usually the data gets url encoded, but Base64 is perhaps a better way, as it's (generally) more efficient.
UPDATE: It might be helpful to look at this the other way. ) You need some stream of values, that might possibly take all 8 bits, to safely pass the 7-bit filtering. The perfect solution is to use '7-to-8' encoding, so each 7 bytes become 8 'safe' characters. But this is not applicable, as some of these 7-bit characters are actually used to specify some additional (meta) information about the stream...
Now you have a dilemma: either use the next integer (6 bit - that is base64) - or try to invent a scheme with 'non-integer' divider. Such schemes exist (check Ascii85, for example), but they are rarely used.
i am reading that in a paper
Any end-user could modify these values (since they are originated in his browser), but if the web developer encodes for example, converting all characters to URL-encoding (hexadecimal) or uses a particular encoding to send GET/POST parameters (e .g., base64 with some secret key string) the attack vector must be revisited.
so, this means that is good practice encoding the variables with base 64 and a secret key?
how is implemented an url-encoding?
this makes sense? i never read about encoding variables as a way of protection
thanks
paper page 5
Base64 encoding schemes are commonly used when there is a need to encode binary data that needs be stored and transferred over media that are designed to deal with textual data (like HTTP). This is to ensure that the data remains intact without modification during transport.
So yes it can be a way of protecting the original data form unwanted modification. But remember it is not anywhere near Encryption.
The specification for URLs (RFC 1738, Dec. '94) poses a problem, in that it limits the use of allowed characters in URLs to only a limited subset of the US-ASCII character set:
"...Only alphanumerics [0-9a-zA-Z], the special characters "$-_.+!*'()," [not including the quotes - ed], and reserved characters used for their reserved purposes may be used unencoded within a URL."
Here's nice article on that http://www.blooberry.com/indexdot/html/topics/urlencoding.htm
In PHP you can use string urlencode ( string $str ) method for URL Encoding.
so, this means that is good practice
encoding the variables with base 64
and a secret key? how is implemented
an url-encoding?
this makes sense?
No, it doesn't really make sense. base64 is not an encryption scheme, it's just a way of encoding binary data into a subset of 7-bit text that isn't likely to be altered by email servers, etc.
base64 does not have a key, not can it encrypt or decrypt.
My guess is that the paper's authors were talking about some encryption scheme prior to the bit you quoted, and they only mentioned base64 later as a way to transmit their already encrypted data safely over HTTP GET or POST parameters.
Without seeing the rest of what you quoted from, we don't know.
base 64 encode does not provide any security whatsoever. it is almost as bad as a mono-alphabetic substitution cipher
here's how to encode/decode in base 64, also known as radix64
http://en.wikipedia.org/wiki/Base64
im not sure what it means to encode with a key in this context
Hey, guys. I work for http://pastebin.com and we have a little issue with the new API and char encoding.
On the site itself we run a meta tag which specifies that everything on the site, including the forms, are utf-8. Because of this all chars get stored in the right way, without having to modify any char types.
With the API however, people can send data from all kinds of different sources & forms, and therefor has to get checked and possibly changed, before storing it.
Chars that are giving a problem are for example:
고객님이 티빙
Iñtërnâtiônàlizætiøn
♥♥♥♥♥
идите в *оопу, он лучший)
What would be a good way to approach this data input to the API to make sure all chars get stored in a valid UTF-8 format, which will work on our site.
Assuming your client is sending utf8 data and headers correctly: Sounds like you're doing a utf8_encode() on already-encoded utf8 data.
Duplicate: What is the best way to handle uploaded text files of different encodings?
In a nutshell, the only reliable way is having the client specify what encoding they are using. Automatic encoding detection is imperfect and tends to be unreliable.
You could for example specify that incoming data needs an encoding specified if it's not UTF-8.
I am passing a lot of data between PHP and JavaScript. I am using JSON and json_encode in php, but the problem here is that I am passing a lot of numbers stored as strings - for example, numbers like 1.2345.
Is there a way to pass the data directly as numbers (floats, integers) and not have to convert it to ASCII and then back?
Thanks,
No. HTTP is a byte stream protocol(*); anything that goes down it has to be packed into bytes. You can certainly use a more compact packed binary representation of values if you like, but it's going to be much more work for your PHP to encode and your JS to decode.
Anyhow, for the common case of small numbers, text representations tend to be very efficient. Your example 1.2345 is actually smaller as a string (6 bytes) than a double-precision float (8 bytes).
JSON was invented precisely to allow non-string types to be transferred over the HTTP connection. It's as seamless as you're going to get. Is there any good reason to care that there was a serialise->string->parse step between the PHP float and the JavaScript Number?
(* exposed to JavaScript as a character protocol, since JS has no byte datatype. By setting the charset of the JSON response to iso-8859-1 you can make it work as if it were pure bytes, but the default utf-8 is usually more suitable.)
If you didn't want to use JSON, there are other encoding options. The data returned from an HTTP request is an octect stream (and not 7-bit clean ASCII stream -- if it were, there would be no way to server UTF-8 encoded documents or binary files, as simple counter examples).
Some binary serialization/data protocols are ASN.1, Thrift, Google Protocol Buffers, Avro, or, of course, some custom format. The advantage of JSON is "unified human-readable simplicity".
But in the end -- JSON is JSON.
Perhaps of interest to someone: JavaScript Protocol Buffer Implementation