Nem teljesen értek veled egyet, bár a különbség tényleg csak a teljesítmény szempontjából számít, ott viszont igencsak, ugyanis _minden_ stringen végzett művelet lépésigényét O(n)-nel szorozza, ha a belső ábrázolás utf8-as, ami mondjuk egy webes alkalmazásnál sem mindegy.
Bár alapvetően inkább perl-párti vagyok, ahogy elsőre utánanéztem, a php-nél is gondoltak erre, és állíthatóvá tették a belső ábrázolást a php.ini 'mbstring.internal_encoding' sorával.
Ha ez tényleg azt csinálja, amit gondolok, akkor az általad javasolt 'mb_.*' tényleg helyes, és még gyors is tud lenni :).
Viszont most, hogy felvetődött, megnéztem a perl viselkedését (mert szégyenszemre a belső ábrázolását eddig nem figyeltem), és ahogy látom, biza utf8! Működik éppen rá minden szépen:
fules@chaos:/tmp$ echo "árvíztűrő tükörfúrógép" | hexcat
00000000 - c3 a1 72 76 c3 ad 7a 74 c5 b1 72 c5 91 20 74 c3 ..rv..zt..r.. t.
00000010 - bc 6b c3 b6 72 66 c3 ba 72 c3 b3 67 c3 a9 70 0a .k..rf..r..g..p.
fules@chaos:/tmp$ echo "árvíztűrő tükörfúrógép" | perl -ni -e 'use encoding "utf8"; print substr($_, 5, 10)."\n";'
tűrő tükör
De belül utf8-at használ az ebadta :(. (Lehet, hogy valahogy rá lehet beszélni értelmesebbre, de ennek utána kell néznem.)
fules@chaos:/tmp$ perl -e 'print "nesze: árvíztűrő tükörfúrógép\n"; kill 6,$$;'
nesze: árvíztűrő tükörfúrógép
Aborted (core dumped)
fules@chaos:/tmp$ hexcat core | grep nesze
00000500 - 70 72 69 6e 74 20 22 6e 65 73 7a 65 3a 20 c3 a1 print "nesze: ..
000240d0 - 6e 65 73 7a 65 3a 20 c3 a1 72 76 c3 ad 7a 74 c5 nesze: ..rv..zt.
00024470 - 6e 65 73 7a 65 3a 20 c3 a1 72 76 c3 ad 7a 74 c5 nesze: ..rv..zt.
Szerk.: UTF8, pont. Na most vagy kerítek egy ideológiát az utf köré, vagy elismerem, hogy itt a perl lesz a lassabb. Tényekkel ne vitatkozzunk, maradok az utóbbinál :).