** Using WeBWorK **

sub decodeAnswers($) {
 my $serialized = shift;
 return unless defined $serialized and $serialized;
 my $array_ref = eval{ Storable::thaw(decode_utf8_base64($serialized)) };

 if ($@ or !defined $array_ref) {
 # My hope is that this next warning is no longer needed since there are few legacy base64 days and the fix seems transparent.
 # warn "problem fetching answers -- possibly left over from base64 days. Not to worry -- press preview or submit and this will go away permanently for this question. $@";
 return ();
 } else {
 return @{$array_ref};
 }
}

and

sub encodeAnswers(\%\@) {
 my %hash = %{shift()};
 my @order = @{shift()};
 my @ordered_hash = ();
 foreach my $key (@order) {
 push @ordered_hash, $key, $hash{$key};
 }
 return encode_utf8_base64( Storable::nfreeze( \@ordered_hash)) ;

}

If I entered the string

0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789

before the change I would get a database error. After the change

webwork simply reports correctly that my answer is incorrect. I haven't thought how to make this backwards compatible yet. It might be easier to implement than switching to JSON but there may be other reasons to switch to JSON. In any case it seems to confirm that the basic source of this bug is the freeze/thaw operation.