Кстати, на будущее - дейсвительно нужно сохранять в UTF8.
Возьмите на заметку если будут странные жалобы на проблемы с конфигом.
Недавно столкнулся что после небольшого изменения конфига нода вдруг вообще перестала запускаться: фатальная ошибка при запуске. То, что дело в конфиге понял сразу, но вот что именно с ним не так ОЧЕНЬ долго не мог понять - т.к. проверял по несколько раз и все параметры и их значение были верны.
А как оказалось проблема была вовсе не в самих добавленных/измененных параметрах, а в том что кроме них я еще написал комментарий к одному из параметров на русском языке.
Вот уж не подулмал бы, что комментарий(которые вообще-то должны полностью игнорироваться при загрузке/чтении конфига) может вызывать фатальный сбор.
Однако это так. Нода крэшилась из-за “неопознанного символа” в конфигурационном файле не успев ничего записать в лог. Последнее впрочем логично т.к. путь к логу надо сначала из конфига прочитать. И увидел эту ошибку только после того, как запустил ее отдельно из коммандной строки, а не как службу.
Помогло как раз принудительное пересохранение конфига в UTF8 (по умолчанию редактор увидев кириллицу сохранил его в ANSI win-1251).
Такое скорее всего будет происходить с любыми другими языками кроме английского/латиницы если пользователь решит комментарий на своем родном языке добавить. А догадаться что безобидный, ничего не значащий комментарий может намертво положить ноду весьма непросто.
Дело было в этом самом пресловутом BOM, почти все встроенные редакторы это делают. Поэтому мы всегда рекомендуем использовать именно Notepad++ или Visual Studio Code. Изначально там UTF8 кодировка. А как только вы используете Блокнот или ещё хуже - WordPad/Word, в лучшем случае кодировка станет системной (win-1251), а в худшем позаменяет обычные символы кавычек и минусов на “вычурные”, моментально сделав конфиг непригодным. Ну или просто этот самый BOM вставит в самое начало файла (первые несколько байт и их не видно).
Эти вещи я знаю, поэтому обычно (в этом случае тоже) использую AkelPad, это как раз примерный аналог Notepad++, работающий с чистым текстом без форматирования.
Я пробовал когда-то давно и то и другое, просто к AkelPad больше привык и он сейчас уже на всех моих машинах установлен, вместе с настроенной пачкой плагинов для расширения возможностей. Типа фильтров строк с регулярными выражениями, слежения за изменениями в логе в режиме реального времени (аналог tail -f) и т.д.
Но он тоже изменил кодировку на win-1251. Точнее файл уже очень давно в ней был сохранен. Вероятно - еще с момента самого первого его редактирования когда-то несколько лет назад при первичной установке и настройке ноды. Но это не вызывало (и не вызывает до сих пор - проверил другие ноды там конфиги тоже в win-1251 сохранены) никаких проблем. До тех пор пока в файле не появились первые локальные символы (в данном случае - кириллицы).
Так что я уверен, что дело вообще не в BOM, а именно в локальных символах если они не в UTF кодировке. Насчет BOM я это даже отдельно проверил, открыв копию проблемного (вызывающего вылет ноды при старте) конфига в HEX-редакторе. Первые байты вызывающего сбой файла: 23 20 68 6F 77 20
Это соответствует началу 1й строки конфига “# how frequently bandwidth usage rollups are calculated” без каких либо лишних символов.
Насколько понимаю BOM только в UTF как раз используются, так что в win-1251 и других локальных кодировках его и не может быть.
К сожалению, не аналог. Он предполагает, какую кодировку использовать вместо той, что была. С другой стороны, в Windows никогда нельзя быть уверенным, что везде будет UTF8…
Да, поэтому для не англоязычных я всегда рекомендую сохранять в кодировке UTF8 без BOM. Потому что большинство программ вообще ANSI берут по умолчанию…
А это интересно. С другой стороны, ваш редактор такой пакостью не занимается.
верно. Просто по умолчанию оно использует UTF8 (ну, или должно…). А встроенные редакторы туда ещё и свой любимый BOM добавляют…
Может, кстати, исправили. Я не проверял после Windows 8…