[hashcash] Re: new format tweak coming...

How about we assume the simplification that '" are not special, and
are considered part of the string as any other alpha-num.  :;,= are
special and must be quoted with \.

I think the following should do it, don't have time to test write now.

It's not one regexp, perhaps more advanced use of regexps can split
this in one go by splitting on [^\\]: etc

#!/usr/bin/perl
$_ = shift;
$_ =~ s/\\(.)/asc(ord(\1)+128)/ge;
($ver,$date,$stamp,$ext,$rand) = split(":",$_);
@names = split(';',$ext);
foreach (@names) {
    ($name,@values) = split(/[=,$]/,$_);
    print "$name = ";
    $first = 1;
    foreach (@values) {
        $_ =~ s/([\200-\377])/asc(ord(\1)-128)/ge;
        if ( !$first ) { print ","; }
        print "[$_]";
    }
    print "\n";
}

The idea being to first of all recognize and move out of the way all
of the \ quoted stuff, then do the simple : split, then the
assignment1;assignment2 split then the name=val,val split within each
asignment, then put back the chars that were \ quoted.

(Where move out of the way is to transpose outside of 7-bit clean
space).

Another encoding as is being discussed is url-encode.  For example:

ver:date:resource:[ext]:rand

where ext is:

name3;name1=val1;name2=val2,val3

so no quotes needed (either " or '), reserved are :;=, and so we use
restricted url-encoding where only those are urlencoded.  Probably
allow also space to be urlencoded, and urlencode + because some
urlencoders use + in place of space and of course % is also encoded
because it's the urlencode escape char.

But do full url-decoding (in case anyone does use other chars).

The restricted urlencoding results in generally "pretty" and readable
strings, where you'll only make a mess when there is a : in the name
or value string.

More comments inline:

On Sun, Mar 14, 2004 at 04:16:40PM -0500, Hubert Chan wrote:
> Ben> Doesn't work, either. You also haven't dealt with : inside the "s.
> 
> How are : inside the "s supposed to be parsed?  I don't see anything
> wrong with my regexp.  As far as I can tell, a : inside "s should be
> treated  just normal characters.

yes but the outer level parsing needs to split
ver:date:resource:ext:rand using the :s and if there are unquoted :s
it can't do that.

> Ben> Alternatively, produce a _tested_ regex that parses the whole
> Ben> format, not a subset.
> 
> Speaking of being regexp friendly, though, I would recommend that for
> the resource field, we either disallow colons, or force them to be
> escaped (or URL encoded).

We should use the same mechanism.  I think \ quoted : would be enough.

Adam

Other related posts: