Вот уже много лет храню личную базу знаний в 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 в UTF-8, в глобальной перспективе и на разных ОС
- Author
- Message
-
Offline
- Posts: 37
- Joined: Thu Sep 15, 2011 6:51 am
-
Offline
- Posts: 1250
- Joined: Thu Nov 16, 2006 11:53 am
- Location: Kyiv, Ukraine
Re: BOM в UTF-8, в глобальной перспективе и на разных ОС
Наличие BOM однозначно указывает редактору, что перед ним файл в формате Юникод. Без BOM редактору приходится догадываться об этом самостоятельно на основе анализа первых N байт (обычно от 1024 байт и больше) текстового файла. Не все редакторы делают такой анализ, и некоторые воспринимают UTF-8 без BOM как ANSI.
В общем случае наличие BOM представляется более полезным, чем его отсутствие.
В общем случае наличие BOM представляется более полезным, чем его отсутствие.
-
Offline
- Posts: 2247
- Joined: Tue Aug 07, 2007 2:03 pm
- Location: Vinnitsa, Ukraine
-
Offline
- Posts: 37
- Joined: Thu Sep 15, 2011 6:51 am
DV, спасибо, не знал, что UTF-8 без BOM может быть распознан как ANSI.
FeyFre, да, конечно, файлы предполагается обрабатывать не только текстовыми редакторами, но и разномастными утилитами. С TXT я исповедую концепцию "единообразный простой материал + разнообразные специализированные инструменты для его обработки" (при этом всё предельно кроссплатформенно и без феодальной привязки к определённому ПО). С простым текстом - как с деревом, из которого можно и дом сколотить, и лодку смастерить, и скульптуру сваять.
В общем, если не найдётся прецедентов, в которых наличие BOM в UTF-8 создавало проблемы, то вопрос можно считать решённым. Пока что я знаю только один такой случай, связанный с CMS WordPress (но тут всё же про *.php и *.html, а не *.txt).
FeyFre, да, конечно, файлы предполагается обрабатывать не только текстовыми редакторами, но и разномастными утилитами. С TXT я исповедую концепцию "единообразный простой материал + разнообразные специализированные инструменты для его обработки" (при этом всё предельно кроссплатформенно и без феодальной привязки к определённому ПО). С простым текстом - как с деревом, из которого можно и дом сколотить, и лодку смастерить, и скульптуру сваять.
В общем, если не найдётся прецедентов, в которых наличие BOM в UTF-8 создавало проблемы, то вопрос можно считать решённым. Пока что я знаю только один такой случай, связанный с CMS WordPress (но тут всё же про *.php и *.html, а не *.txt).
-
Offline
- Posts: 1250
- Joined: Thu Nov 16, 2006 11:53 am
- Location: Kyiv, Ukraine
Говоря о консольных утилитах, портированных с 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.
А вот, к примеру, написанный на .NET искатель/заменитель текста TextCrawler (http://www.digitalvolcano.co.uk/content/textcrawler) ориентируется по BOM - в его форуме даже есть тема насчёт того, что UTF-8 без BOM воспринимается им как ANSI.