Вместо русских букв знаки вопроса при импорте из эксель в ms sql

Обновлено: 06.01.2025

Символьный формат Юникода рекомендуется для массового переноса данных между несколькими экземплярами SQL Server через файл данных, содержащий символы расширенной или двухбайтовой кодировки (DBCS). Формат символьных данных Юникода позволяет экспортировать данные из сервера в кодовой странице, отличающейся от кодовой страницы, используемой выполняющим операцию клиентом. В этих случаях использование символьного формата Юникода имеет следующие преимущества.

Если данные источника и назначения имеют тип данных Юникода, при использовании символьного формата Юникода все символьные данные сохраняются.

Если данные источника и назначения имеют тип данных, отличный от Юникода, использование символьного формата Юникода позволяет свести к минимуму потери дополнительных символов данных из источника, которые не могут быть представлены в назначении.

Особые рекомендации по использованию символьного формата Юникода, bcp и файла форматирования

Метки порядка байтов могут быть неправильно интерпретированы при следующих условиях:

для указания символа Юникода используется программа bcp и параметр -w ;

используется файл форматирования;

первое поле в файле данных не содержит символы.

Узнайте, можно ли использовать какой-либо из следующих обходных путей для решения вашей конкретной задачи:

Не используйте файл форматирования. Пример этого обходного пути представлен ниже: ознакомьтесь с разделом Использование bcp и символьного формата Юникода для импорта данных без файла форматирования.

Используйте параметр -c вместо -w.

Повторно экспортируйте данные, используя собственный формат.

Вручную вставьте первую запись в целевой таблице, а затем используйте параметр -F 2 , чтобы начать импорт со второй записи.

Вручную вставьте первую фиктивную запись в файл данных, а затем используйте параметр -F 2 , чтобы начать импорт со второй записи. Пример этого обходного пути представлен ниже: ознакомьтесь с разделом Использование bcp и символьного формата Юникода для импорта данных с файлом форматирования, не являющимся XML.

Используйте промежуточную таблицу, в которой первый столбец имеет символьный тип данных, или

повторно экспортируйте данные и измените порядок полей данных так, чтобы первое поле данных содержало символы. После этого используйте файл форматирования для повторного сопоставления поля данных с фактическим порядком в таблице. Например, ознакомьтесь с разделом Использование файла форматирования для сопоставления столбцов таблицы с полями файла данных (SQL Server).

Параметры команд для символьного формата Юникода

Импортировать в таблицу данные в символьном формате Юникода можно при помощи программы bcp, инструкций BULK INSERT или INSERT . SELECT * FROM OPENROWSET(BULK. ). Для команды bcp или инструкции BULK INSERT формат данных можно указать в инструкции. Для инструкции INSERT . SELECT * FROM OPENROWSET(BULK. ) нужно указать формат данных в файле форматирования.

Символьный формат Юникода поддерживается следующими параметрами командной строки:

Get-Help	Параметр	Описание
bcp	-w	Использует символьный формат Юникода.
BULK INSERT	DATAFILETYPE ="widechar"	Использует символьный формат Юникода при массовом импорте данных.
OPENROWSET	Недоступно	Требуется использовать файл форматирования.

Также в файле форматирования можно указать форматирование для каждого поля. Дополнительные сведения см в разделе Файлы форматирования для импорта или экспорта данных (SQL Server).

Пример условий теста

Примеры в этой статье основаны на таблице и файле форматирования, которые определены ниже.

Образец таблицы

Приведенный ниже скрипт создает тестовую базу данных, таблицу с именем myWidechar и заполняет таблицу начальными значениями. Выполните следующий запрос Transact-SQL в Microsoft SQL Server Management Studio (SSMS):

Образец файла форматирования в формате, отличном от XML

SQL Server поддерживает два типа файлов форматирования: файлы форматирования в формате, отличном от XML, и XML-файлы форматирования. Файл форматирования не в формате XML поддерживается более ранними версиями SQL Server. Дополнительные сведения см. в разделе Файлы формата, отличные от XML (SQL Server) . Следующая команда будет использовать служебную программу bcp для создания файла форматирования myWidechar.fmt в формате, отличном от XML, на основе схемы myWidechar . Чтобы создать файл форматирования с помощью служебной программы bcp , укажите аргумент format , а вместо пути файла данных задайте значение nul . Параметр format также требует наличия параметра -f . Кроме того, в этом примере квалификатор c используется для указания символьных данных, а T используется для указания доверенного подключения, в рамках которого применяется встроенная система безопасности. В командной строке введите следующие команды:

SQLState = S1000, NativeError = 0
Error = [Microsoft][ODBC Driver 13 for SQL Server]I/O error while reading BCP format file

Примеры

В приведенных ниже примерах используется база данных и файлы форматирования, созданные ранее.

Использование bcp и символьного формата Юникода для экспорта данных

Параметр -w и команда OUT . Примечание. Файл данных, созданный в этом примере, будет использоваться во всех последующих примерах. В командной строке введите следующие команды:

Использование bcp и символьного формата Юникода для импорта данных без файла форматирования

Параметр -w и команда IN . В командной строке введите следующие команды:

Использование bcp и символьного формата Юникода для импорта данных с файлом форматирования, не являющимся XML

Параметры -w и -f switches и IN commи. Так как этот пример включает bcp, файл форматирования, символ Юникода, а первое поле данных в файле данных не содержит символы, потребуется использовать обходной путь. См. раздел Особые рекомендации по использованию символьного формата Юникода, bcp и файла форматированиявыше. Файл данных myWidechar.bcp будет изменен: в него будет добавлена дополнительная фиктивная запись, которая затем будет пропущена по параметру -F 2 .

В командной строке введите следующие команды и внесите требуемые изменения:

Использование инструкции BULK INSERT и символьного формата Юникода без файла форматирования

Аргумент DATAFILETYPE . Выполните следующий запрос Transact-SQL в Microsoft SQL Server Management Studio (SSMS):

Использование инструкции BULK INSERT и символьного формата Юникода с файлом форматирования, не являющимся XML

Аргумент FORMATFILE . Выполните следующий запрос Transact-SQL в Microsoft SQL Server Management Studio (SSMS):

Использование инструкции OPENROWSET и символьного формата Юникода с файлом форматирования, не являющимся XML

Аргумент FORMATFILE . Выполните следующий запрос Transact-SQL в Microsoft SQL Server Management Studio (SSMS):

При переносе дампа или после нескольких манипуляций в базе неожиданно появились знаки вопросов в MySQL вместо русских букв? Это известная и распространённая проблема в MySQL старших версий.

🟥 Это руководство поможет предпринять быстрые шаги в исправлении ситуации.

Мы рассмотрим конкретные действия для быстрого решения. Обратите внимание на официальное руководство по кодировке в MySQL, чтобы вы смогли разбираться в сути и выполнять рекомендации осознанно.

Исправляем знаки вопросов в MySQL на русские буквы

Воспользуйтесь этими быстрыми рекомендациями, чтобы отобразить русские буквы без знаков вопросов и «крякозябр». Ниже мы привели некоторые уточнения.

Дождитесь выполнения соединения с сервером
Введите запрос:
set names кодировка

«кодировка» — это параметр кодировки, в которой вы выводите данные страницы на сайте.

То есть запрос для UTF-8 должен выглядеть так:
set names utf8

Обратите внимание, что запросы «set names» по факту не влияют на кодировку, которая используется функцией mysql_real_escape_string . Поэтому рекомендуется применять установку кодировки через mysql_set_charset() вместо запроса «set names» . Но даже если вы проигнорируете эту рекомендацию, то для Uta8 и других однобайтных кодировок ничего плохого не последует.

Исправление проблемы кодировки MySQL, если запрос SET NAMES не помог

Перед тем, как изменить кодировку MySQL, вновь выполните запрос «Set Names», но уже с указанием кодировки таблицы (мы должны её выяснить).

Причина кроется в том, что для таблиц настройка в одной кодировке, а данные в них — в другой.
Попробуйте начать с простого решения — того же запроса «Set Names», но в кодировке таблицы.
Для этого задайте запрос для названия вашей таблицы:
show create table `table`
Используйте полученную кодировку в запросе «Set Names»:
SET NAMES кодировка

«кодировка» — это параметр, который показал результат запроса « Show Create Table » из пункта 3 ( DEFAULT CHARSET=кодировка ).
Так вы уберёте «крякозябры» и знаки вопросов из MySQL, настроите правильную отдачу и запись русских букв в данных (главное, чтобы у самой веб-страницы была соответствующая кодировка), но проблему сортировки и поиска пока не решите. Идём дальше.

Теперь, зная кодировку таблицы (например, latin1 ) и имея данные в той же кодировке, мы должны изменить фактическую кодировку данных.

Через mysqldump создайте дамп базы данных.
Используйте эту команду, в которой вместо слова «кодировка» вставьте параметр, выясненный из кодировки таблицы:
mysqldump -uUSERNAME -pPASSWORD DB_NAME --allow-keywords --create-options --complete-insert --default-character-set=кодировка --add-drop-table > dump.sql
Главное не перепутать кодировку таблиц с кодировкой данных.
Проверьте дамп на правильное отображение кодировки уже в формате данных таблицы, а не самой таблицы, как в пункте 3 (то есть уже не l atin1 , а utf8 , например). Скопируйте бэкап дампа отдельно.
В дампе найдите оператор «Create Database» и проверьте, правильная ли в нём кодировка.
Если нет, то исправьте. Тоже самое можно (и лучше сделать) с оператором «Create Table».
Используйте эту команду для заливки дампа, где «кодировка» — параметр данных таблицы ( utf8 , а не latin1 из нашего примера):
mysql -uUSERNAME -pPASSWORD DB_NAME --default-character-set=utf8 < dump.sql
На веб-странице сайта найдите функцию mysql_connect , затем mysql_select_db и ниже их размещения добавьте строчку, где «кодировка» — это параметр данных таблицы, а не самой таблицы:
mysql_query("SET NAMES кодировка")

Ничего не помогает, проблема кодировки MySQL так и осталась

Объёмный wiki-раздел по кодировке MySQL составили белорусские коллеги, где вы можете получить исчерпывающее описание процесса правильного создания баз данных и таблиц. Ведь именно в этом процессе кроются все причины возникновения проблемы со знаками вопросов MySQL и «крякозябрами» вместо русских букв.

Также обратите внимание и на эти моменты при работе с базами данных

правильная ли задана кодировка при создании таблиц (можно использовать любую, но она должна отражать кодировку данных в таблице);
правильная ли кодировка у скрипта, работающего с базой данных (кодировка веб-страницы и скрипта должна быть одной);
правильная ли кодировка у самого сайта (у веб-страницы и заголовка «Content-Type» сайта она должна быть общая);
в правильной ли кодировке сохраняются данные на веб-странице через редактор (выберите в редакторе нужную кодировку, следите за этим).

Не хотите самостоятельно разбираться в настройке MySQL и оптимизировать работу ИТ-инфраструктуры предприятия?

Передайте заботы о программном обеспечении в компанию ИТ-аутсорсинга ZEL-Услуги с полноценным ИТ-аудитом и экспертной поддержкой по любым техническим вопросам и задачам.

Таблица MS Access с русскими полями экспортирована в текстовый файл. Кодировка видимо 1251
После импорта в MySQL с помощью Local Data Infile из текстовых полей с русскими полями выводится абракадабра.
Как можно настроить кодировку MySQL 5.0 ? Или как правильно сделать экспорт из MS Access в другую кодировку?

кодировку явно указать пробовали?

Извините, в MYSQL 5.0 в синтаксисе load data нет character set
кроме этого пробовал сменить кодировку:
set character_set_server=cp1251;
это не помогло

Попробуйте SET NAMES cp1251
и кроме того, убедитесь (SHOW CREATE TABLE имя_таблицы), что таблица создана в cp1251 (или в другой русской кодировке)

к сожалению весь блок команд
SET character_set_client=cp1251; /
Set character_set_server=cp1251;
SET NAMES CP1251
SET COLLATION_CONNECTION=CP1251_GENERAL_CI"
ни к чему не приводит - SHOW CREATE TABLE имя_таблицы - показывает Latin1
И соответственно при импорте с Load data нет русских символов , так же
не может вставить INSERT Into Test VALUES("Дима");

Отредактированно eugira (08.11.2007 16:41:03)

ALTER TABLE имя_таблицы CONVERT TO CHARSET cp1251;

eugira написал:

MySQL 5.0 Reference Manual:

12.2.5 LOAD DATA INFILE Syntax

LOAD DATA [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE 'file_name'
[REPLACE | IGNORE]
INTO TABLE tbl_name
[CHARACTER SET charset_name]
[FIELDS
[TERMINATED BY 'string']
[[OPTIONALLY] ENCLOSED BY 'char']
[ESCAPED BY 'char']
]
[LINES
[STARTING BY 'string']
[TERMINATED BY 'string']
]
[IGNORE number LINES]
[(col_name_or_user_var. )]
[SET col_name = expr. ]

причем там же черным по белому написано:

The character set indicated by the character_set_database system variable is used to interpret the information in the file. SET NAMES and the setting of character_set_client do not affect interpretation of input. Beginning with MySQL 5.0.38, if the contents of the input file use a character set that differs from the default, it is possible (and usually preferable) to use the CHARACTER SET clause to specify the character set of the file.

или может у вас версия таки меньше 5.0.38? Тогда. имхо вам нужно файл перекодировать в нужную кодировку (если совет paulus-а не поможет)

eugira написал:

ни к чему не приводит - SHOW CREATE TABLE имя_таблицы - показывает Latin1

Этот вопрос тут обсуждался уже, но ответа я так и не нашел.

Такой запрос к серверу: select 'русский'
возвращает вопросительные знаки.

При этом в базе есть таблицы с полями varchar, и там хранится нормальный русский текст. и select из этих таблиц тоже возвращает русский текст. таблицы были заполнены с помощью export wizard. Но при добавлении туда новых записей, добавляются вопросительные знаки.

sp_helpsort = Latin1-General, case-insensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data, SQL Server Sort Order 52 on Code Page 1252 for non-Unicode Data

как сделать, чтобы select 'русский' возвращал 'русский'?

Здравствуйте, Аноним, Вы писали:

А>Этот вопрос тут обсуждался уже, но ответа я так и не нашел.

А>Такой запрос к серверу: select 'русский'
А>возвращает вопросительные знаки.

А>При этом в базе есть таблицы с полями varchar, и там хранится нормальный русский текст. и select из этих таблиц тоже возвращает русский текст. таблицы были заполнены с помощью export wizard. Но при добавлении туда новых записей, добавляются вопросительные знаки.

А>sp_helpsort = Latin1-General, case-insensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data, SQL Server Sort Order 52 on Code Page 1252 for non-Unicode Data

А>как сделать, чтобы select 'русский' возвращал 'русский'?

А чего у тебя кодпейдж 1252? и латин-дженерал? Кириллицу поставить не пробовал?

Здравствуйте, Курилка, Вы писали:

К>А чего у тебя кодпейдж 1252? и латин-дженерал? Кириллицу поставить не пробовал?

Я не могу менять настройки сервера. Могу менять только настройки базы.

Ситуация такая, что я могу получить русский текст из таблицы, не смотря на то, что у сервера 1252.
Поэтому я решил, что я могу _вообще_ получить русский.

Вопрос остается
A>>как сделать, чтобы select 'русский' возвращал 'русский'

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Курилка, Вы писали:

К>>А чего у тебя кодпейдж 1252? и латин-дженерал? Кириллицу поставить не пробовал?

А>Я не могу менять настройки сервера. Могу менять только настройки базы.

А>Ситуация такая, что я могу получить русский текст из таблицы, не смотря на то, что у сервера 1252.
А>Поэтому я решил, что я могу _вообще_ получить русский.

А>Вопрос остается
A>>>как сделать, чтобы select 'русский' возвращал 'русский'

Коллейшн прописать-то не пробовал?

Аноним wrote:
> Я не могу менять настройки сервера. Могу менять только настройки базы.
>
> Ситуация такая, что я могу получить русский текст из таблицы, не смотря на то, что у сервера 1252.
> Поэтому я решил, что я могу _вообще_ получить русский.

у отдельных полей могут быть свои кодировки Сменить кодировку БД
можно так:

Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, Курилка, Вы писали:

К>>>А чего у тебя кодпейдж 1252? и латин-дженерал? Кириллицу поставить не пробовал?

А>>Я не могу менять настройки сервера. Могу менять только настройки базы.

А>>Ситуация такая, что я могу получить русский текст из таблицы, не смотря на то, что у сервера 1252.
А>>Поэтому я решил, что я могу _вообще_ получить русский.

А>>Вопрос остается
A>>>>как сделать, чтобы select 'русский' возвращал 'русский'

К>Коллейшн прописать-то не пробовал?

Все равно вопросительные знаки возвращаются((

Или как-то по-другому надо?

У полей в таблицах коллейшн такой же стоит. И из них данные правильно возвращаются.

Здравствуйте, <Аноним>, Вы писали:
А такой:

Уйдемте отсюда, Румата! У вас слишком богатые погреба.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Курилка, Вы писали:

К>>Коллейшн прописать-то не пробовал?

А>Пробовал.
А>
А>Все равно вопросительные знаки возвращаются((

А>Или как-то по-другому надо?

А>У полей в таблицах коллейшн такой же стоит. И из них данные правильно возвращаются.

Дак тебе СУБД для того чтобы данные в ней хранить, или чтобы строчку "русский" получать?

Здравствуйте, Курилка, Вы писали:

А>>Пробовал.
А>>
А>>Все равно вопросительные знаки возвращаются((

А>>Или как-то по-другому надо?

А>>У полей в таблицах коллейшн такой же стоит. И из них данные правильно возвращаются.

К>Дак тебе СУБД для того чтобы данные в ней хранить, или чтобы строчку "русский" получать?

Ну а ты как думаешь?
Если я научусь строчку "русский" получать, то у меня будут правильно все процедуры и проекции работать.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, <Аноним>, Вы писали:
S>А такой:
S>
S>?

Да, спасибо. Видимо, так и придется делать.
Хотел избежать перевода всей базы в юникод. Наверняка есть способ обойтись без этого.
Но раз я его не знаю.

Здравствуйте, <Аноним>, Вы писали:
А>Да, спасибо. Видимо, так и придется делать.
А>Хотел избежать перевода всей базы в юникод. Наверняка есть способ обойтись без этого.
Ок, подсказка номер 2:
что вернется, если в твою табличку данные вставить так:

Уйдемте отсюда, Румата! У вас слишком богатые погреба.

> К>Дак тебе СУБД для того чтобы данные в ней хранить, или чтобы строчку
> "русский" получать?
>
> Ну а ты как думаешь?
> Если я научусь строчку "русский" получать, то у меня будут правильно все
> процедуры и проекции работать.

Всё, что нас не убивает, ещё горько об этом пожалеет.

Здравствуйте, Sinclair, Вы писали:

S>Ок, подсказка номер 2:
S>что вернется, если в твою табличку данные вставить так:
S>
S>?

Она вернет то, что нужно.
Но чтобы это работало, нужно во всех процедурах поменять типы параметров на сервере и на клиенте.
А этого как раз хотелось избежать.

Здравствуйте, <Аноним>, Вы писали:
А>Но чтобы это работало, нужно во всех процедурах поменять типы параметров на сервере и на клиенте.
Ок, подсказка номер 3 (тебе не кажется, что пора немножко и самому поработать, а, дружок?)
что произойдет, если твою любимую процедуру вставки в таблицу вызвать вот так:

Уйдемте отсюда, Румата! У вас слишком богатые погреба.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, <Аноним>, Вы писали:
S>Ок, подсказка номер 3 (тебе не кажется, что пора немножко и самому поработать, а, дружок?)
Я оценил твои педагогические способности, дружок Очень крут. Очень.

Я заменил типы параметров и переменных на сервере на юникод.
Заменил типы параметров на клиенте на юникод.
Подумал (surprise!) и заменил типы данных на сервере на юникод. Гулять так гулять, теперь все в юникоде.

Если ты знаешь способ, как этого можно было избежать, скажи, пожалуйста.

Здравствуйте, <Аноним>, Вы писали:
А>Моя любимая процедура запишет в базу вопросительные знаки.
Sure? Уйдемте отсюда, Румата! У вас слишком богатые погреба.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, <Аноним>, Вы писали:
А>>Моя любимая процедура запишет в базу вопросительные знаки.
S>Sure?

Да Если провести данные через переменную типа varchar, то они портятся.

Здравствуйте, <Аноним>, Вы писали:

А>Да Если провести данные через переменную типа varchar, то они портятся.
А, ну да. Происходит потеря коллейшна. Тебе в принципе было более чем достаточно объявить параметры процедуры либо nvarchar, либо задать им корректный collation. Уйдемте отсюда, Румата! У вас слишком богатые погреба.

А>как сделать, чтобы select 'русский' возвращал 'русский'?

Я, может, немного опоздал к началу тусовки, но хочется задать тупой вопрос — а с помощью чего смотрим результаты? Знаки вопроса вызвали смутые воспоминания — когда-то давно web-клиент тоже их выводил при работе связки "web-сервис + MS SQL". Дело в итоге оказалось "не в бобине" — неправильно работал клиент.

Читайте также: