これだとLiberalなUTF-8ですね。

[を] UTF-8 の文字にマッチする正規表現
UTF-8の文字にマッチする正規表現の素直版。

新旧、というのか、LiberalなUTF-8とStrictなUTF-8の違いは、RFC2044RFC2279を見ればはっきりします。要はU+11000より上を認めるかどうかということです。今のところUnicode.orgの定義では、U+0000 - U+10FFFF しか認めていないので、そちらの定義に従うと、むしろこの正規表現はさらに短く

$RE_UTF8CHAR_STRICT
 = qr/(?:[\x00-\x7f]|[\xC0-\xDF][\x80-\xBF]|[\xE0-\xEF][\x80-\xBF]{2}|[\xF0-\xF7][\x80-\xBF]{3})/;
ないし
$RE_UTF8CHAR_STRICT = 
  qr{(?: [\x00-\x7f]                # 1 byte
       | [\xC0-\xDF][\x80-\xBF]     # 2 bytes
       | [\xE0-\xEF][\x80-\xBF]{2}  # 3 bytes
       | [\xF0-\xF7][\x80-\xBF]{3}  # 4 bytes
    )}x;

と書けます。

012345offset
10xxxxxxx
2110xxxxx10xxxxxx
31110xxxx10xxxxxx10xxxxxx
411110xxx10xxxxxx10xxxxxx10xxxxxx
5111110xx10xxxxxx10xxxxxx10xxxxxx10xxxxxx
61111110x10xxxxxx10xxxxxx10xxxxxx10xxxxxx10xxxxxx
bytes/char

ただし、これも実は厳密ではなくて、これだとSurrogate Pairの領域(U+D800 - U+DFFF)も入ってしまいますが、まあ普通そこまでやらんでもいいでしょう。

Dan the Man with Too Many Encodings to Support

追記: 成瀬さんからTBが。

はてなるせだいあり - [Char]UTF-8の正規表現
もっと厳密にしますと

これはすごい。となると、

ここからさらにU+FFFEやU+FFFFが無い、というのも考慮するとうれしい日もあるかもしれません。いや、無いかな。

というのにも対応した奴が欲しくなりますよねえ。というわけで以下に。

$RE_UTF8CHAR_VALID = 
  qr{(?:  [\x00-\x7F]                   #   U+0000 - U+007F
        | [\xC2-\xDF][\x80-\xBF]        #   U+0080 - U+07FF
        | \xE0[\xA0-\xBF][\x80-\xBF]    #   U+0800 - U+0FFF
        | [\xE1-\xEC][\x80-\xBF]{2}     #   U+1000 - U+CFFF
        | \xED[\x80-\x9F][\x80-\xBF]    #   U+D000 - U+D7FF
        | \xEF[\x80-\xBF][\x80-\xBD]    #   U+E000 - U+FFFD
        | \xF0[\x90-\xBF][\x80-\xBF]{2} #  U+10000 - U+3FFFF
        | [\xF1-\xF3][\x80-\xBF]{3}     #  U+40000 - U+FFFFF
        | \xF4[\x80-\x8F][\x80-\xBF]{2}	# U+100000 - U+10FFFF
      )}x;

ちなみに、Encode.pmのutf-8-strictでは、このレベルのチェックまでやってます。

self memo : 2006-03-11
RFCとにらめっこしなかった自分が恥ずかしい。

さすがに$RE_UTF8CHAR_MAPPED{4.1}とかいうのはご勘弁を;-)