Error on line 1 at column 39 unsupported encoding unicode

Обмен заказами

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

ПерваяСтрока = времТекст.ПолучитьСтроку(1);
Если СокрЛП(ПерваяСтрока) = «» Тогда
времТекст.УдалитьСтроку(1);
ОтветСервера = времТекст.ПолучитьТекст();
КонецЕсли;

Тоесть если первая строка пустая то просто удаляю ее из полученного ответа

Ну или может проще проканает (не пробовал): Вместо этого куска просто написать ОтветСервера = СокрЛП(ОтветСервера)

Но причину наверное стоит искать на стороне сайта. И разобраться почему он возвращает файл неправильного (не совсем правильного)) формата

Так как проблема то решается?? чо то я так и не понял)))))

так Для того, чтобы старый обмен заработал — нужно выполнить два скрипта php:

COption::SetOptionString(«catalog», «DEFAULT_SKIP_SOURCE_CHECK», «Y» );
COption::SetOptionString(«sale», «secure_1c_exchange», «N» );

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

В коде процедуры обмена (ЗагрузитьДокументыССайта) идет проверка на первую строку из этого файла:

Если Лев(ОтветСервера, 2) = «PK» Тогда
СтрокаCML = РаспаковатьZIPАрхив(ОтветСервера);
Иначе
Если Лев(ОтветСервера, 5) = »
СтрокаCML = ОтветСервера;
КонецЕсли;
КонецЕсли;

Нас интересует это условие:

Если Лев(ОтветСервера, 5) = »
СтрокаCML = ОтветСервера;
КонецЕсли;

И так как у нас первой строкой в ответе сервера идет пустая строка — получается 1с считает что грузить ему нечего из этого файла
Решил проблему куском простого кода:

времТекст = Новый ТекстовыйДокумент;
времТекст.УстановитьТекст(ОтветСервера);
Если времТекст.КоличествоСтрок() > 0 Тогда

ПерваяСтрока = времТекст.ПолучитьСтроку(1);
Если СокрЛП(ПерваяСтрока) = «» Тогда
времТекст.УдалитьСтроку(1);
ОтветСервера = времТекст.ПолучитьТекст();
КонецЕсли;

Тоесть если первая строка пустая то просто удаляю ее из полученного ответа

Ну или может проще проканает (не пробовал): Вместо этого куска просто написать ОтветСервера = СокрЛП(ОтветСервера)

Но причину наверное стоит искать на стороне сайта. И разобраться почему он возвращает файл неправильного (не совсем правильного)) формата

Источник

Устранение ошибки «Недопустимое смешение коллажей» в mysql

Получаем ошибку ниже при попытке выполнить выбор в хранимой процедуре в MySQL.

Нелегальное сочетание сортировок (latin1_general_cs, IMPLICIT) и (latin1_general_ci, IMPLICIT) для операции ‘=’

Любая идея о том, что здесь может быть неправильным?

Сравнение таблицы latin1_general_ci , а столбца в предложении where — latin1_general_cs .

ОТВЕТЫ

Ответ 1

Как правило, это вызвано сравнением двух строк несовместимого сопоставления или попыткой выделить данные другого сопоставления в объединенный столбец.

Предложение COLLATE позволяет указать параметры сортировки, используемые в запросе.

Например, следующее предложение WHERE всегда будет содержать сообщение об ошибке, которую вы опубликовали:

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

Другой вариант — использовать оператор BINARY :

BINARY str — сокращение от CAST (st как AS BINARY).

Ваше решение может выглядеть примерно так:

Ответ 2

TL; DR

Либо измените сопоставление одного (или обоих) строк так, чтобы они соответствовали, либо добавили в выражение выражение COLLATE .

Что это за «сортировка» в любом случае?

A набор символов представляет собой набор символов и кодировок. сопоставление — это набор правил для сравнения символов в наборе символов. Позвольте сделать различие понятным на примере мнимого набора символов.

Предположим, что у нас есть алфавит с четырьмя буквами: » A » , » B » , » A » , » B » . Мы даем каждой букве число: » A » = 0, » B » = 1, » A » = 2, » B » = 3. Буква » A » является символом, число 0 является кодировкой для » A » , а комбинация всех четырех букв и их кодировок — это набор символов .

Предположим, что мы хотим сравнить два строковых значения: » A » и » B » . Самый простой способ сделать это — посмотреть кодировки: 0 для » A » и 1 для » B » . Поскольку 0 меньше 1, мы говорим: » A » меньше » B » . Мы только что применили сопоставление с нашим набором символов. Сопоставление — это набор правил (только одно правило в этом случае): «сравнить кодировки». Мы называем это простейшее из всех возможных сопоставлений двоичным сопоставлением.

Но что, если мы хотим сказать, что строчные и прописные буквы эквивалентны? Тогда у нас будет по крайней мере два правила: (1) обрабатывать строчные буквы » A » и » B » как эквивалентные » A » и » B » ; (2), затем сравните кодировки. Мы называем это нечувствительным к регистру сопоставлением. Это немного сложнее, чем двоичная сортировка.

В реальной жизни большинство наборов символов имеют много символов: не только » A » и » B » , но целые алфавиты, иногда несколько алфавитов или восточные системы письма с тысячами символов, а также множество специальных символов и знаков препинания Метки. Кроме того, в реальной жизни большинство коллайлов имеют много правил, а не только для того, чтобы различать буквенный регистр, но также и для того, чтобы отличить акценты ( «акцент» — это знак, прикрепленный к персонажу, как на немецком языке » Ö » ), и для многосимвольные сопоставления (например, правило » Ö » = » OE » в одном из двух германских сопоставлений).

Хорошо, но как MySQL решает, какое сопоставление использовать для данного выражения?

В подавляющем большинстве утверждений очевидно, что используется MySQL для сопоставления операции сравнения. Например, в следующих случаях должно быть ясно, что сортировка — это сортировка столбца charset_name :

Однако с несколькими операндами может быть неоднозначность. Например:

Если сравнение использует сортировку столбца x или строкового литерала ‘Y’ ? Оба x и ‘Y’ имеют сопоставления, так что сопоставление имеет приоритет?

Стандартный SQL разрешает такие вопросы, используя то, что раньше называлось правилами «принуждаемости».

MySQL использует значения коэрцитивности со следующими правилами для устранения неоднозначностей:

Используйте сопоставление с наименьшим значением принуждения.

Если обе стороны имеют одну и ту же коэрцитивность, то:

Если обе стороны являются Unicode или обе стороны не являются Unicode, это ошибка.

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

Он возвращает результат, имеющий набор символов utf8 и ту же сортировку, что и utf8_column . Значения latin1_column автоматически преобразуются в utf8 перед конкатенацией.

Для операции с операндами из того же набора символов, но которые смешивают сортировку _bin и a _ci или _cs , используется сортировка _bin . Это похоже на то, как операции, в которых смешиваются недвоичные и двоичные строки, оценивают операнды как двоичные строки, за исключением того, что они предназначены для сопоставлений, а не для типов данных.

Итак, что такое «незаконное сочетание сортировок»?

«Неправильное сочетание сопоставлений» возникает, когда выражение сравнивает две строки разных сопоставлений, но имеет равную совместимость, а правила принуждения не могут помочь разрешить конфликт. Эта ситуация описана в третьей цитате в приведенной выше цитате.

Конкретная ошибка, заданная в вопросе Illegal mix of collations (latin1_general_cs,IMPLICIT) and (latin1_general_ci,IMPLICIT) for operation ‘=’ , говорит нам о том, что было проведено сравнение равенства между двумя строками, не относящимися к Unicode, с равной совместимостью. Кроме того, он говорит нам, что сопоставления не были указаны явно в заявлении, а скорее подразумевались из источников строк (например, метаданных столбца).

Все это очень хорошо, но как решить такие ошибки?

Как показывают приведенные выше выдержки из руководства, эта проблема может быть решена несколькими способами, из которых два являются разумными и рекомендуемыми:

Измените сортировку одной (или обеих) строк так, чтобы они совпадали, и больше не существует двусмысленности.

Как это можно сделать, зависит от того, откуда пришла строка: Литеральные выражения принимают сопоставление, указанное в системной переменной collation_connection ; значения из таблиц берут сопоставление, указанное в их метаданных столбцов.

Настроить одну строку, чтобы она не была принудительной.

Я пропустил следующую цитату из вышеперечисленного:

MySQL присваивает значения коэрцитивности следующим образом:

Явное предложение COLLATE обладает способностью к нулю (не является коэрцитивной).

Конкатенация двух строк с разными сопоставлениями имеет коэрцитивность 1.

Сопоставление столбца или параметра хранимой процедуры или локальной переменной имеет совместимость с 2.

«Системная константа» (строка, возвращаемая такими функциями, как USER() или VERSION() ) обладает способностью 3.

Сопоставление литерала имеет коэрцитивность 4.

NULL или выражение, полученное из NULL , имеет коэрцитивность 5.

Таким образом, просто добавление предложения COLLATE в одну из строк, используемых при сравнении, заставит использовать эту сортировку.

В то время как другие были бы ужасно плохой практикой, если бы они были развернуты только для устранения этой ошибки:

Принудите одну (или обе) строки к некоторым другим значениям коэрцитивности, чтобы иметь преимущество.

Использование CONCAT() или CONCAT_WS() приведет к тому, что строка с способностью 1; и (если в хранимой процедуре) использование параметров/локальных переменных приведет к строкам с способностью 2.

Измените кодировку одной (или обеих) строк так, чтобы она была Unicode, а другая — не.

Это можно сделать путем перекодирования с помощью CONVERT(expr USING transcoding_name) ; или путем изменения базового набора символов (например, изменение столбца, изменение character_set_connection для литеральных значений или отправка их с клиента в другую кодировку и изменение character_set_client /добавление средства ввода символов). Обратите внимание, что изменение кодировки приведет к другим проблемам, если некоторые желаемые символы не могут быть закодированы в новом наборе символов.

Измените кодировки одной (или обеих) строк так, чтобы они были одинаковыми и изменили одну строку, чтобы использовать соответствующую сортировку _bin .

Методы изменения кодировок и сопоставлений были подробно описаны выше. Этот подход был бы малопригодным, если бы на самом деле требовалось применять более сложные правила сопоставления, чем предлагалось с помощью сортировки _bin .

Ответ 3

Добавление моего 2c к обсуждению будущих googlers.

Я изучал аналогичную проблему, когда я получил следующую ошибку при использовании пользовательских функций, которые получили параметр varchar:

Используя следующий запрос:

Я смог сказать, что БД использовала utf8_general_ci, а таблицы были определены с помощью utf8_unicode_ci:

Обратите внимание, что представления имеют NULL-сопоставление. Похоже, что представления и функции имеют определения сортировки, хотя этот запрос показывает null для одного представления. Используемая сортировка — это сортировка БД, которая была определена при создании представления/функции.

Печальное решение заключалось в том, чтобы изменить сортировку db и воссоздать представления/функции, чтобы заставить их использовать текущую сортировку.

Изменение сортировки db:

Надеюсь, это поможет кому-то.

Ответ 4

Иногда бывает сложно конвертировать кодировки, особенно в базы данных с огромным количеством данных. Я думаю, что лучший вариант — использовать «двоичный» оператор:

Ответ 5

У меня была аналогичная проблема, я пытался использовать процедуру FIND_IN_SET со строкой переменной.

и получал ошибку

Код ошибки: 1267. Недопустимое сочетание сортировок (utf8_unicode_ci, IMPLICIT) и (utf8_general_ci, IMPLICIT) для операции «find_in_set»

Короткий ответ:

Не нужно менять переменные collation_YYYY, просто добавьте правильную сортировку рядом с объявлением переменной, т.е.

Длинный ответ:

Сначала я проверил переменные сортировки:

Затем я проверил сортировку таблицы:

Это означает, что моя переменная была настроена со значением по умолчанию utf8_general_ci, тогда как моя таблица была настроена как utf8_unicode_ci.

Добавив команду COLLATE рядом с объявлением переменной, сопоставление переменных соответствовало настройке сопоставления для таблицы.

Ответ 6

Вы можете попробовать этот script, который преобразует все ваши базы данных и таблицы в utf8.

Ответ 7

Решение, если речь идет о литералах.

Я использую интеграцию данных Pentaho и не могу указать синтаксис sql. Использование очень простого поиска в БД дало ошибку Msgstr «Недействительное сочетание сортировок (cp850_general_ci, COERCIBLE) и (latin1_swedish_ci, COERCIBLE) для операции ‘=’»

Сгенерированный код был «SELECT DATA_DATE AS last_DATA_DATE FROM hr_cc_normalised_data_date_v WHERE PSEUDO_KEY =?»

Сокращение истории сократило поиск до представления, и когда я выпустил

который объясняет, откуда берется «cp850_general_ci».

Вид был просто создан с помощью ‘SELECT’ X ‘. ‘ В соответствии с такими литералами, как это, следует наследовать их набор символов и сортировку из настроек сервера, которые были правильно определены как «latin1» и «latin1_general_cs», так как этого явно не случилось, я заставил его создать вид

теперь он показывает latin1_general_cs для обоих столбцов, и ошибка исчезла.:)

Ответ 8

MySQL действительно не любит смешивать сортировки, если только он не может принудить их к одному (что явно не возможно в вашем случае). Не можете ли вы просто заставить ту же сортировку использовать предложение COLLATE? (или более простой BINARY ярлык, если применимо. ).

Ответ 9

Если столбцы, с которыми у вас возникают проблемы, являются «хэшами», тогда рассмотрим следующее.

Если «хэш» является двоичной строкой, вы действительно должны использовать тип данных BINARY(. ) .

Если «хеш» — это шестнадцатеричная строка, вам не нужно utf8, и этого следует избегать из-за проверки символов и т.д. Например, MySQL MD5(. ) дает 32-байтовую строку с фиксированной длиной. SHA1(. ) дает 40-байтовую шестую строку. Это можно сохранить в CHAR(32) CHARACTER SET ascii (или 40 для sha1).

Или, еще лучше, сохраните UNHEX(MD5(. )) в BINARY(16) . Это уменьшает половину размера столбца. (Тем не менее, это делает его непечатаемым.) SELECT HEX(hash) . , если вы хотите, чтобы он был читабельным.

Сравнение двух столбцов BINARY не имеет проблем с сортировкой.

Ответ 10

Ответ 11

Другим источником проблемы с сопоставлениями является таблица mysql.proc . Проверьте сортировки ваших процедур хранения и функций:

Также обратите внимание на столбцы mysql.proc.collation_connection и mysql.proc.character_set_client .

Ответ 12

Если у вас установлен phpMyAdmin, вы можете следовать инструкциям, приведенным в следующей ссылке: https://mediatemple.net/community/products/dv/204403914/default-mysql-character-set-and-collation Необходимо сопоставить сопоставление базы данных с сопоставлением всех таблиц, а также полей таблиц, а затем перекомпилировать все сохраненные данные. процедуры и функции. С этим все должно работать снова.

Ответ 13

Я использовал ALTER DATABASE mydb DEFAULT COLLATE utf8_unicode_ci; , но не работал.

Эта работа для меня:

Да, только concat .

Ответ 14

Этот код необходимо поместить внутри Запустить SQL-запрос/запросы в базе данных

Пожалуйста, замените имя_таблицы и имя_столбца соответствующим именем.

Источник

Автор	Добавил
Dru
Сообщений: 101	При открытии страницы plugins/rss_menu/rss.php? news.2 ошибка: This page contains the following errors: error on line 1 at column 38: Unsupported encoding utf-8 error on line 1 at column 38: Encoding error Below is a rendering of the page up to the first error. Вот перевод: Эта страница содержит следующие ошибки: ошибка в строке 1 в графе 38: не поддерживаемые кодировки utf-8 ошибка в строке 1 в графе 38: Кодирование ошибка Ниже приводится рендеринга страницы до первой ошибки. Только не пойму в каков файле нужно исправить ошибку? rss.php — там все нормально.
	Популярность сообщения: 1
Рекламный блок
Наверх
Predator
Сообщений: 4057	Версия движка какая? И, когда ж вы научитесь давать полную информацию, а то у меня не работает… Что не работает, где не работает… Я не матерюсь, а всего лишь употребляю ненормативную лексику в целях более полного и лаконичного выражения своих эмоций.
	Популярность сообщения: 1
Dru
Сообщений: 101	Predator: Была 1.0 Full Release, обновился до 0.7.26 Full Build 5.0 No Prefix
	Популярность сообщения: 0
IvanoV
Сообщений: 5	У меня схожая проблема. Был сайт 0.7.26 с кодировкой win1251, скачал здесь 0.7.26 Full Build 5.0 No Prefix, изменил везде (наверное) кодировку на win1251, но в rss вот такая ошибка: This page contains the following errors: error on line 1 at column 38: Unsupported encoding win—1251 error on line 1 at column 38: Encoding error Below is a rendering of the page up to the first error. Еще в админ панели вот так: + Показать Как убрать эти кракозябры?
	Популярность сообщения: 0
Dru
Сообщений: 101	Разобрался! IvanoV: Для решения твоей проблемы измени кодировку файла files/shortcode/ admin_siteinfo.sc на win-1251 А, чтобы решить твою вторую проблему смотри languages/Russian/Russian.php или замени его с предыдущей твоей локализации.
	Популярность сообщения: 3
Predator
Сообщений: 4057	Все последние версии движка, работают с кодировкой utf-8, зачем же вы ему пытаетесь подсунуть 1251 PS: Еще наверно и БД создаете в такой же мелкомягковской кодировке! Я не матерюсь, а всего лишь употребляю ненормативную лексику в целях более полного и лаконичного выражения своих эмоций.
	Популярность сообщения: 1
IvanoV
Сообщений: 5	pokuziev: спасибо, помог! Predator: Я только за utf-8, но сайт был создан изначально на win-1251, и перевести сейчас базу не получается. Из-за этого приходится новые версии переводить из utf-8 в win-1251……..
	Популярность сообщения: 1
Predator
Сообщений: 4057	Сообщение от IvanoV…  Predator: перевести сейчас базу не получается Да ну Значит не умеешь ты этого делать, перевести можно из любой кодировки, в любую другую Я не матерюсь, а всего лишь употребляю ненормативную лексику в целях более полного и лаконичного выражения своих эмоций.
	Популярность сообщения: 2