Почему делает Подвижный, думают, что мои файлы SQL являются двоичными?
Я просто написал сценарий своего SQL Server, сохранил procs, определения таблицы, и т.д. с помощью Studio управления SQL Server, и попытался добавить их к моему Подвижному репозиторию управления исходным кодом. Они были добавлены очень хорошо, но теперь когда я изменяюсь и разность их, Подвижный называет их "двоичными файлами" и не дает мне, надлежащее объединило различный.
Я думал, что кодирование могло бы быть проблемой, таким образом, я пытался повторно создать сценарии и определить ANSI для вывода текстового файла, но я получаю то же поведение. Я могу просмотреть их очень хорошо в блокноте без любого нечетно выглядящего разоблачения символов. Почему делает Подвижный, думают, что эти файлы являются двоичными?
Иначе, если кто-то может рекомендовать хороший инструмент для сценариев базы данных SQL Server, которая не могла бы вызвать эту проблему, которая могла бы работать, также.
4 ответа
Я столкнулся с этой проблемой, потому что SQL Server Management Studio сохраняет файлы в формате Unicode. Первые два байта (в большинстве случаев) текстового файла Unicode определяют кодировку. Большинство новых текстовых редакторов (например, Блокнот) обрабатывают это прозрачно.
Первые два байта, вероятно, там, где ваша проблема. Они могут выглядеть как ÿþ. Или FF FE в шестнадцатеричном формате.
На кнопке «Сохранить» в диалоговом окне «Сохранить» есть список выбора. Выберите «Сохранить с кодировкой ...» и выберите «US-ASCII-Codepage20127». Я считаю, что эта настройка неактивна и останется для будущих сохранений.
Andrew прав; это где-то байт NUL (мое предположение - Byte Order Mark в начале, вставленный грубым редактором). Однако не беспокойтесь об этом, в отличие от SVN или CVS Mercurial не обрабатывает двоичные и текстовые файлы по-разному. Он отображает их по-разному, когда вы делаете 'hg log', но они совсем не обрабатываются по-разному.
В предстоящих релизах mercurial особый случай BOM и не позволяйте им вызывать поведение "пользователь, вероятно, не хочет видеть diff этого на консоли".
Согласно документации, файл считается двоичным, если в нем есть нулевые байты. В файлах SQL не должно быть нулевых байтов, поэтому я бы сначала проверил это (попробуйте посмотреть в шестнадцатеричном редакторе). Полагаю, вы знаете, что можете заставить diff рассматривать его как текст
Я столкнулся с этим, когда редактировал файл хранимых процедур из SQL Server на linux и использовал git. Git думал, что это двоичный файл, потому что файл из SQL Server был UTF-16 и, следовательно, содержал NULs. Я решил эту проблему с помощью emacs, который позволяет изменить кодировку на UTF-8.