dsd_corp

  $str=file_get_contents('./words.txt');
  $aw=preg_split('/[\W]+/', $str);
  $wc=array_count_values($aw);
  file_put_contents('./words_out.txt', var_export(array($aw, $wc), true));

Покетбук. Для таких ситуаций вроде лучшее решение.

Простейший вариант и пофиг на multiline с модификатором s:
#<\?([\x00-\xFF]+)\?>#

По просьбам выше выкладываю.
Идем в этот репозиторий.
Тащим оттуда три файла: xmlp.inc, progress.inc и cucumbers.zip.
Сам пример по вашему вопросу в cucumbers.zip.
xmlp.inc — парсер типа DOM.
progress.inc — просто вспомогательный, используется примером для замера и вывода на экран времени работы.

Нужно распаковать zip и в получившуюся директорию скопировать остальные два файла.

Собственно запускаем пример example.php

Основная нужная вам функция: replace_text()
Первые два параметра понятны и так — это текст для поиска и искомое.
Четвертый параметр $ignore_tags — это массив имен тегов, которые мы пропускаем. В вашем случае по условию это 'A'. 'IMG' в примере можно исключить из этого массива — я просто так добавил )
Третий параметр — на что заменить найденные вхождения.
Но если этот третий параметр false(я так сделал опцию), то функция вернет не измененную строку, а массив оффсетов найденных вхождений.
Функция не останавливается на первом валидном вхождении — заменяет все, что найдет, и все, что подходит по условию.
Если вы не хотите, чтобы функция правила косяки HTML/XML ее собственному разумению, ну и заодно хотите заменить только определенные по счету вхождения, тогда вы можете получить оффсеты, и потом либо в цикле заменить все PHP-шной функцией substr_replace(т.к. оффсеты вхождений у вас есть, а длину искомой строки вы тоже знаете), либо заменить только первое вхождение по первому оффсету из возвращенного массива.

В примере функции frt1(), frt2() и frt3() идентичны по функционалу, frt1() работает рекурсивно, в остальных от рекурсии я избавился. frt3() от frt2() отличается только ассоциативной индексацией стека(в глазах не так рябит и понятнее). А так все три эти функции делают одно и то же, первые две можно удалить.
Фактически используется frt3() для поиска с заменой и frt4() для получения оффсетов.

Файл cucumbers.txt — это ваш пример, в cucumbers1.txt я напихал еще огурцов в разные места )))
Эти файлы используются как входные, ну там разберетесь, видно все по коду.
Результаты работы экзампла тоже в файлы выплевываются, вы их увидите в той же директории после отработки скрипта.
Будут вопросы — задавайте.

Может есть смысл завести массив запрашиваемых наборов данных и заполнять их по мере приема, а из кусков интерфейса периодически проверять, не появились ли данные для текущего представления?
Что-то вроде массива или структуры:

struct my_data {
  bool received;
  uint32 request_time;
  uint32 receive_time;
  uint8 *buff;
  data_struct unpacked_data;
  ...
};

struct my_data_storage {
  struct my_data *main_data;
  struct my_data *section1_data;
  struct my_data *section2_data;
  ...
};

Соответственно при открытии любого интерфейсного блока(section) он запрашивает свои данные у… назовем это «контроллер коммуникации» — поток или объект, отвечающий за работу с удаленными серверами. Далее интерфейсный блок ждет, периодически проверяя готовность данных и отображая что там вы отображаете(крутящееся колесо или пустую табличку или еще что).

Можно контролировать таймауты приема, устаревание данных и т.п., поля request_time и receive_time у структуры блока данных в помощь.

Пример алгоритма:
— Пользователь открывает в интерфейсе блок section1.
— Показываем этот кусок интерфейса пустым или с крутящимся колесом.
— Смотрим в хранилище данных данных на поле section1_data.
— — Если оно NULL, интерфейс шлет запрос данных контроллеру коммуникации, тот в свою очередь шлет запрос данных к серверу, создавая и инициализируя начальными значениями в этом поле структуру my_data.
— — Если оно не NULL, смотрим на поле received(данные приняты и распарсены полностью). Если данные еще не приняты, ждем дальше. Если данные приняты, смотрим по receive_time их актуальность, если еще актуальны(таймаут устаревания не прошел), то отображаем, если нет — перезапрашиваем еще раз(при этом поле section1_data обнуляется и пересоздается заново, либо просто переинициализируется).
Контроллер коммуникации например может сам контролировать таймаут приема данных и выставлять флаг неудачного запроса.
Ну и т.п.
Многое зависит от того, на чем вы пишете, под какую систему, от реализации интерфейса и т.п. Как это все вместе соединить, вам решать под себя.

То есть суть в том, что каждый элемент интерфейса работает независимо от других: лезет в хранилище за своим набором данных, инициирует их запрос с сервера, заведует отображением и т.п.
Вот как-то так. Не судите строго, это просто первое, что пришло в голову по прочтении вашего вопроса.

Для тех.документации и вообще перечисленных вами форматов лучше брать Покеты 903/912 — это 9-дюймовые.
У меня вот Покет 301+ есть, для художки всем устраивает, но читать PDF на нем, отформатированный изначально под A4 — сущее мучение.
Страница на экран — нифига не видно. С масштабированием — неудобно и долго.
На 912 покете подавляющее большинство PDF документов отлично отображается без масштабирования. Именно его я взял для документации разной.

Однако все-равно у 912 есть нюансы и они очень важны:
1. электрокнижка такого размера должна лежать либо дома, либо на работе, и в защитном армированном чехле обязательно. Из-за ее размеров она еще более хрупкая, чем 6-дюймовые аналоги. В транспорте с собой таскать опасно.
2. если читать pdf/djvu как обычную книжку, то все ок. Если же документацию и даташиты, по которым так или иначе нужно часто скакать туда-сюда по разделам, уже не удобно на eInk в принципе.
Поэтому у меня так получилось, что когда я качаю большой даташит и читаю его впервые, беру Покет 912 и вдумчиво изучаю главу за главой. Это удобно. Но когда приходит время непосредственной работы с даташитом — приходится брать iPad, т.к. в электрокнижке из-за тормознутости eInk очень много времени тратится на скакание к содержанию и беготню между разделами. На девайсах с LCD это гораздо быстрее все.

Так что подумайте дважды, прежде чем брать eInk книжку, если она предназначается именно под описанный мной режим работы.
Если же нет, и вам по-любому нужна eInk читалка, можете смело брать Покетбук — одна из лучших по поддержке форматов и юзабельности.

Условие у вас конечно весьма расплывчатое.
ТЗ четко понятно только вам )
Из того, что я понял, для PHP:

$s="Есть строка\n".
"целое gg =665 j h = 78;".
"Проверить ее на условие и запомнить символы gg, j, h.".
"целое z s=234 f r = 35 s".
"целое a b c d e".
"целое i=23 j=13 k=4567 l=13243546 m=0".
"Написал регулярку:";

$r=preg_match_all('/целое(?:[\s]+[a-z]+(?:[\s]*?\=[\s]*?[\d]+)?)+/is', $s, $matches, PREG_SET_ORDER, 0);
if ($r==false || $r<=0) exit(0);
$result=array();
foreach ($matches as $m) {
  $r=preg_match_all('/[\s]+([a-z]+)(?:[\s]*?\=[\s]*?[\d]+)?/is', $m[0], $rmatches, PREG_SET_ORDER, 0);
  if ($r==false || $r<=0) continue;
  $res=array();
  foreach ($rmatches as $rs) {
    $res[]=$rs[1];
  }
  $result[]=$res;
}
@file_put_contents('out_html.txt', var_export(array($matches, $result), true));
exit(0);

Так, или иначе, нужно два прохода. На первом отбираем строки по формату, на втором получаем все необходимые аттрибуты.