1

I have a form which is submitted via mailto to a email server.

As you most know, there is a limitation to the mailto content over which it won't work because it exceeds URL characters limit.

I developed some custom data compression that are domain specific, but it is still not enough (In case all fields are filled, it will bust the limit, this is rare... but rare is bad enough for the client. Never is better.).

I found the Lempel–Ziv–Welch algorithm (http://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Welch) and concluded it would allow me to save 40% of the length average.

Unfortunately, I need of course to call encodeURIComponent to send it to mailto, and as LSW algorightm will return many URL unsupported characters this will in fact make it worse once URL encoded.

Before you tell me it would be easier to make a post to a server using server-side language, let me tell you this is a really unique situation where the form has to be submitted via email via a client-side application, because emails are the only way to connect with the outside world for the end users...

So, do you know any way to compress data efficiently without encodeURIComponent ruining it all ?

Or is there a way to send content to mailto without going through browser ?

I've seen some ways to open Outlook with ActiveX and stuff, but this is pretty browser/email client specific.

Also I checked for options where I save form info in a file using javascript... but the application users are, well let's just say they are not experts at all, and from what I've been told, they could fail to attach the email. (yes, they are that bad)

So I look for the simplest option, where user involvment is almost 0 and where the result is an email sent with the form data, all of that without server-side languages, with a compression algorithm if applicable.

Thanks a lot for your help !

Icefire
  • 163
  • 1
  • 10

1 Answers1

1

You'll have a hard time getting to "never" with compression, since there will always be strings that a compressor expands instead of compresses. (Basic mathematical property of compression.)

Having said that, there are much better compressors than LZW, depending on the length of your input. You should try zlib and lzma. The binary output of those would then need to be coded using only the allowed URL characters.

Mark Adler
  • 101,978
  • 13
  • 118
  • 158
  • Thanks for your answer Mark. Indeed LZW can get the data to be bigger than original. The links are interesting but may not be applyable in javascript for the encoding unless I miss something, I'll take a look soon enough to see what I can do with that. I'll look for equivalent libraries in javascript. – Icefire Nov 05 '13 at 21:33
  • I found an implementation of LZMA, but I'm not sure I understand to be frank. This returns an array of numbers. Of course this array is way longer than the original string, so am I supposed to do with this array ? At first I thought this was an array of char codes of the new String, but this is obviously not the case since there are negative numbers... Any hint Mark ? – Icefire Nov 11 '13 at 04:18
  • Obviously I understand in term of bytes this save content, but this is not my intent. I want to save characters to be sent to the email client... I guess I should search strictly for algorithms for which the result is a string. – Icefire Nov 11 '13 at 04:35
  • My question seems similar to http://stackoverflow.com/questions/7498544/string-to-string-compression-algorithm . Will continue my research... – Icefire Nov 11 '13 at 04:48
  • All compressors will produce binary data. You will need to use something like base64 to convert the binary to readable characters, which will expand the data. See [binary to text encoding schemes](http://en.wikipedia.org/wiki/Binary-to-text_encoding). – Mark Adler Nov 11 '13 at 06:06
  • You can also take a look at [smaz](https://github.com/antirez/smaz) for small string compression. – Mark Adler Nov 11 '13 at 06:07