Encoded URL

First, define two routines that can do the grunt work of crushing and uncrushing your parameters, which for the sake of argument are being stored in a HASH: 
use MIME::Base64;

sub Crush
{
        return shift(@_).MIME::Base64::encode (join ("\x00", @_), "");
}

sub Uncrush
{
        my ($q) = shift;
        return split (/\x00/, MIME::Base64::decode($q->path_info()));
}

[download]
This is, of course, assuming you don't have any NULL (ASCII 0) characters in your data. If you do, this code will break, but it will work fine on normal ASCII text. Additionally, it uses "path_info()" from CGI.pm, which you should be using anyway.

You could tie them into your program like so: 
my (%data) = ( 'x' => 'y' );  # etc.

$url = Crush ("http://www.xyzco.com/foo.cgi?",%data);

# Or, on the receiving end...

my ($q) = new CGI;

my (%data) = Uncrush ($q);

[download]
It all ends up as a great big pile of goo as far as the user is concerned, but it isn't encrypted to any great degree. If you wanted, you could MD5 encrypt it, PGP it, or whatever strikes your fancy, before MIME::Base64::encode(), with the opposite on the receiving end, of couse.

Server Side Data

An intelligent alternative to this "encoding" is to keep the data on the server. As you mentioned, long URLs are a problem for some e-mail programs, and certainly more users. To keep the URL to an absolute minimum, you could store all of the data in a database on the server side and pass only a key to the client.

Basically, your URL would contain a text key like "AxZLkFlG" which is a randomly created string that the server would use to identify that session. You could then store all of your data server side.

The downside to this approach is that the data has to be preserved for extended periods of time, because if the server data is "expired", the URL becomes virtually useless. If you expect the users to re-visit six or eight months from now, that would translate to a six or eight month history of data, which can get quite large, depending on your application.

Additionally, if a user sends a copy of the URL to five friends, they will all be modifying the same database entry, which can lead to some unsavory variable "bleed" between their sessions. This can be very dangerous, especially for e-commerce applications.

If you have no idea when the user is going to re-visit, and you want to preserve the state of the program indefinitely, you have to pack all the data into the URL. Base64 expands the content moderately, so the URLs will always be longer using this method, but this can be minimized if you compress it before encoding (i.e. LZW encoding, like that used in gzip).

In reply to Re: Encoding/compress CGI GET parameters by tadman
in thread Encoding/compress CGI GET parameters by snellm

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.