Macrolinux ha ragione ma bisogna stare attenti con il suo esempio in quanto funzionerà, ma per caso.
Il primo argomento BinData() è il BSON sottotipo binario che, come si è detto è uno dei seguenti:
generic: \x00 (0)
function: \x01 (1)
old: \x02 (2)
uuid_old: \x03 (3)
uuid: \x04 (4)
md5: \x05 (5)
user: \x80 (128)
Questi sono solo helper in modo che il deserializzatore grado di interpretare i dati binari in modo diverso a seconda su ciò che questi byte rappresentano eccetto per il sottotipo 2 che è simile al sottotipo generico ma memorizza un int32 che rappresenta la lunghezza della matrice di byte come i primi 4 byte di dati.
ora a vedere il motivo per cui l'esempio è sbagliato noterete che chiama BinData (2, "1234") non memorizza il binario che rappresenta la stringa "1234" per due motivi:
- Il BinData la funzione interpreta quella stringa come una stringa codificata in base64.
- Il tipo 2 richiede che i primi 4 byte siano un int32 contenente la lunghezza della matrice di byte.
Vedere bsonspec.org per ulteriori informazioni.
fonte
2013-04-03 17:33:00
Interessante. Questi sottotipi sono usati per qualcosa? – Thilo
Credo di sì :-). Il posto migliore per chiedere è il gruppo BSON. Sicuramente, c'è una ragione per la differenza tra il nuovo '\ x00' e lo storico' \ x02' (http://groups.google.com/group/bson/browse_thread/thread/c45f78fba9311975). Per UUID e MD5 (la mia opinione) è per l'ottimizzazione. Entrambi sono esadecimali di lunghezza fissa (cifre esadecimali a 16 byte/128 bit/32, UUID di layout diverso ha '-') e ampiamente utilizzati, gli implementatori di driver potrebbero ottimizzare la lettura/scrittura. –
Non so cosa un pilota possa ottimizzare qui. Tutti i tipi binari sono memorizzati come 'length (int32) subtype-byte byte *'. Lunghezza fissa o no, la lunghezza è memorizzata. E i dati vengono memorizzati come byte non elaborati (non esadecimali). Forse un'opzione per la convalida dei dati? O per scopi di visualizzazione: UUID potrebbe essere visualizzato più bello di 'BinData (3, ........)'? – Thilo