Вы сами правильно сказали, то что вы объяснили о fasm - это костыль.
Вместо исправления проблемы - речь идёт про её обходы. Это неправильно, не зависимо от правильности BOM.
Ну так не применяйте его, вам уже кучу раз об этом сказали. Зачем вы применяете непригодное и не задуманное быть пригодным, а потом жалуетесь на это?
Ну так не применяйте его, вам уже кучу раз об этом сказали. Зачем вы применяете непригодное и не задуманное быть пригодным, а потом жалуетесь на это?
Вам так трудно исправить баг, про который вам подробно рассказали и на сто рядов доказали, что это именно баг? Если такой же баг есть в Visual Studio, это что, значит, что его исправлять нельзя?!
Чем плохо использовать ABC IDE для редактирования кода на паскале, если этот код потом предполагается компилировать Free Pascal? Подсветка синтаксиса паскаля, хоть и не идеальна совместима с fpc, но ведь лучше чем никакой, правильно? В идеале в IDE вообще должна быть опция, какой компилятор вызывать при нажатии F9, чтобы можно было сделать полную интеграцию ABC IDE с компилятором FPC.
Вместо исправления проблемы - речь идёт про её обходы.
Ну да. правильный способ исправления проблемы — изменить текстовый редактор так, чтобы он не вставлял BOM в UTF-8. Но для некоторых редакторов (MS Notepad, PascalABC.net IDE и тд) это невозможно или сложно. поскольку такой настройки нету.
Если до MS вряд ли реально достучаться, то у ABC есть хотя бы форум.
Вообще стандарт Unicode не запрещает BOM, хотя и не советует его добавлять. Просто он бесполезен, но не значит, что запрещен. В стандарте также есть рекомендация не добавлять / не убирать его при редактировании.
Фактически BOM — экзотический пробел нулевой ширины. То есть мусорный символ. В обычном тексте он особо не помешает, а вот в коде на любом языке — очень даже вреден.
В некоторые компиляторы добавлены костыли для пропуска BOM, но ведь не во все, поэтому в коде он категорически не рекомендуется.
В языках, в спецификации которых не описано, что BOM допустим, его ни в коем случае не следует ставить, но к сожалению некоторые редакторы ставят.
Фактически BOM в начале потока это BOM и ничто другое. Это в середине он так воспринимается в виде костыля, для случаев когда например два файла конкатенировали.
В спецификации языка и не должно быть написано ничего про BOM. Компилятор должен открыть и прочитать файл. Компилятор в целом может требовать что-то, что не определено в спецификации. Например, gcc нормально работает с файлами UTF-8 и BOM, но не переваривает переменные в UTF-8.
А у MS с этим проблемы, потому что они изначально все через ж делают и не осилили определение кодировки и например в VS2019 с этим проблемы… опять. Просто системной кодировки UTF-8 там до сих пор нет, поэтому он им всегда нужен как маркер кодировки.
Я посмотрел код текстового редактора. В принципе, я Вас понимаю.
К сожалению, редактор взят As is из Sharp Developа. И - увы - сохранение с BOM там запаяно. Если бы была какая-то опция, мы бы каким-то образом сделали чтобы это можно было переключать.
Я также посмотрел редактор последнего Lazarus. Он нормально открывает файлы с BOM и если их изменить и сохранить, то тоже сохраняет с BOM. К чести сказать, новые файлы он сохраняет без BOM.
А, то есть виджет редактора кода вы не сами писали, а взяли готовый?
Ну так что мешает найти там где вставляется BOM и закомментировать эту строку? Наверное наиболее правильное поведение будет не трогать BOM, и всегда считать файлы за UTF-8 если нет явных признаков иного, а BOM считать обычным символом и желательно ещё и сделать его видимым, хотя в норме он и рендерится как пробел нулевой ширины.
Хотя даже если он будет неразрывным пробелом нулевой ширины. его можно удалить вручную, просто неудобно.
Все работают с BOM. Вы хотите без BOM. Нужна опция. И нужен кто-то кто аккуратно это сделает.
Как показывает практика, эта универсальная фраза в 100% случаев приводит к тому, что вопрос снимается с повестки дня. Никто не хочет что-то делать, но все готовы без устали обвинять и критиковать.
В смысле, вы хотите сказать, что кому-то этот BOM нужен и полезен?
Тогда вопросов нет,
Но вы уверены, что им действительно кто-то пользуется в том смысле, что у кого-то есть use-case, где, если ABC IDE начнёт сохранять без BOM, придётся ставить другую программу и его добавлять?
Вообще можно по умолчанию BOM не трогать, не добавлять и не удалять, и добавить в меню две функции — убрать BOM из файла и добавить BOM, тогда опция будет не нужна. Ещё лучше вариант — сделать BOM видимым, например. в виде чёрного прямоугольника с надписью BOM, тогда пользователь будет видеть, есть он или нет, и сможет самостоятельно его удалить или (в каких-то экзотических случаях, которые скорее всего никогда не возникнут), добавить.
BOM
Тот же fpc судя по документации использует BOM для определения кодировки исходников: “if the file starts with an UTF-8 BOM, then the source file codepage is UTF-8, otherwise … the source file codepage is set to CP_ACP (for backward compatibility with previous FPC versions)” (FPC Unicode support - Free Pascal wiki). 
Ну так это проблемы fpc, нам-то они тут зачем? Если я купил кофеварку, почему ее производитель должен от меня выслушивать упреки, что она не позволяет варить пельмени?
Вы, извините, как тот мужик из бородатого советского анекдота, который просил переселить его в другую комнату общежития, потому что “из этой видна раздевалка в женской душевой”:
Catcher нравится fpc. Catcher зацепился за то что BOM никому не нужен, а pabc его ставит и это нужно всенепременно поправить. Я ему отвечаю, что тот же fpc как раз использует BOM для определения UTF-8 кодировки.
Другими словами, если мы хотим совместимости, то pabc как раз правильно делает что добавляет BOM в utf-8 файлах, иначе их fpc не сможет нормально интерпретировать.
Я нигде не писал, что pabc что-то должен делать по другому, я как раз не вижу тут проблемы. А учитывая, что IDE pabc вообще под linux нативно не работает, а под виндой поведение соответствует поведению того-же VS - на мой взгляд вообще все вполне корректно.
Но чукча видимо не читатель…
Зря они конечно так сделали, но кроме BOM указан вариант {$codepage UTF8}, который всё же лучше, ну и ещё есть вариант ещё лучше — не иметь в исходном коде никаких символов вне ASCII, тогда не будет нужна ни директива, ни BOM, ни что-то иное.
Как указано по ссылке, BOM используется только, если такой директивы нет.
В VS, насколько я понимаю, это поведение уже исправили, да и в VScode его нет.
Я и так много букв написал, почему это некорректно.
Если вам в программе надо текст на русском вывести вы что предлагаете делать? 
Не, есть люди, которые ради этого utf-8 эскейп последовательности фигачят в коде… только как потом такой код читать.
Не похоже: c++ - VS2019 compiler misinterprets UTF8 without BOM file as ANSI - Stack Overflow
Не похоже: c++ - VS2019 compiler misinterprets UTF8 without BOM file as ANSI - Stack Overflow
Ну да, у них, закономерно для микрософта, фикс неполноценный, нужно указывать ключ компилятора /utf-8, что и написано по ссылке. А автору вопроса нужно перевести все файлы проекта в формат UTF-8 без BOM и включить этот ключ в настройках компилятора.
Для этого есть специальная библиотека gettext. Непосредственно в коде все сообщения должны быть только на английском языке в ASCII, а все русские, китайские, японские, немецкие, французские и тд сообщения, даже если латиницей, а уж тем более иероглифами или кириллицей, должны быть вынесены в отдельный файл локализации, где кодировка указывается одной из директив самого файла и подставляться в зависимости от настроек приложения.
Но если уж очень хочется, то можно сохранять только в формате, совместимом с ASCII, то есть без мусорных начальных байтов.
А если мы не хотим вляпаться в GPL, то что? Runtime там под LGPL, но все равно не все так просто. Ну и если вы делаете учебную программу на 10 строк, то тоже будем gettext тянуть? ради двух строк? Это для больших проектов имеет смысл, а по мелочи просто глупо.
UTF-8 с символами больше 128 не могут быть совместимы с ASCII по определению. Такие файлы будут несовместимы с fpc по умолчанию.
Если у вас есть особый usecase (я так и не понял какой) где вам bom мешает - можете просто скрипт написать, который его удаляет. Можете еще добавить в него replace(’\r\n’, ‘\n’). Это всего несколько строчек кода.
А разве gettext под GPL? И даже если и так, то просто выкладываете вашу программу под GPL и всё, в этом нет ничего плохого.
Тогда просто пишем по-английски и всё. Зачем перевод в учебной программе из двух строк? Разве что цель учебной программы как раз в том, чтобы разобраться с тем как делать многоязычные программы. Тогда да, gettext.
Мне работодатель не разрешает
Ну например в задании написаны вывести результат на русском
Ну например в задании написаны вывести результат на русском
Ну, значит, плохое задание.
Но вообще никто не мешает сохранить в UTF-8 и если компилятор как есть не сожрёт, то добавить директиву какую-нибудь, разную для разных языков программирования или ключ компилятора вроде /utf-8
Значит плохой работодатель. Но, как вы сами заметили, gettext не под GPL. Да и вообще, то что я не знаю других библиотек для интернационализации, не значит, что их нет. Наверняка есть что-нибудь другое, может даже совместимое с теми же *.po и *.mo файлами.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021