Как правильнее получить уникальный хеш длиной в 16 символов из уникального идентификатора 1с? Необходимо для интеграции. Есть скрипты для кодирования по алгоритму они возвращают хеш в 32 символа, есть что-нибудь похожее для хеша в 16 символов. И на сколько правильно будет брать первые 16 символов от 1с-ного идентификатора?

берите не первые, а случайные 16

Я для штрихкода CODE128 до 20 ужимал. Про 16 не слышал.

(0) Бери первые 16 из хеша для "кодирования по алгоритму". Либо сложи посимвольно две половины.
Первые 16 символов от УИД тоже как хэш должны пойти. Посчитать хэш для журнала документов, сгруппировать и посмотреть разброс совпадений.

И да, из УИДа логично брать только символы - без скобок и дефисов.

Неправильно. Вообще Хэш это либо байтовый масив либо uint или UInt64
Можно проиксорить 2 части либо например взять пример вычисления хэша для строки

public override unsafe int GetHashCode()
{
    if (HashHelpers.s_UseRandomizedStringHashing)
    {
        return InternalMarvin32HashString(this, this.Length, 0L);
    }
    fixed (char* str = ((char*) this))
    {
        char* chPtr = str;
        int num = 0x15051505;
        int num2 = num;
        int* numPtr = (int*) chPtr;
        int length = this.Length;
        while (length > 2)
        {
            num = (((num << 5) + num) + (num >> 0x1b)) ^ numPtr[0];
            num2 = (((num2 << 5) + num2) + (num2 >> 0x1b)) ^ numPtr[1];
            numPtr += 2;
            length -= 4;
        }
        if (length > 0)
        {
            num = (((num << 5) + num) + (num >> 0x1b)) ^ numPtr[0];
        }
        return (num + (num2 * 0x5d588b65));
    }
}

(0) "они возвращают хеш в 32 символа" - может я чего-то не понял, но изначально УИД в 1С как раз - 32 символа.

(5) Ммм.. Что неправильного увидел?)
Хешем может быть почти всё, что на ум придёт. Один символ, одна цифра и т.д.

(6) УИД - не очень под хеш подходит, т.к. он уникальный)
Но тут уже лучше автора спросить, зачем ему понадобился хеш как таковой)

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

Или wiki:Hash?previous=yes
Хеширование (иногда «хэширование», англ. hashing) — преобразование по детерминированному алгоритму входного массива данных произвольной длины в выходную битовую строку фиксированной длины. Такие преобразования также называются хеш-функциями или функциями свёртки, а их результаты называют хешем, хеш-кодом или сводкой сообщения (англ. message digest).


Хорошая хеш-функция должна удовлетворять двум свойствам:
быстро вычисляться;
минимизировать количество коллизий


УИД неуникален. Есть вероятность коллизий.
А так ему видно хочется уменьшить разрядность хэша

Что-то мне кажется, что если символ - это байт, то 16 байт - это и есть GUID.

(7) Для интеграции доков, у получающей стороны ID = 16 символов

Заведи справочник УИДов.
Код справочника будет хешем.

(0)Прислушайся к (11) это самый лучший вариант.

(11), (12) Ну так-то да, решение вроде хорошее

В какие-то крайности вас понесло! Все давно придумано:http://www.sql.ru/forum/349486-2/podskazhite-algoritm-szhatiya-stroki-teksta

(8) УИД неуникален? Как так получилось? Разве он не на то и УИД, что уникальный?)

(8) И ты так и не ответил на вопрос, что неправильного в (5) увидел. Либо я не заметил ответа)

>минимизировать количество коллизий
Нет же)

wiki:GUID
Хотя уникальность каждого отдельного GUID не гарантируется, общее количество уникальных ключей настолько велико (2128 или 3,4028?1038), что вероятность того, что в мире будут независимо сгенерированы два совпадающих ключа, крайне мала.

В 1С с их генерацией УИД вероятность больше

(16) Неправильно брать первые 16 символов. Нужно брать все 32 хэшировать их в 12 байт и переводить в Base64. Вот так будет правильно. Тогда вероятность коллизий резко уменьшится.
Но для его задачи лучше всего 11