Старая знакомая ситуация: есть что-то, какой-то сервис, отдающий массивы PHP в формате функции var_export(), либо исторически сложилось так что что-то в системе отдает оформленные в код PHP массивы.

Например, ваш скрипт получает строки вида:

$test = "array('gmt' => 'Europe/Moscow',
'sudia3' => '',
'sudia1' => '',
'sudia2' => '',
'pos1' => '4-2-3-1',
'color1' => '#f00',
'pos2' => '4-4-1-1',
'color2' => '#000',
);";

Да, вы не ошиблись, бывает код PHP приходящий в строке. Один из вариантов разбора - eval(). Однако на разнородной системе это и дыра в безопасности.

При этом грамотным решением будет serialize() массива на той стороне, и unserialize() на вашей, или JSON. Однако, предположим, что в вашем проекте исторически сложилось так, что на "той" стороне это исправить на данный момент нельзя. А массив хочется "разобрать" безопасно.

В такой ситуации поможет ставшее стандартным(с PHP 4.2.0) расширение Tokenizer и его функция token_get_all().

Пример простенького разбора массива с ее помощью(пусть он у нас одномерный):

$test = array(
  "'gmt' => 'Europe/Moscow',
  'sudia3' => '',
  'sudia1' => '',
  'sudia2' => '',
  'pos1' => '4-2-3-1',
  'color1' => '#f00',
  'pos2' => '4-4-1-1',
  'color2' => '#000',
);";

$t = token_get_all($test);
$label = array();
foreach( $t as $k => $token) {
  if(!is_array($token) ) {
    unset($t[$k] );
  } else {
    list($id, $val) = $token;
    if ( ($id == T_WHITESPACE) || ($id == T_VARIABLE) || ($id ==
T_BAD_CHARACTER) || ($id == T_OPEN_TAG) || ($id == T_ARRAY) || ($id == T_DOUBLE_ARROW) ) {
      unset($t[$k] );
    }
    else {
   }
  }
}
$c = count($t);
if ($c % 2 == 0) {
  $arr = array();
  $k = array_keys($t);
  $cc = $c /2;
  for ($i = 0; $i < $cc; $i ++) {
    $key = trim($t[$k[2*$i] ] [1], '\'"');
    $val = trim($t[$k[2*$i + 1] ] [1], '\'"');
    $arr[$key] = $val;
  }
  // а вот и наш исходный массив
  var_dump($arr);
} else {
  echo "Parse error\n";
}

Длиннее чем eval()? Да! За код будет спокойнее чем за eval()? Однозначно - да.

2 марта тихо и незаметно выпустили PHP 5.4.0, Новый релиз PHP.

Основные вещи которые нас затронут, и которые надо учитывать при настройке серверного ПО в том числе:

• error_reporting - E_ALL теперь будет включать бит E_STRICT:
• интерпретатор в интерктивном режиме теперь не "вываливается", если ему скормить некорректный код;
• кодировка по умолчнию UTF-8;
• register_globals RIP. (что в прочем не помешает идиотам их эмулировать);
• из классов - наверно самое интересное - добавлен Transliterator для транслитерации строк;
• временные зоны - PHP не будет пытаться угадать текущую временную зону для расширения DateTIme. Надо пользовать date_timezone_set
• ООП - добавлено понятие trait(несколько напоминает модули в Ruby).

Изменений не очень много, но большая вероятность того что старые скрипты, модули и пр. перестанут в 5.4 работать, довольно велика.

Полноценную поддержку Unicode в строках так и не сделали. :(

Данная ситуация довольно редкая, однако все же встречается. Есть некая переменная, для которой надо посмотреть ее структуру. 

Мы начинаем делать

var_dump($fields);

и садимся в лужу, видя сообщение в логе сервера:

[Thu Feb 23 16:21:07 2012] [error] [client 127.0.0.1] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 78045652 bytes) in /web/site1/includes/theme.inc on line 1080, referer: http://localhost/site1/

Что же произошло. В $fields где-то в глубине обнаружился указатель на объект который уже есть в fields и описан выше. И var_dump начинает рекурсивно "бегать" по структуре объекта, пока не сожрет всю память.

Получается, мы не можем посмотреть "что там внутри", без описания оберток. В drupal есть модуль devel, который использует библиотеку krumo, но в тех версиях, которые я видел - тоже нет лимитов глубины прохода.

Проблема решается установкой xdebug и использованием функции xdebug_var_dump(). У этого модуля можно задать глубину показа "внутренностей" в переменной xdebug.var_display_max_depth и указать количество объектов на конкретном уровне, которые можно показывать переменной xdebug.var_display_max_children.

Таким образом, можно не городить свои обертки для дампов. 

PS. Пишу это в качестве напоминания для себя.

PPS. Удивительно, до сих пор в PHP не предусмотрели штатно уровни вложенности в функции var_dump.

Не считаю, что тестирование в принципе может что-то показать о знаниях, тем не менее:

Можно немного размять мозги. :)

Пройти тестирование.

http://lenta.ru/articles/2011/12/07/statetv/

PS. Ненавижу политику, достали.