BOM в UTF-8, в глобальной перспективе и на разных ОС

Russian main discussion
Post Reply
  • Author
  • Message
Offline
Posts: 37
Joined: Thu Sep 15, 2011 6:51 am

BOM в UTF-8, в глобальной перспективе и на разных ОС

Post by KeepGoing »

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

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

DV
Offline
Posts: 1250
Joined: Thu Nov 16, 2006 11:53 am
Location: Kyiv, Ukraine

Re: BOM в UTF-8, в глобальной перспективе и на разных ОС

Post by DV »

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

Offline
Posts: 2247
Joined: Tue Aug 07, 2007 2:03 pm
Location: Vinnitsa, Ukraine

Post by FeyFre »

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

Offline
Posts: 37
Joined: Thu Sep 15, 2011 6:51 am

Post by KeepGoing »

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

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

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

DV
Offline
Posts: 1250
Joined: Thu Nov 16, 2006 11:53 am
Location: Kyiv, Ukraine

Post by DV »

Говоря о консольных утилитах, портированных с 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.

s1n
Offline
Posts: 1
Joined: Sun Jan 06, 2013 3:14 am

Post by s1n »

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