Почему завершающий байт 0x00 после строки BSON (не Cstring / ename)?

Question

очевидно, что для bson cstring последний байт используется для определения длины строки, поэтому он равен: (byte*) "\x00". Они используются в качестве шаблонов регулярных выражений, параметров rexegs и ename, которые не являются длинными / используются в итерациях, поэтому длина не обязательна, но потом приходит ...

Строка bson записывается как: int32 (byte*) "\x00"

со спецификацией следующим образом: The int32 is the number bytes in the (byte*) + 1 (for the trailing '\x00'). The (byte*) is zero or more UTF-8 encoded characters.

но зачем использовать завершающий нулевой байт? если у нас есть длина строки в кодировке utf-8, этого достаточно для рабочего процесса байтовых данных, а байт 0x00 просто добавляет ненужный байт. Я что-то упустил?

Answer 1

Обоснование как длины строки, так и нулевого терминатора двояко: совместимость с существующими строками в стиле C и производительность.

Для производительности MongoDB должна иметь возможность быстро перейти к определеннойполе в документе без итерации по всему BSON. Это особенно важно, если вы ищете поле, близкое к концу большого (скажем, 16 МБ) документа. С длиной строки, закодированной как одна из первых сведений о типе строки, он может просто пропустить это количество байтов и перейти к следующему полю. В противном случае, он должен будет перебирать всю строку, пока не найдет конец строки.

Для совместимости MongoDB написан на C ++, где строки заканчиваются нулями . Он может обрезать этот нулевой терминатор, чтобы сохранить один байт, поскольку длина закодирована, но для переноса этой строки из BSON в формат, пригодный для использования в C ++, потребовалось бы снова нажать на этот ноль. Для этого потребуется специальная процедура обработки строк, единственным преимуществом которой является сохранение одного байта.

В целом было решено, что «потеря» одного байта является приемлемым компромиссом.