Lossless compression method to shorten string before base64 encoding to make it shorter?

Question

just built a small webapp for previewing HTML-documents that generates URL:s containing the HTML (and all inline CSS and Javascript) in base64 encoded data. Problem is, the URL:s quickly get kinda long. What is the "de facto" standard way (preferably by Javascript) to compress the string first without data loss?

PS; I read about Huffman and Lempel-Ziv in school some time ago, and I remember really enjoying LZW :)

EDIT:

Solution found; seems like rawStr => utf8Str => lzwStr => base64Str is the way to go. I'm further working on implementing huffman compression between utf8 and lzw. Problem so far is that too many chars become very long when encoded to base64.

Tarpon

Answer 1

Check out this answer. It mentions functions for LZW compression/decompression (via http://jsolait.net/, specifically http://jsolait.net/browser/trunk/jsolait/lib/codecs.js).

Neurocoele

You sir have almost saved my day! Great library, although the base64 encoder wasn't to keen on encoding the lzw encoded string. – Tarpon

I found an extended base64 encoder/decoder that works: webtoolkit.info/javascript-base64.html. In combination with the lzw-en-/decoder you linked to it all works. Thanks for your help! – Tarpon

Page not found - womp womp – Monacid

Answer 2

You will struggle to get very much compression at all on a URL, they're too short and don't contain enough redundant information to get much benefit from Huffman / LZW style algorithms.

If you have constraints on the space of possible URLS (e.g. all content tends to be in the same set of folders) you could hard code some parts of the URLS for expansion on the client - i.e. cheat.

Foeticide

The HTML code to compress will be several thousand chars and contain alot of similiar chars. I believe/hope compression will make a significant difference. – Tarpon

Ah Ok - so they really are kinda long! One other consideration - if you ensure GZIP compression is on for the HTML docs (i.e. via IIS) then you're getting compression anyway for the entire HTML document. In that case is compressing the URL before you encode and put them in the HTML redundant? Letting the browser do the decompression in code rather than you doing it in JS may be substantially quicker. – Foeticide

Sorry I'm not fully following you yet. I just read about GZIP and it seems like a better choice than just LZW. Is there some native support for GZIP en-/decoding in browsers? Would a GZIP:ed string be safe to put straight into an URL? – Tarpon

You can turn on GZIP compression on IIS. See microsoft.com/technet/prodtechnol/windowsserver2003/library/iis/…. Then any HTML pages are GZIP'ed (or DEFLATE'ed) before they are sent to the browser if the browser supports it. The browser will uncompress when it receives the HTML. This may make your GZIP of a small section of the page redundant - and possibly detrimental to the size/speed of the page. – Foeticide