Another possibility is to do just a single substitution, and keep track of what was matched.

#!/usr/bin/perl -w
use strict;
use warnings;


my %subs = (
    farenheit => sub { 
        warn "Matched F with $^N\n";
        return sprintf("%.u" , ($^N - 32) / 1.8) . 'C'
    },
    celsius   =>  sub {
        warn "Matched C with $^N\n";
        return sprintf("%.u" , ($^N * 1.8) + 32) . 'F'
    },
);

my $WHAT;

my $regex = qr/
      (\d+)F (?{ $WHAT = 'farenheit' })
    | (\d+)C (?{ $WHAT = 'celsius'   })
/xi;

my $html = do { local $/; <DATA> };

$html =~ s/$regex/$subs{$WHAT}->()/eg;

warn $html;

__DATA__
convert 180F to C
convert 180C to F
[download]

Note that this uses a feature that's marked as EXPERIMENTAL in perlre, so be warned.

Also since there are now multiple captures in the same regex, $^N is more robust than using $1, $2 etc.

foreach my $key (keys %subs)
{
  warn "checking key: $key\n";
  if ($html =~ s/$key/$subs{$key}->()/eg) {
    warn $html;
    last;
  }
}
[download]

So that you leave the loop once you've made a substitution.

Just a minor observation regarding your use of sprintf and concatenation. You can dispense with the concatenation entirely by just including the concatenated text in the format string. E.g. replace

return sprintf("%.u" , ($1 - 32) / 1.8) . 'C'
[download]

with

return sprintf q{%.uC}, ( $1 - 32 ) / 1.8
[download]

Also, I'm not sure what you intend with the "%.u" format specifier, which will truncate your result. Perhaps something like "%.1f" would be more useful?

$ perl -E 'say sprintf q{%.uC}, ( 75 - 32 ) / 1.8;'
23C
$ perl -E 'say sprintf q{%fC}, ( 75 - 32 ) / 1.8;'
23.888889C
$ perl -E 'say sprintf q{%.1fC}, ( 75 - 32 ) / 1.8;'
23.9C
$
[download]

I hope this is helpful.

You're iterating over all the keys, and you're not happy that the subs associated with all of them get called. The simple solution here is to not iterate over all the keys.

You are finding it not very useful to convert units and convert them back. I'm wondering why it would be useful to convert in whichever direction in the first place instead of ending up with all metric or all Imperial. Maybe appending the conversion to the existing version would be handy, but going from a randomly mixed bag of units to having exactly the opposite measurements in the wrong units doesn't seem to be.

Perhaps you should have a metric-to-Imperial hash and an Imperial-to-metric hash, and tell the program from the command line or such which units you want to have in the end. That way you'd only convert in one direction, and only the measurements that started in the wrong units.

i think mischief is onto something. when you find yourself going slightly loopy in complex code, it's often an indication to refactor design. as a lot of time it's not super ingenious code that "wins"; simpler code with a simple interface is often more flexible in the long run.
processing the input to produce a internal representation in ISO units or other consistent units, allows good flexibility.
if you're interested following that path, have a look (and infer the logic) on unit conversion apps such as those for iphone.
the hardest line to type correctly is: stty erase ^H