Macrolinux tiene razón, pero debe tener cuidado con su ejemplo, ya que funcionará pero por accidente.
El primer argumento de BinData() es el subtipo binaria BSON que, como se ha mencionado es uno de los siguientes:
generic: \x00 (0)
function: \x01 (1)
old: \x02 (2)
uuid_old: \x03 (3)
uuid: \x04 (4)
md5: \x05 (5)
user: \x80 (128)
Estos son sólo ayudantes para que el deserializer puede interpretar los datos binarios de manera diferente dependiendo en qué representan esos bytes excepto para el subtipo 2 que es como el subtipo genérico pero almacena un int32 que representa la longitud de la matriz de bytes como los primeros 4 bytes de datos.
ahora para ver por qué el ejemplo es incorrecta se le nota que llamar BinData (2, "1234") no almacena el binario que representa la cadena "1234" por dos razones:
- El BinData función interpreta esa cadena como una cadena codificada en base64.
- El tipo 2 requeriría que los primeros 4 bytes sean un int32 que contenga la longitud de la matriz de bytes.
Consulte bsonspec.org para obtener más información.
Interesante. ¿Se usan esos subtipos para cualquier cosa? – Thilo
Supongo que sí :-). El mejor lugar para preguntar es el grupo BSON. Definitivamente, hay una razón para la diferencia entre el nuevo '\ x00' y el histórico' \ x02' (http://groups.google.com/group/bson/browse_thread/thread/c45f78fba9311975). Para UUID y MD5 (mi opinión) es para la optimización. Ambos son hexadecimales de longitud fija (dígitos hexadecimales de 16 bytes/128 bits, el UUID de diseño diferente tiene '-') y los implementadores de controladores ampliamente utilizados podrían optimizar la lectura/escritura. –
No sé qué podría optimizar un controlador aquí. Todos los tipos binarios se almacenan como 'longitud (int32) subtipo-byte bytes *'. Longitud fija o no, la longitud se almacena. Y los datos se almacenan como bytes sin formato (no hexadecimales). Tal vez una opción para la validación de datos? O para fines de visualización: UUID podría mostrarse mejor que 'BinData (3, ........)'? – Thilo