Народ, кто-нибудь сталкивался с подобным?

Есть ТЗ с одной колонкой, строковой, типизированной. Выполняю по ней Свернуть() и, в некоторых случаях, после свертки в ней остаюся строки с одинаковыми значениями!
Значения реально одинаковые, не похожие буквы в разных раскладках -- я потом по этой таблице бытаюсь регистр сведений заполнить, и получаю отлуп по причине неуникального ключа.

Как такое возможно?

Пробелы в конце. Ваш К.О.

(0)  пробелы в конце строк

(1)(2) Нет. Проверено.

(3) показывай код, результат

Хммм, это не пробел, но какой-то непечатный символ. Потому, что СтрДлина у этих значений разная. Даже после СокрЛП разная.

Но тогда вопрос, как с этим бороться?

Фублин, Дима...
Такие вопросы от тебя...

(7) Ну вот если такой умный, скажи как избежать подобных граблей?

(8) Навести порядок в данных, удалить непечатные символы

Запретить на фиг копирование из интернета наименований и подобной требухи. Я на оболеввшем. А так да, проще найти эти символы вариантов от вывести в отдельной колонке до хекс-редактора.

(8) Выяснить, какие символы там есть, откуда они появляются. Уничтожить причину. В существующих данных провести люстрацию.

(9) Как? В юникоде этих символов как у дурака фантиков.

(12) КодСимвола() на что нам свыше дан?

Даже вспомнил, в свое время пришлось вырезать символ "09".

(11) Данные из внешнего источника приходят.

(13) Ну вот в данном конкретном случае он показывает 8237. И что мне с этой инфой делать?

Вопрос в том, какого хрена вообще 1С неодинаковые строки считает одинаковыми.

(17) сам же в (0) сказал, что 1с их считает неодинаковыми.

(16) СтрЗаменить(строка, Символ(8237), "")
(17) Кто тебе сказал такое? В (0) у тебя обратная ситуация

(17) Что делать? Кто виноват? Доколе?

(18) Это скуль их считает неодинаковыми. Ибо проверку на уникальность ключа он делает.

(19) А если в другой записи будет Символ(8236)? Или Символ(8235)? Или ещё один из овердохера непечатных символов?

(21) Ну, тогда придется тебе что-то сделать.

Format characters
202A  LEFT-TO-RIGHT EMBEDDING
• commonly abbreviated LRE
202B  RIGHT-TO-LEFT EMBEDDING
• commonly abbreviated RLE
202C  POP DIRECTIONAL FORMATTING
• commonly abbreviated PDF
202D  LEFT-TO-RIGHT OVERRIDE
• commonly abbreviated LRO
202E  RIGHT-TO-LEFT OVERRIDE
• commonly abbreviated RLO

Видимо не умеет СокрЛП такие символы обрезать

(21) Тьфу, точнее наоборот. Для 1С они разные, а для скуля одинаковые.

В общем, решение: ЗаменитьНедопустимыеСимволыXML() из БСП.

(25) ставлю лайк

(21) Проверяй на вхождение в диапазон допустимых символов

(27) Допустимых тоже какбэ оердохера.

значит - некорректная работа программиста 1с, а не метода Свернуть()

(5) кто бы сомневался в корявости рук.

(25) А, нет, нихрена. Эта функция такие символы не убирает.
Заррраза!

(30) Есть предложения, как решить?

(31) Перебери "перечисление" Символы:
ВК (CR)
ВТаб (VTab)
НПП (NBSp)
ПС (LF)
ПФ (FF)
Таб (Tab)

99% что ничего больше у тебя не будет.

А если останется - берёшь конкретные кривые строки и вырезаешь оттуда кривые символы на замену

(32) Перевести в ANSI, отфильтровать (это проще, ведь там всего 256 символов останется), перевести обратно в UTF ?

(33) Смотри (16)

(34) Не пойдет, нужен юникод. Данные могут быть на языках, использующих не только кириллицу и простую латиницу.

(35) Ну что делать с конкретным символом ты знаешь.
Универсального рецепта с учетом (36) не будет. В любом случае тебе нужен либо "чёрный" список символов, либо "белый" (тут проблема в (36))

(36) Ну так засучивай рукава и пиши свой RTrim - по классам уникодных символов и т.п.

Не, есть, конечно одно напрашивающееся решение -- свернуть запрососм. Но оно мне не нравится :(

(39) или поменять  collatoin

Юникод зло, во многих случаях - необходимое.. Но вот для кириллицы он нафиг не нужен, ИМХО, и без него отлично можно было обойтись классическими 8битными кодовыми страницами рус-лат. Проблема была в зоопарке этих кодовых страниц.. и юникод как бы решил эту проблему, но при этом создал новые.

(40) Ну, это такое ... Сейчас поменяют, а потом админ базу на другой сервак перенесет с настройками по умолчанию, и задолбаются проблему искать.

(41) Мир не ограничивается зоной ru. Только кириллицы сушествует больше десятка вариантов, а ещё есть расширенная латиница, а ещё есть другие алфавиты, а ещё есть вообще не алфавиты.

(41) Проблема тут не в юникоде, а в том, что 1С и MSSQL на котором работает 1С, по-разному сравнивают строки.

(43) Ты еще про регистрозависимость вспомни

(42) "Только кириллицы сушествует больше десятка вариантов, а ещё есть расширенная латиница"
Часто ли 99,9% пользователей требуется редактировать текст, где русский вперемешку с болгарским? Думаю, крайне редко. Да и в этом случае есть решения. Помню, на УКНЦ была технология переключения кодовых страниц КОИ-7 с помощью управляющих символов, позволяющего хранить в файле и выводить на консоль многоязычный текст. Это технология, придуманная айтишниками для айтишников. А юникод придумывался для гламурных юзеров, ценой дикого оверхеда при хранении национальных символов и при этом с кучей недостаточно документированных нюансов, которые используются кем попало как попало...