AkelPad

Вот уже много лет храню личную базу знаний в TXT в кодировке ANSI (1251), и АкелПад (в паре с клавиатурным лончером Launchy) - мой основной инструмент. Задумал переконвертировать её в UTF-8, который представляется более удобным для того, чтобы обрабатывать эту самую базу как разными инструментами (напр., ZIM и ResophNotes, для которых UTF-8 - родная кодировка, а ANSI они вообще не понимают), так и на разных платформах, отличных от Windows (Android, MacOS).

Вопрос: конвертировать с BOM, или без него?
Я так понимаю, что всё, для чего BOM нужен в однонаправленной UTF-8 - это помощь программе-редактору в определении кодировки (c BOM программа однозначно понимает, что перед ней Юникод). Насколько (на практике) эта помощь нужна современным программам?
Случались ли ситуации, в которых наличие BOM в UTF-8 мешало удобной и безпроблемной работе с файлами?
Хочется выбрать один вариант (с BOM или без), конвертировать всё пакетом, и на ближайшие "дцать" лет не вспоминать о кодировках и их особенностях..

Наличие BOM однозначно указывает редактору, что перед ним файл в формате Юникод. Без BOM редактору приходится догадываться об этом самостоятельно на основе анализа первых N байт (обычно от 1024 байт и больше) текстового файла. Не все редакторы делают такой анализ, и некоторые воспринимают UTF-8 без BOM как ANSI.
В общем случае наличие BOM представляется более полезным, чем его отсутствие.

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

DV, спасибо, не знал, что UTF-8 без BOM может быть распознан как ANSI.

FeyFre, да, конечно, файлы предполагается обрабатывать не только текстовыми редакторами, но и разномастными утилитами. С TXT я исповедую концепцию "единообразный простой материал + разнообразные специализированные инструменты для его обработки" (при этом всё предельно кроссплатформенно и без феодальной привязки к определённому ПО). С простым текстом - как с деревом, из которого можно и дом сколотить, и лодку смастерить, и скульптуру сваять.

В общем, если не найдётся прецедентов, в которых наличие BOM в UTF-8 создавало проблемы, то вопрос можно считать решённым. Пока что я знаю только один такой случай, связанный с CMS WordPress (но тут всё же про *.php и *.html, а не *.txt).

Говоря о консольных утилитах, портированных с Unix/Linux, я встречал ещё такое упоминание: "For some reason this tool (psql for postgres) can't handle leading BOM character sequences in utf8 encoded files". Но тут мы, похоже, сталкиваемся с дубовостью разработчиков, которые в своих утилитах ожидают либо всегда UTF-8, либо всегда ANSI, не делая никаких дополнительных проверок (даже на наличие BOM).
А вот, к примеру, написанный на .NET искатель/заменитель текста TextCrawler (http://www.digitalvolcano.co.uk/content/textcrawler) ориентируется по BOM - в его форуме даже есть тема насчёт того, что UTF-8 без BOM воспринимается им как ANSI.

Один раз столкнулся с проблемой, когда софт у хостера неправильно распозновал BOM-файлы и в итоге на сайте в начале страницы был заголовок от BOMа. Пришлось все *.php(и прочие) файлы перегонять в уникод без BOM'а.