Нет проблем. В командной строке отсутствует аргумент-терминатор поля, поэтому по умолчанию используется вкладка. Это описано в документации:
-t field_term
Указывает терминатор поля. По умолчанию используется \ t (символ табуляции). Используйте этот параметр, чтобы переопределить терминатор поля по умолчанию. Для получения дополнительной информации см. Указать терминаторы полей и строк (SQL Server) .
Если вы укажете терминатор поля в шестнадцатеричной записи в команде bcp.exe, значение будет усечено до 0x00. Например, если вы укажете 0x410041, будет использовано 0x41.
Если field_term начинается с дефиса (-) или косой черты (/), не включайте пробел между -t и значением field_term.
Ссылка указывает на целую статью, в которой объясняется, как использовать терминаторы для каждой из групповых операций.
Что касается операции копирования / вставки, то она не имеет ничего общего с SQL Server. SQL Server не имеет пользовательского интерфейса, это сервис. Я подозреваю, что то, что было вставлено в Блокнот, было скопировано из сетки SSMS.
SSMS - это клиент инструмент, как и любой другой. Когда вы копируете данные из него в буфер обмена, он решает, что поместить туда и какой формат использовать. Этот формат может быть простым текстом с использованием пробелов и вкладок для разметки, RTF, HTML и т. Д.
Простой текст с вкладками в качестве разделителей полей, вероятно, является лучшим выбором для любого инструмента, так как он сохраняет визуальную компоновку до точки и использует только один символ в качестве разделителя. Можно также использовать макет фиксированной длины с использованием пробелов, но при этом будут добавлены символы, которые вполне могут быть частью поля.
Кодировки и кодовые страницы
-c
экспортирует данные с использованием кодовой страницы пользователя по умолчанию. Это означает, что текст, хранящийся в полях varchar
с использованием другой кодовой страницы (сопоставление), может быть искажен. Невидимые символы Юникода также будут искажены и будут отображаться как что-то еще или как ?
.
-c
Выполняет операцию с использованием символьного типа данных. Эта опция не запрашивает для каждого поля; он использует char в качестве типа хранилища, без префиксов и с \ t (символ табуляции) в качестве разделителя полей и \ r \ n (символ перевода строки) в качестве разделителя строки. -c не совместим с -w.
Лучше использовать экспорт файла как UTF16, используя -w
.
-w
Выполняет операцию массового копирования с использованием символов Юникода. Эта опция не запрашивает для каждого поля; он использует nchar в качестве типа хранения, без префиксов, \ t (символ табуляции) в качестве разделителя полей и \ n (символ новой строки) в качестве разделителя строк. -w не совместим с -c.
Кодовую страницу можно указать с помощью параметра -C
. Например, -C 1251
будет экспортировать данные с использованием кодовой страницы Latin1 в Windows. 1253 будет экспортировать его с использованием греческой кодовой страницы.
-C {ACP | OEM | RAW | code_page}
Указывает кодовую страницу данных в файле данных. code_page уместен, только если данные содержат столбцы типа char, varchar или text со значениями символов больше 127 или меньше 32.
SQL Server 2016 и более поздние версии также могут экспортировать текст как UTF8 с -C 65001
. Более ранние версии не поддерживают UTF8.
Версии до версии 13 (SQL Server 2016 (13.x)) не поддерживают кодовую страницу 65001 (кодировка UTF-8). Версии, начинающиеся с 13, могут импортировать кодировку UTF-8 в более ранние версии SQL Server.
Все это описано в онлайн-документации bcp .
Эта тема настолько важна для любой базы данных, что в ней есть целый раздел с описанием формата данных и соображений , с использованием файлов формата для указания различных настроек для каждого столбца , и рекомендации по обеспечению совместимости с другими приложениями