1

Here is an overview of what 8 bit clean means.

In the context of web applications, why are images saved as Base64? There is a 33% overhead associated with being 8 bit clean.

If the transmission method is safe there is no need for this.

But basically, my images are saved in Base64 on the server, and transferred to the client, which as we all know can read Base64.

Here is the client side version of Base 64 in an SO Post.

How can you encode a string to Base64 in JavaScript?

Is http/https 8 bit clean?

Reference

http://www.princeton.edu/~achaney/tmve/wiki100k/docs/8-bit_clean.html

http://en.wikipedia.org/wiki/8-bit_clean

Community
  • 1
  • 1
employee-0
  • 1,023
  • 1
  • 9
  • 19
  • Is HTTP 8-bit clean? [A fairly authoritative answer](http://stackoverflow.com/questions/2418982/why-do-we-need-to-base64-encode-images-before-transmitting#comment2402286_2419019) from [Julian Reschke](http://www.arkko.com/tools/allstats/julianf.reschke.html) – Hawkeye Parker Nov 14 '14 at 11:03

4 Answers4

8

You are asking two different things.

  1. Q: Is http 8 bit clean?

    A: yes HTTP is "bit 8 clean".

  2. Q: In the context of web applications, why are images saved as Base64?

    A: images are not usually saved in Base64. In fact, they are almost never. They are usually saved or transmitted or streamed in compressed binary format (PNG or JPG or similar)

    Base64 is used to embed images inside the HTML.

So, you got an image logo.png. You include it statically in your page as <img src='logo.png'>. The image is transmitted thru HTTP in binary, no encoding in neither browser nor server side. This is the most common case.

Alternatively, you might decide to embed the contents of the image inside the HTML. It has some advantages: The browser will not need to do a second trip to the server to fetch the image, because the browser has already received it in the same HTTP GET response of the HTML file. But some disadvantages, because HTML files are text and certain character values may have special meaning for HTML (not for HTTP), you cannot just embed the binary values inside the HTML text. You have to encode them to avoid such collisions. The most usual encoding method is base64, which avoids all the collisions with only a 33% of overhead.

PA.
  • 28,486
  • 9
  • 71
  • 95
  • you want to use base64 encoding (or hex -base16- or base32 encoding or ascii85 encodin or any other encoding) when you want to **embed** the image in the HTML text. Possibly to avoid a second roundtrip to the server, or to overcome technical limitations in your web application server. – PA. Sep 17 '13 at 13:59
  • If HTTP is "bit 8 clean", how is binary data transmitted? – user2864740 Dec 01 '13 at 05:40
  • 1
    that's exactly what clean means in this context, that you can transfer binary data by just using the http protocol to transmit the data stream without any special coding. – PA. Dec 02 '13 at 11:52
  • @PA. - Do you mean to say that HTTP is 8-bit clean since no encoding is required? If yes, what does it mean by `This is only 7-bits, not 8 as the last 128 characters would be depending on set encoding (Latin1, UTF8 etc.) which means that the encoded data could be mangled if a different encoding type was set at client/receiver end compared to source.`? – Motivated Jan 26 '19 at 16:55
  • HTTP **is** bit8 clean. But transmitting and receiving text over HTTP needs an agreement on encoding. – PA. Jan 27 '19 at 15:30
  • @PA. - Do you mean to say that the last bit determines the type of encoding? If yes, does it mean that if a client requests for a resource with an encoding format other than that recognized by the server, it may received a mangled response? – Motivated Feb 03 '19 at 05:49
  • No, I don't mean that. The last bit does not determine the encoding. The encoding can tacitaly or implicitely agreed. For example, a server can send a HTTP `Content-type charset` header; or the HTML document can include a `` tag. – PA. Feb 03 '19 at 17:44
3

RFC 2616s abstract states:

A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.

HTTP always starts with a text-only header and in this header the content-type is specified. As long as sender and receiver agree on this contents type anything is possible.

HTTP relies on a reliable (recognize the wordplay) transport layer such as TCP. HTTPS only adds security to the transport layer (or between the transport layer and HTTP, not sure about this).

So yep, http(s) is 8 bit clean.

In addition to PAs answer and your question "But why use an encoding method that adds 33% overhead, when you don't need it?": because that's part of a different concept!

HTTP transfers data of any kind, and the http-content may be an html file with an embedded picture. But after receiving that html file a browser or some other renderer has to interpret the html content. And that follows different standards, which require arbitrary data to be encoded. html is not 8-bit clean, in fact it is not even 7-bit clean as there are many restrictions on the characters used and their order of appearance.

Community
  • 1
  • 1
Matthias Bäßler
  • 480
  • 1
  • 5
  • 11
  • +1, BUT ... It's not a different concept Base64 is used b.c. it supports 8 bit UNCLEAN systems ... hence it is a relic of the past when used in web. – employee-0 Sep 25 '13 at 12:53
2

In the context of web applications, why are images saved as Base64? There is a 33% overhead associated with being 8 bit clean.

Base64 is used to allow 8-bit binary data to be presented as printable text within the ASCII definition. This is only 7-bits, not 8 as the last 128 characters would be depending on set encoding (Latin1, UTF8 etc.) which means that the encoded data could be mangled if a different encoding type was set at client/receiver end compared to source.

As there aren't enough printable characters within ASCII to represent all 8-bit values (which has absolute values and aren't dependent on encoding itself) you need to "water out the bits" and base-64 keeps high enough numbers to enable the bytes to be represented as printable chars.

This is the 33% overhead you see as the byte values representing characters outside the printable range must be shifted to a value that becomes printable within the ASCII table; Base-64 allows this (you could also use quoted printable which was common in the past, ie. with Usenet, email etc.).

I'm thinking about writing another encoding type to remove the overhead.

Good luck :-)

0

Related to the query

  • Is HTTP 8-bit clean ?

HTTP protocol is not in entirety a 8-bit clean protocol.

HTTP Entity Body is 8-bit clean since there is a provision to suggest the content-type, allowing content-negotiation between the interacting entities as pointed by everyone in this thread.

However the request line , the headers and the status line are not 8-bit clean.

In order to send any binary information as part of

  • the request line, as part of query parameters / path segments

  • header

one must use one of the binary-to-text encoding to preserve the binary values.

For instance when sending a signature as part of query parameters or headers , which is the case of signed URL technique employed by CDN , the signature a binary information has to be encoded to preserve the binary value of it.

Chandu
  • 4,581
  • 2
  • 17
  • 13
  • 1
    I believe all of HTTP is [8-bit clean](http://en.wikipedia.org/wiki/8-bit_clean). The entire HTTP protocol is spec'd as using and transmitting _octets_: "[A recipient MUST parse an HTTP message as a sequence of octets....](http://tools.ietf.org/html/rfc7230#section-3)". Headers are [historically spec'd as ISO-8859-1](http://tools.ietf.org/html/rfc7230#section-3.2.4), which is an 8-bit encoding. We use binary-to-text encodings (e.g., Base64) to encode non-ascii start line/header binary data, because this ensures that the data conforms to the HTTP spec, **not** because HTTP isn't 8-bit clean. – Hawkeye Parker Nov 17 '14 at 00:21