use URI::Escape;
     $safe = uri_escape("10% is enough\n");
[download]

     $str  = uri_unescape($safe);
[download]

Thank you. And is there the function to convert '10' into 'a'? Contrary to hex().

Nuance

The only way to use pack to convert between number bases would be to pack the number and then unpack it using different formats. But pack doesn't have a format for octal, so it still wouldn't work for this case.

A better approach is just to use oct to convert the octal string into an integer and then use sprintf to convert the integer into a hex string:

    $oct= "0765";
    $hex= sprintf "0x%X",oct($oct);
[download]

Also note that $oct= 0765 sets $oct to an integer so that print "$oct\n" will print "501", since printing an integer defaults to using decimal notation.

But on to my main point about computing via doubles...

Perl uses C doubles for (nearly) all numeric computations because it is a good idea. Enough said? No?

Okay, Perl's primary data type is a scalar which you can think of as simultaneously having string, two's compliment (or unsigned), and double-precision floating point values where changing any one changes all of the others. Actually, each scalar simultaneously has zero or more of these and changing one invalidates all of the others until such time as the other type of value is needed. When a scalar is used in a context requiring a value type that the scalar doesn't currently have, that type of value is computed from one of the values that the scalar already has (and now the scalar has one more type of value cached inside of it). Some of these conversions can give warnings.

All of this should give you fits if you want a strongly typed language. But you can't throw a CS textbook without hitting a stongly typed language and that is a discussion for another thread.

So, all of the string operators operate on strings. All of the bit-wise logical operators operate on (signed or unsigned) "long int"s (though a few can also operate on strings if the conditions are right). All of the arithmatic operators (and "math" functions) use double-precision floating point. So your question probably boils down to: "Why doesn't doing arithmatic on integers just use C integral data types instead of double?"

So, let's go the other direction first. Why should it (use longs)?

1. It would be faster.
2. Floating point arithmatic isn't precise.
3. I could have sworn there were other reasons but now I can't think of any more.

Well, as for #1, this used to be very true for a lot of common processors. Now days it is only slightly true for most processors and on some processors floating point arithmatic is actually faster than integer arithmatic because such processors have excellent floating-point acceleration hardware but little integer arithmatic acceleration hardware. Anyway, the speed gained is usually small enough that the other advantages really out weigh it.

If you want to experiement with the speed difference, you can use integer around bits of code and all aritmatic will be done using longs, even if the original numbers were not integers.

Now, if we changed Perl to be able to do integer arithmatic when it "made sense", then most arithmatic operators would have to do calculations to figure out whether to work on integers or doubles. This would slightly slow down all arithmatic, perhaps enough that it would be a net loss of performance in many situations.

Okay, on to #2. #2 is completely wrong. Well, floating point arithmatic is not infinitely precise, but it is more precise than integer arithmatic. If you do arithmatic that involves no fractions, then using doubles will give you exact and correct answer even more often than using longs will. This is because a double is usually twice as big as a long and allocates more bits for mantissa than can fit in a long.

In other words, a double is better at holding integers than long or unsigned long. In fact, Perl's own int function will return a double value if it needs to:

    $a= 0xffffffff;     print $a,"\n";
    $a += 1;            print $a,"\n";
    $a += 1;            print $a,"\n";
    $a += 1;            print $a,"\n";
    $a += 1;            print "\t\t",$a,"\n";
    print "non-fract:\t", int($a), "\n";
    printf "unsigned long:\t%u\n", $a;
    print "unsigned long:\t", $a|0, "\n";
[download]

produces

4294967295
4294967296
4294967297
4294967298
                4294967299
non-fract:      4294967299 # correct
unsigned long:  4294967295 # incorrect
unsigned long:  4294967295 # incorrect
[download]

I wrote a very simple Perl function to find the prime factors of an integer. To test the speed improvement gained by use integer, I timed several test runs with and without that added. I quickly found cases where use integer made things much, much faster. But those cases all turned out to be because I was using integers too big to fit in an unsigned long. But those same integers were handled perfectly by Perl with its automatic use of doubles.

So if you give Perl an integer too big to fit exactly into a double, then it, like using doubles in C, will (usually silently) approximate it with a (relatively) nearby integer. If you force Perl to use long, then much smaller integers are too big and they get (usually silently) replaced with integers that are not nearby.

So be glad that Perl uses doubles!