Массовая замена HTML-разметки в Sublime Text с помощью RegExp

При работе с HTML часто возникает рутинная задача: есть десятки однотипных элементов, которые нужно заменить на реальную разметку. Делать это вручную - долго и рискованно, также можно легко допустить ошибку.

В моём случае это были заглушки вида:

<p>Image 1</p>
<p>Image 2</p>
<p>Image 3</p>

Нужно было превратить их в теги изображений, сохранив номера файлов изображений.

Почему не руками

Ручная правка подходит только для пары строк. Когда элементов больше 10–20, возрастает риск:

• ошибиться в номере изображения

• забыть закрыть тег

• нарушить единообразие разметки

Поэтому логичнее использовать инструменты, которые уже есть в редакторе.

Решение через Sublime Text и RegExp

В Sublime Text есть мощный поиск и замена с поддержкой регулярных выражений. Этого более чем достаточно для задачи.

Открываем HTML-файл и вызываем панель замены:

• Ctrl + H (Windows / Linux)

• Cmd + Alt + F (macOS)

Обязательно включаем режим Regular Expression (иконка .*).

Шаблон поиска

<p>Image (\d+)</p>

Разберём выражение:

• <p>Image — фиксированная часть

• (\d+) — группа захвата, которая находит любое число

• </p> — закрывающий тег

Число внутри скобок сохраняется как первая группа.

Шаблон замены

<img src="images/\1.jpg">

Здесь \1 — ссылка на первую группу захвата из шаблона поиска. На её место подставляется найденное число.

В результате:

• Image 1 → images/1.jpg

• Image 12 → images/12.jpg

Проверка и замена

Перед массовой заменой полезно нажать Find All, чтобы убедиться, что совпадения находятся только там, где нужно.

После этого можно смело использовать Replace All — Sublime Text заменит все подходящие строки за один шаг.

Подводные камни

Несколько моментов, о которых легко забыть:

• если не включить RegExp, \1 подставлен не будет

• в Sublime используется именно \1, а не $1

• шаблон чувствителен к пробелам и регистру

Альтернативы

Для подобных задач подойдут и другие инструменты:

• sed в терминале

• массовая генерация HTML через bash-циклы

• аналогичная замена в VS Code

Но если файл уже открыт в Sublime Text, RegExp — самый быстрый вариант.

Вывод

Регулярные выражения в Sublime Text позволяют эффективно автоматизировать рутинные правки HTML без дополнительных скриптов и плагинов. Даже простые приёмы вроде групп захвата экономят время и снижают количество ошибок.

Дополнительно

Более подробная пошаговая инструкция с ориентацией на новичков опубликована в моём блоге:

https://kodprog.ru/kak-bystro-zamenit-tekst-na-tegi-img-v-sublime-text

Почему я снова вернулся на Debian после Ubuntu 24.04 и Fedora 42

Недавно я купил новый ноутбук и решил использовать это как повод попробовать что-то свежее, кроме привычной Ubuntu.

Сначала я поставил Ubuntu 22.04, но быстро понял, что хочу поэкспериментировать и посмотреть, как себя чувствуют другие дистрибутивы на новом железе.

Я решил обновиться с Ubuntu 22.04 до 24.04 - казалось бы, логичный шаг: свежий LTS, новые пакеты, улучшения в GNOME. Но спустя пару недель я понял, что дистрибутив нужно менять. Расскажу, почему.

Медленная работа с большим количеством файлов

Главная причина — баг, который проявлялся в файловом менеджере.
Когда в каталоге было много файлов, его открытие могло занимать слишком много времени, иногда десятки секунд.

Если регулярно работаешь с проектами, папками картинок или архивами — это превращается в настоящий тормоз.

Да, баг могут исправить, но в тот момент он мешал работать каждый день.

Fedora: понравилась, но не подошла под задачи

Первым я решил попробовать Fedora 42.
Впечатления были отличные:

• система работает быстро,

• GNOME выглядит аккуратнее без патчей Canonical,

• Wayland ощущается максимально плавным,

• окружение ощущается «современным из коробки».

Но очень быстро я столкнулся с проблемой:
часть нужных мне пакетов просто отсутствовала в репозиториях.

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

В итоге я пытался найти нужные программы, но либо я их не там искал, либо их не было, либо которые я нашел не заработали.

Почему я выбрал Debian 13

В этом году как раз вышел Debian 13 с GNOME 48, я решил попробовать его.

И для себя получил:

• стабильность, к которой привык,

• современный GNOME без патчей,

• огромный набор пакетов в репозиториях,

• отсутствие лишних предустановленных компонентов,

• а главное — всё, что мне нужно, установилось без танцев.

В итоге Debian остаётся для меня тем самым балансом:

Итог

Ubuntu 24.04 — неплохой релиз, но сейчас он не подходит под мои задачи.

Fedora оставила отличные впечатления — она бы идеально подошла мне «для души».
Но для работы мне нужна система, где всё устанавливается из репозиториев, ничего не ломается после обновлений и не приходится искать обходные решения.

Так я и остановился на Debian 13 с GNOME 48 — и пока это лучший вариант для моего сценария.

А прочитать статью про мой ноутбук, который я приобрел для Линукс за 25000 рублей, вы можете по ссылке:

https://kodprog.ru/noutbuk-dlya-linuks-za-25000

Почему мне не понравился Arch Linux

Однажды я решил попробовать Arch Linux — в качестве эксперимента, чтобы понять, подходит ли он мне как основная система. Спойлер: нет. Хотя я понимаю, почему Arch нравится многим, лично мне он не зашёл. Расскажу коротко — без холивара, просто субъективный опыт.

1. Слишком много ручной настройки

Да, это философия Arch — «собери систему под себя».
Но когда даже базовые вещи требуют:

• поиска пакета вручную,

• чтения вики,

• настройки конфигов,

в какой-то момент это начинает отвлекать от работы.

Мне хотелось просто пользоваться системой, а не постоянно её собирать.

2. Установка превращается в квест

Я понимаю, что сейчас есть Archinstall, но это всё равно:

• больше шагов,

• больше точек, где можно ошибиться,

• больше нюансов, которые надо держать в голове.

Для сравнения: Ubuntu/Debian/Fedora ставятся буквально за 10–15 минут без сюрпризов.
Arch — это отдельный процесс, который каждый раз занимает время, силы и концентрацию.

3. Постоянные обновления и риск поломок

Rolling release — это круто, но это также:

• риск, что обновление завтра что-то сломает,

• необходимость держать в голове зависимости,

• желание обновляться реже, но при этом понимание, что массово обновлять ещё опаснее.

Мне нужен более предсказуемый рабочий инструмент, а не адреналиновый аттракцион.

4. Много времени уходит на поиск информации

Arch Wiki — одна из лучших в мире, но:

• почти каждое действие требует чтения документации,

• часто нужно искать решения на форумах,

• иногда конфликты пакетов решаются вручную.

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

5. Минимализм оказался минусом

Arch устанавливается «голым».
Ты ставишь:

• окружение,

• драйверы,

• кодеки,

• шрифты,

• инструменты,

• конфигурируешь систему практически с нуля.

Кому-то это даёт свободу.
Мне — лишние часы, которые можно было потратить на реальную работу.

Итог

Я понимаю, за что любят Arch — скорость, свежие пакеты, гибкость. Но для моего сценария использования он требует слишком много времени и внимания. В итоге я вернулся к Debian/Ubuntu: они просто работают, а я могу заниматься задачами, а не конфигами.