Какая рекомендуемая реализация для хеширования OLE-вариантов?

Question

Варианты OLE, используемые старшими версиями Visual Basic и широко распространенные в COM Automation, могут хранить множество различных типов: базовые типы, такие как целые и плавающие, более сложные типы, такие как строки и массивы, и вплоть до * 1001.* реализации и указатели в виде ByRef вариантов.

Варианты также слабо типизированы: они преобразуют значение в другой тип без предупреждения в зависимости от того, какой оператор вы применяете и какие текущие типы имеют переданные значенияоператору.Например, сравнение двух вариантов, один из которых содержит целое число 1, а другой содержит строку "1", на равенство вернет True.

Итак, предположим, что я работаю с вариантами на основе данныхуровень (например, VARIANT в C ++ или TVarData в Delphi - т.е. большое объединение различных возможных значений), как я должен последовательно хэшировать варианты, чтобы они подчинялись правильным правилам?

Правила:

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

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

В настоящее время я работаю так, как нормализую варианты строк (если они подходят),и обрабатывать их как строки, в противном случае я работаю с вариантами данных, как если бы это был непрозрачный большой двоичный объект, и хэширую и сравниваю их необработанные байты.Конечно, у этого есть некоторые ограничения: числа 1..10 сортируются как [1, 10, 2, ... 9] и т. Д. Это слегка раздражает, но оно непротиворечиво и очень мало работает.Тем не менее, мне интересно, есть ли принятая практика для этой проблемы.

Answer 1

В вашем вопросе есть встроенная напряженность между использованием хеш-функции и заявленными требованиями, которые должны быть проверены на соответствие вводу хеш-функции. Я бы посоветовал иметь в виду несколько общих свойств хэшей: информация теряется в процессе хэширования, и следует ожидать коллизий хэшей. Можно создать идеальный хеш без коллизий, но было бы проблематично (или невозможно?) Построить идеальную хеш-функцию, если доменом функции является любой возможный вариант OLE. С другой стороны, если мы не говорим о совершенном хэше, то ваше первое правило нарушается.

Я не знаю более широкого контекста того, чего вы пытаетесь достичь, но я должен отбросить одно из ваших предположений: действительно ли вам нужна хеш-функция? Ваши требования могут быть выполнены довольно просто, если вы разработаете систему, которая кодирует, а не хэширует все возможные атрибуты OLE Variant, чтобы их можно было вызывать позже и сравнивать с другими изображениями Variant.

Ваша базовая реализация преобразования Variant в строковое представление движется в этом направлении. Как вы, несомненно, знаете, Variant может содержать указатели, двойные указатели и массивы, поэтому вам придется разработать согласованное строковое представление этих типов данных. Я подвергаю сомнению, мог ли этот подход действительно быть классифицирован как хэш. Разве вы не просто сохраняете атрибуты данных?

Answer 2

Хэш-коды одинаковых ВАРИАНТОВ должны быть равны.

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

Answer 3

Итак, в общем, чтобы сделать материал сравнимым с первым потоком в общем формате, строке или BLOB-объекте.

Как вы справляетесь, например, локализация, например формирование реалов? Реальный по сравнению со строкой, содержащей тот же реальный, созданный в другой локали, потерпит неудачу. Или реальное записанное в строку значение с другой точностью.

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