- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
sub hex_to_string
{
my ($res, $str, $i) = ("", shift, 0);
$str =~ tr/A-Z/a-z/;
while ($i < length($str))
{
my $m = ord(substr($str, $i++, 1));
my $n = ord(substr($str, $i++, 1));
if ($m >= 48 && $m <= 57)
{
$m -= 48;
}
if ($m >= 97 && $m <= 102)
{
$m = 10 + $m - 97;
}
if ($n >= 48 && $n <= 57)
{
$n -= 48;
}
if ($n >= 97 && $n <= 102)
{
$n = 10 + $n - 97;
}
$res .= chr($m * 16 + $n);
}
$res = join("\n", split(/\r\n/, $res));
return $res;
}
Печально, что силу регулярок недооценивают.
sub hex_to_string($)
{
my $input_hex_data = shift;
my $result = $input_hex_data;
$result =~ s/([a-fA-F0-9][a-fA-F0-9])/chr(hex($1))/eg;
return $result;
}
Follow us!
вдобавок простые регулярные выражения перл заменяет на обычные строчные операции. поэтому извращатся со строчными операциями в перле не имеет смысла - регулярками и проще и так же эффктивно.
на 5.14 код приведеный свыше можно переписать так:
хотя все равно говно потому что даже и функцию для этого заводить не надо потому что совсем правильно это делается так:
Может быть наоборот, обычно извращаются с регулярками?
"человеческий" синтаксис означал бы тот факт, что парсер был бы сложный и медленный.
Конечно, вы сами можете придумать таковой и написать парсер или конвертор, но, боюсь, попытка эта подобна 1С
Удобно, парсируемо, читабельно, по скорости рвёт регулярки в клочья.
ПыСы: но, увы, почти никому не известно...
Тоже самое и с английскими вставками в русский язык. Просто легче выразить, но не знающий их изливает горы непонимания.
> набираешся
просто неудачный пост
сначала надо осилить связность предложений
Но упрощения могут привести еще больше непонимания.
Просто всё упирается в непонимание .i.
причём с завидной регулярностью