ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/CBOR-XS/XS.pm
(Generate patch)

Comparing CBOR-XS/XS.pm (file contents):
Revision 1.5 by root, Sat Oct 26 23:02:55 2013 UTC vs.
Revision 1.68 by root, Wed Jul 17 09:37:16 2019 UTC

12 $perl_value = decode_cbor $binary_cbor_data; 12 $perl_value = decode_cbor $binary_cbor_data;
13 13
14 # OO-interface 14 # OO-interface
15 15
16 $coder = CBOR::XS->new; 16 $coder = CBOR::XS->new;
17 #TODO 17 $binary_cbor_data = $coder->encode ($perl_value);
18 $perl_value = $coder->decode ($binary_cbor_data);
19
20 # prefix decoding
21
22 my $many_cbor_strings = ...;
23 while (length $many_cbor_strings) {
24 my ($data, $length) = $cbor->decode_prefix ($many_cbor_strings);
25 # data was decoded
26 substr $many_cbor_strings, 0, $length, ""; # remove decoded cbor string
27 }
18 28
19=head1 DESCRIPTION 29=head1 DESCRIPTION
20
21WARNING! THIS IS A PRE-ALPHA RELEASE! IT WILL CRASH, CORRUPT YOUR DATA
22AND EAT YOUR CHILDREN! (Actually, apart from being untested and a bit
23feature-limited, it might already be useful).
24 30
25This module converts Perl data structures to the Concise Binary Object 31This module converts Perl data structures to the Concise Binary Object
26Representation (CBOR) and vice versa. CBOR is a fast binary serialisation 32Representation (CBOR) and vice versa. CBOR is a fast binary serialisation
27format that aims to use a superset of the JSON data model, i.e. when you 33format that aims to use an (almost) superset of the JSON data model, i.e.
28can represent something in JSON, you should be able to represent it in 34when you can represent something useful in JSON, you should be able to
29CBOR. 35represent it in CBOR.
30 36
31This makes it a faster and more compact binary alternative to JSON. 37In short, CBOR is a faster and quite compact binary alternative to JSON,
38with the added ability of supporting serialisation of Perl objects. (JSON
39often compresses better than CBOR though, so if you plan to compress the
40data later and speed is less important you might want to compare both
41formats first).
32 42
33The primary goal of this module is to be I<correct> and the secondary goal 43The primary goal of this module is to be I<correct> and the secondary goal
34is to be I<fast>. To reach the latter goal it was written in C. 44is to be I<fast>. To reach the latter goal it was written in C.
35 45
46To give you a general idea about speed, with texts in the megabyte range,
47C<CBOR::XS> usually encodes roughly twice as fast as L<Storable> or
48L<JSON::XS> and decodes about 15%-30% faster than those. The shorter the
49data, the worse L<Storable> performs in comparison.
50
51Regarding compactness, C<CBOR::XS>-encoded data structures are usually
52about 20% smaller than the same data encoded as (compact) JSON or
53L<Storable>.
54
55In addition to the core CBOR data format, this module implements a
56number of extensions, to support cyclic and shared data structures
57(see C<allow_sharing> and C<allow_cycles>), string deduplication (see
58C<pack_strings>) and scalar references (always enabled).
59
36See MAPPING, below, on how CBOR::XS maps perl values to CBOR values and 60See MAPPING, below, on how CBOR::XS maps perl values to CBOR values and
37vice versa. 61vice versa.
38 62
39=cut 63=cut
40 64
41package CBOR::XS; 65package CBOR::XS;
42 66
43use common::sense; 67use common::sense;
44 68
45our $VERSION = 0.03; 69our $VERSION = 1.71;
46our @ISA = qw(Exporter); 70our @ISA = qw(Exporter);
47 71
48our @EXPORT = qw(encode_cbor decode_cbor); 72our @EXPORT = qw(encode_cbor decode_cbor);
49 73
50use Exporter; 74use Exporter;
51use XSLoader; 75use XSLoader;
52 76
77use Types::Serialiser;
78
53our $MAGIC = "\xd9\xd9\xf7"; 79our $MAGIC = "\xd9\xd9\xf7";
54 80
55=head1 FUNCTIONAL INTERFACE 81=head1 FUNCTIONAL INTERFACE
56 82
57The following convenience methods are provided by this module. They are 83The following convenience methods are provided by this module. They are
85strings. All boolean flags described below are by default I<disabled>. 111strings. All boolean flags described below are by default I<disabled>.
86 112
87The mutators for flags all return the CBOR object again and thus calls can 113The mutators for flags all return the CBOR object again and thus calls can
88be chained: 114be chained:
89 115
90#TODO
91 my $cbor = CBOR::XS->new->encode ({a => [1,2]}); 116 my $cbor = CBOR::XS->new->encode ({a => [1,2]});
117
118=item $cbor = new_safe CBOR::XS
119
120Create a new, safe/secure CBOR::XS object. This is similar to C<new>,
121but configures the coder object to be safe to use with untrusted
122data. Currently, this is equivalent to:
123
124 my $cbor = CBOR::XS
125 ->new
126 ->forbid_objects
127 ->filter (\&CBOR::XS::safe_filter)
128 ->max_size (1e8);
129
130But is more future proof (it is better to crash because of a change than
131to be exploited in other ways).
132
133=cut
134
135sub new_safe {
136 CBOR::XS
137 ->new
138 ->forbid_objects
139 ->filter (\&CBOR::XS::safe_filter)
140 ->max_size (1e8)
141}
92 142
93=item $cbor = $cbor->max_depth ([$maximum_nesting_depth]) 143=item $cbor = $cbor->max_depth ([$maximum_nesting_depth])
94 144
95=item $max_depth = $cbor->get_max_depth 145=item $max_depth = $cbor->get_max_depth
96 146
112 162
113Note that nesting is implemented by recursion in C. The default value has 163Note that nesting is implemented by recursion in C. The default value has
114been chosen to be as large as typical operating systems allow without 164been chosen to be as large as typical operating systems allow without
115crashing. 165crashing.
116 166
117See SECURITY CONSIDERATIONS, below, for more info on why this is useful. 167See L<SECURITY CONSIDERATIONS>, below, for more info on why this is useful.
118 168
119=item $cbor = $cbor->max_size ([$maximum_string_size]) 169=item $cbor = $cbor->max_size ([$maximum_string_size])
120 170
121=item $max_size = $cbor->get_max_size 171=item $max_size = $cbor->get_max_size
122 172
127effect on C<encode> (yet). 177effect on C<encode> (yet).
128 178
129If no argument is given, the limit check will be deactivated (same as when 179If no argument is given, the limit check will be deactivated (same as when
130C<0> is specified). 180C<0> is specified).
131 181
132See SECURITY CONSIDERATIONS, below, for more info on why this is useful. 182See L<SECURITY CONSIDERATIONS>, below, for more info on why this is useful.
183
184=item $cbor = $cbor->allow_unknown ([$enable])
185
186=item $enabled = $cbor->get_allow_unknown
187
188If C<$enable> is true (or missing), then C<encode> will I<not> throw an
189exception when it encounters values it cannot represent in CBOR (for
190example, filehandles) but instead will encode a CBOR C<error> value.
191
192If C<$enable> is false (the default), then C<encode> will throw an
193exception when it encounters anything it cannot encode as CBOR.
194
195This option does not affect C<decode> in any way, and it is recommended to
196leave it off unless you know your communications partner.
197
198=item $cbor = $cbor->allow_sharing ([$enable])
199
200=item $enabled = $cbor->get_allow_sharing
201
202If C<$enable> is true (or missing), then C<encode> will not double-encode
203values that have been referenced before (e.g. when the same object, such
204as an array, is referenced multiple times), but instead will emit a
205reference to the earlier value.
206
207This means that such values will only be encoded once, and will not result
208in a deep cloning of the value on decode, in decoders supporting the value
209sharing extension. This also makes it possible to encode cyclic data
210structures (which need C<allow_cycles> to be enabled to be decoded by this
211module).
212
213It is recommended to leave it off unless you know your
214communication partner supports the value sharing extensions to CBOR
215(L<http://cbor.schmorp.de/value-sharing>), as without decoder support, the
216resulting data structure might be unusable.
217
218Detecting shared values incurs a runtime overhead when values are encoded
219that have a reference counter large than one, and might unnecessarily
220increase the encoded size, as potentially shared values are encode as
221shareable whether or not they are actually shared.
222
223At the moment, only targets of references can be shared (e.g. scalars,
224arrays or hashes pointed to by a reference). Weirder constructs, such as
225an array with multiple "copies" of the I<same> string, which are hard but
226not impossible to create in Perl, are not supported (this is the same as
227with L<Storable>).
228
229If C<$enable> is false (the default), then C<encode> will encode shared
230data structures repeatedly, unsharing them in the process. Cyclic data
231structures cannot be encoded in this mode.
232
233This option does not affect C<decode> in any way - shared values and
234references will always be decoded properly if present.
235
236=item $cbor = $cbor->allow_cycles ([$enable])
237
238=item $enabled = $cbor->get_allow_cycles
239
240If C<$enable> is true (or missing), then C<decode> will happily decode
241self-referential (cyclic) data structures. By default these will not be
242decoded, as they need manual cleanup to avoid memory leaks, so code that
243isn't prepared for this will not leak memory.
244
245If C<$enable> is false (the default), then C<decode> will throw an error
246when it encounters a self-referential/cyclic data structure.
247
248FUTURE DIRECTION: the motivation behind this option is to avoid I<real>
249cycles - future versions of this module might chose to decode cyclic data
250structures using weak references when this option is off, instead of
251throwing an error.
252
253This option does not affect C<encode> in any way - shared values and
254references will always be encoded properly if present.
255
256=item $cbor = $cbor->forbid_objects ([$enable])
257
258=item $enabled = $cbor->get_forbid_objects
259
260Disables the use of the object serialiser protocol.
261
262If C<$enable> is true (or missing), then C<encode> will will throw an
263exception when it encounters perl objects that would be encoded using the
264perl-object tag (26). When C<decode> encounters such tags, it will fall
265back to the general filter/tagged logic as if this were an unknown tag (by
266default resulting in a C<CBOR::XC::Tagged> object).
267
268If C<$enable> is false (the default), then C<encode> will use the
269L<Types::Serialiser> object serialisation protocol to serialise objects
270into perl-object tags, and C<decode> will do the same to decode such tags.
271
272See L<SECURITY CONSIDERATIONS>, below, for more info on why forbidding this
273protocol can be useful.
274
275=item $cbor = $cbor->pack_strings ([$enable])
276
277=item $enabled = $cbor->get_pack_strings
278
279If C<$enable> is true (or missing), then C<encode> will try not to encode
280the same string twice, but will instead encode a reference to the string
281instead. Depending on your data format, this can save a lot of space, but
282also results in a very large runtime overhead (expect encoding times to be
2832-4 times as high as without).
284
285It is recommended to leave it off unless you know your
286communications partner supports the stringref extension to CBOR
287(L<http://cbor.schmorp.de/stringref>), as without decoder support, the
288resulting data structure might not be usable.
289
290If C<$enable> is false (the default), then C<encode> will encode strings
291the standard CBOR way.
292
293This option does not affect C<decode> in any way - string references will
294always be decoded properly if present.
295
296=item $cbor = $cbor->text_keys ([$enable])
297
298=item $enabled = $cbor->get_text_keys
299
300If C<$enabled> is true (or missing), then C<encode> will encode all
301perl hash keys as CBOR text strings/UTF-8 string, upgrading them as needed.
302
303If C<$enable> is false (the default), then C<encode> will encode hash keys
304normally - upgraded perl strings (strings internally encoded as UTF-8) as
305CBOR text strings, and downgraded perl strings as CBOR byte strings.
306
307This option does not affect C<decode> in any way.
308
309This option is useful for interoperability with CBOR decoders that don't
310treat byte strings as a form of text. It is especially useful as Perl
311gives very little control over hash keys.
312
313Enabling this option can be slow, as all downgraded hash keys that are
314encoded need to be scanned and converted to UTF-8.
315
316=item $cbor = $cbor->text_strings ([$enable])
317
318=item $enabled = $cbor->get_text_strings
319
320This option works similar to C<text_keys>, above, but works on all strings
321(including hash keys), so C<text_keys> has no further effect after
322enabling C<text_strings>.
323
324If C<$enabled> is true (or missing), then C<encode> will encode all perl
325strings as CBOR text strings/UTF-8 strings, upgrading them as needed.
326
327If C<$enable> is false (the default), then C<encode> will encode strings
328normally (but see C<text_keys>) - upgraded perl strings (strings
329internally encoded as UTF-8) as CBOR text strings, and downgraded perl
330strings as CBOR byte strings.
331
332This option does not affect C<decode> in any way.
333
334This option has similar advantages and disadvantages as C<text_keys>. In
335addition, this option effectively removes the ability to encode byte
336strings, which might break some C<FREEZE> and C<TO_CBOR> methods that rely
337on this, such as bignum encoding, so this option is mainly useful for very
338simple data.
339
340=item $cbor = $cbor->validate_utf8 ([$enable])
341
342=item $enabled = $cbor->get_validate_utf8
343
344If C<$enable> is true (or missing), then C<decode> will validate that
345elements (text strings) containing UTF-8 data in fact contain valid UTF-8
346data (instead of blindly accepting it). This validation obviously takes
347extra time during decoding.
348
349The concept of "valid UTF-8" used is perl's concept, which is a superset
350of the official UTF-8.
351
352If C<$enable> is false (the default), then C<decode> will blindly accept
353UTF-8 data, marking them as valid UTF-8 in the resulting data structure
354regardless of whether that's true or not.
355
356Perl isn't too happy about corrupted UTF-8 in strings, but should
357generally not crash or do similarly evil things. Extensions might be not
358so forgiving, so it's recommended to turn on this setting if you receive
359untrusted CBOR.
360
361This option does not affect C<encode> in any way - strings that are
362supposedly valid UTF-8 will simply be dumped into the resulting CBOR
363string without checking whether that is, in fact, true or not.
364
365=item $cbor = $cbor->filter ([$cb->($tag, $value)])
366
367=item $cb_or_undef = $cbor->get_filter
368
369Sets or replaces the tagged value decoding filter (when C<$cb> is
370specified) or clears the filter (if no argument or C<undef> is provided).
371
372The filter callback is called only during decoding, when a non-enforced
373tagged value has been decoded (see L<TAG HANDLING AND EXTENSIONS> for a
374list of enforced tags). For specific tags, it's often better to provide a
375default converter using the C<%CBOR::XS::FILTER> hash (see below).
376
377The first argument is the numerical tag, the second is the (decoded) value
378that has been tagged.
379
380The filter function should return either exactly one value, which will
381replace the tagged value in the decoded data structure, or no values,
382which will result in default handling, which currently means the decoder
383creates a C<CBOR::XS::Tagged> object to hold the tag and the value.
384
385When the filter is cleared (the default state), the default filter
386function, C<CBOR::XS::default_filter>, is used. This function simply
387looks up the tag in the C<%CBOR::XS::FILTER> hash. If an entry exists
388it must be a code reference that is called with tag and value, and is
389responsible for decoding the value. If no entry exists, it returns no
390values. C<CBOR::XS> provides a number of default filter functions already,
391the the C<%CBOR::XS::FILTER> hash can be freely extended with more.
392
393C<CBOR::XS> additionally provides an alternative filter function that is
394supposed to be safe to use with untrusted data (which the default filter
395might not), called C<CBOR::XS::safe_filter>, which works the same as
396the C<default_filter> but uses the C<%CBOR::XS::SAFE_FILTER> variable
397instead. It is prepopulated with the tag decoding functions that are
398deemed safe (basically the same as C<%CBOR::XS::FILTER> without all
399the bignum tags), and can be extended by user code as wlel, although,
400obviously, one should be very careful about adding decoding functions
401here, since the expectation is that they are safe to use on untrusted
402data, after all.
403
404Example: decode all tags not handled internally into C<CBOR::XS::Tagged>
405objects, with no other special handling (useful when working with
406potentially "unsafe" CBOR data).
407
408 CBOR::XS->new->filter (sub { })->decode ($cbor_data);
409
410Example: provide a global filter for tag 1347375694, converting the value
411into some string form.
412
413 $CBOR::XS::FILTER{1347375694} = sub {
414 my ($tag, $value);
415
416 "tag 1347375694 value $value"
417 };
418
419Example: provide your own filter function that looks up tags in your own
420hash:
421
422 my %my_filter = (
423 998347484 => sub {
424 my ($tag, $value);
425
426 "tag 998347484 value $value"
427 };
428 );
429
430 my $coder = CBOR::XS->new->filter (sub {
431 &{ $my_filter{$_[0]} or return }
432 });
433
434
435Example: use the safe filter function (see L<SECURITY CONSIDERATIONS> for
436more considerations on security).
437
438 CBOR::XS->new->filter (\&CBOR::XS::safe_filter)->decode ($cbor_data);
133 439
134=item $cbor_data = $cbor->encode ($perl_scalar) 440=item $cbor_data = $cbor->encode ($perl_scalar)
135 441
136Converts the given Perl data structure (a scalar value) to its CBOR 442Converts the given Perl data structure (a scalar value) to its CBOR
137representation. 443representation.
151and you need to know where the first CBOR string ends amd the next one 457and you need to know where the first CBOR string ends amd the next one
152starts. 458starts.
153 459
154 CBOR::XS->new->decode_prefix ("......") 460 CBOR::XS->new->decode_prefix ("......")
155 => ("...", 3) 461 => ("...", 3)
462
463=back
464
465=head2 INCREMENTAL PARSING
466
467In some cases, there is the need for incremental parsing of JSON
468texts. While this module always has to keep both CBOR text and resulting
469Perl data structure in memory at one time, it does allow you to parse a
470CBOR stream incrementally, using a similar to using "decode_prefix" to see
471if a full CBOR object is available, but is much more efficient.
472
473It basically works by parsing as much of a CBOR string as possible - if
474the CBOR data is not complete yet, the pasrer will remember where it was,
475to be able to restart when more data has been accumulated. Once enough
476data is available to either decode a complete CBOR value or raise an
477error, a real decode will be attempted.
478
479A typical use case would be a network protocol that consists of sending
480and receiving CBOR-encoded messages. The solution that works with CBOR and
481about anything else is by prepending a length to every CBOR value, so the
482receiver knows how many octets to read. More compact (and slightly slower)
483would be to just send CBOR values back-to-back, as C<CBOR::XS> knows where
484a CBOR value ends, and doesn't need an explicit length.
485
486The following methods help with this:
487
488=over 4
489
490=item @decoded = $cbor->incr_parse ($buffer)
491
492This method attempts to decode exactly one CBOR value from the beginning
493of the given C<$buffer>. The value is removed from the C<$buffer> on
494success. When C<$buffer> doesn't contain a complete value yet, it returns
495nothing. Finally, when the C<$buffer> doesn't start with something
496that could ever be a valid CBOR value, it raises an exception, just as
497C<decode> would. In the latter case the decoder state is undefined and
498must be reset before being able to parse further.
499
500This method modifies the C<$buffer> in place. When no CBOR value can be
501decoded, the decoder stores the current string offset. On the next call,
502continues decoding at the place where it stopped before. For this to make
503sense, the C<$buffer> must begin with the same octets as on previous
504unsuccessful calls.
505
506You can call this method in scalar context, in which case it either
507returns a decoded value or C<undef>. This makes it impossible to
508distinguish between CBOR null values (which decode to C<undef>) and an
509unsuccessful decode, which is often acceptable.
510
511=item @decoded = $cbor->incr_parse_multiple ($buffer)
512
513Same as C<incr_parse>, but attempts to decode as many CBOR values as
514possible in one go, instead of at most one. Calls to C<incr_parse> and
515C<incr_parse_multiple> can be interleaved.
516
517=item $cbor->incr_reset
518
519Resets the incremental decoder. This throws away any saved state, so that
520subsequent calls to C<incr_parse> or C<incr_parse_multiple> start to parse
521a new CBOR value from the beginning of the C<$buffer> again.
522
523This method can be called at any time, but it I<must> be called if you want
524to change your C<$buffer> or there was a decoding error and you want to
525reuse the C<$cbor> object for future incremental parsings.
156 526
157=back 527=back
158 528
159 529
160=head1 MAPPING 530=head1 MAPPING
178CBOR integers become (numeric) perl scalars. On perls without 64 bit 548CBOR integers become (numeric) perl scalars. On perls without 64 bit
179support, 64 bit integers will be truncated or otherwise corrupted. 549support, 64 bit integers will be truncated or otherwise corrupted.
180 550
181=item byte strings 551=item byte strings
182 552
183Byte strings will become octet strings in Perl (the byte values 0..255 553Byte strings will become octet strings in Perl (the Byte values 0..255
184will simply become characters of the same value in Perl). 554will simply become characters of the same value in Perl).
185 555
186=item UTF-8 strings 556=item UTF-8 strings
187 557
188UTF-8 strings in CBOR will be decoded, i.e. the UTF-8 octets will be 558UTF-8 strings in CBOR will be decoded, i.e. the UTF-8 octets will be
194 564
195CBOR arrays and CBOR maps will be converted into references to a Perl 565CBOR arrays and CBOR maps will be converted into references to a Perl
196array or hash, respectively. The keys of the map will be stringified 566array or hash, respectively. The keys of the map will be stringified
197during this process. 567during this process.
198 568
569=item null
570
571CBOR null becomes C<undef> in Perl.
572
199=item true, false 573=item true, false, undefined
200 574
201These CBOR values become C<CBOR::XS::true> and C<CBOR::XS::false>, 575These CBOR values become C<Types:Serialiser::true>,
576C<Types:Serialiser::false> and C<Types::Serialiser::error>,
202respectively. They are overloaded to act almost exactly like the numbers 577respectively. They are overloaded to act almost exactly like the numbers
203C<1> and C<0>. You can check whether a scalar is a CBOR boolean by using 578C<1> and C<0> (for true and false) or to throw an exception on access (for
204the C<CBOR::XS::is_bool> function. 579error). See the L<Types::Serialiser> manpage for details.
205 580
206=item null, undefined 581=item tagged values
207 582
208CBOR null and undefined values becomes C<undef> in Perl (in the future,
209Undefined may raise an exception or something else).
210
211=item tags
212
213Tagged items consists of a numeric tag and another CBOR value. The tag 583Tagged items consists of a numeric tag and another CBOR value.
21455799 is ignored (this tag implements the magic header).
215 584
216All other tags are currently converted into a L<CBOR::XS::Tagged> object, 585See L<TAG HANDLING AND EXTENSIONS> and the description of C<< ->filter >>
217which is simply a blessed array reference consistsing of the numeric tag 586for details on which tags are handled how.
218value followed by the (decoded) BOR value.
219 587
220=item anything else 588=item anything else
221 589
222Anything else (e.g. unsupported simple values) will raise a decoding 590Anything else (e.g. unsupported simple values) will raise a decoding
223error. 591error.
226 594
227 595
228=head2 PERL -> CBOR 596=head2 PERL -> CBOR
229 597
230The mapping from Perl to CBOR is slightly more difficult, as Perl is a 598The mapping from Perl to CBOR is slightly more difficult, as Perl is a
231truly typeless language, so we can only guess which CBOR type is meant by 599typeless language. That means this module can only guess which CBOR type
232a Perl value. 600is meant by a perl value.
233 601
234=over 4 602=over 4
235 603
236=item hash references 604=item hash references
237 605
238Perl hash references become CBOR maps. As there is no inherent ordering in 606Perl hash references become CBOR maps. As there is no inherent ordering in
239hash keys (or CBOR maps), they will usually be encoded in a pseudo-random 607hash keys (or CBOR maps), they will usually be encoded in a pseudo-random
240order. 608order. This order can be different each time a hash is encoded.
241 609
242Currently, tied hashes will use the indefinite-length format, while normal 610Currently, tied hashes will use the indefinite-length format, while normal
243hashes will use the fixed-length format. 611hashes will use the fixed-length format.
244 612
245=item array references 613=item array references
246 614
247Perl array references become fixed-length CBOR arrays. 615Perl array references become fixed-length CBOR arrays.
248 616
249=item other references 617=item other references
250 618
251Other unblessed references are generally not allowed and will cause an 619Other unblessed references will be represented using
252exception to be thrown, except for references to the integers C<0> and 620the indirection tag extension (tag value C<22098>,
253C<1>, which get turned into false and true in CBOR. 621L<http://cbor.schmorp.de/indirection>). CBOR decoders are guaranteed
622to be able to decode these values somehow, by either "doing the right
623thing", decoding into a generic tagged object, simply ignoring the tag, or
624something else.
254 625
255=item CBOR::XS::Tagged objects 626=item CBOR::XS::Tagged objects
256 627
257Objects of this type must be arrays consisting of a single C<[tag, value]> 628Objects of this type must be arrays consisting of a single C<[tag, value]>
258pair. The (numerical) tag will be encoded as a CBOR tag, the value will be 629pair. The (numerical) tag will be encoded as a CBOR tag, the value will
259encoded as appropriate for the value. 630be encoded as appropriate for the value. You must use C<CBOR::XS::tag> to
631create such objects.
260 632
261=item CBOR::XS::true, CBOR::XS::false 633=item Types::Serialiser::true, Types::Serialiser::false, Types::Serialiser::error
262 634
263These special values become CBOR true and CBOR false values, 635These special values become CBOR true, CBOR false and CBOR undefined
264respectively. You can also use C<\1> and C<\0> directly if you want. 636values, respectively. You can also use C<\1>, C<\0> and C<\undef> directly
637if you want.
265 638
266=item blessed objects 639=item other blessed objects
267 640
268Other blessed objects currently need to have a C<TO_CBOR> method. It 641Other blessed objects are serialised via C<TO_CBOR> or C<FREEZE>. See
269will be called on every object that is being serialised, and must return 642L<TAG HANDLING AND EXTENSIONS> for specific classes handled by this
270something that can be encoded in CBOR. 643module, and L<OBJECT SERIALISATION> for generic object serialisation.
271 644
272=item simple scalars 645=item simple scalars
273 646
274TODO
275Simple Perl scalars (any scalar that is not a reference) are the most 647Simple Perl scalars (any scalar that is not a reference) are the most
276difficult objects to encode: CBOR::XS will encode undefined scalars as 648difficult objects to encode: CBOR::XS will encode undefined scalars as
277CBOR null values, scalars that have last been used in a string context 649CBOR null values, scalars that have last been used in a string context
278before encoding as CBOR strings, and anything else as number value: 650before encoding as CBOR strings, and anything else as number value:
279 651
280 # dump as number 652 # dump as number
281 encode_cbor [2] # yields [2] 653 encode_cbor [2] # yields [2]
282 encode_cbor [-3.0e17] # yields [-3e+17] 654 encode_cbor [-3.0e17] # yields [-3e+17]
283 my $value = 5; encode_cbor [$value] # yields [5] 655 my $value = 5; encode_cbor [$value] # yields [5]
284 656
285 # used as string, so dump as string 657 # used as string, so dump as string (either byte or text)
286 print $value; 658 print $value;
287 encode_cbor [$value] # yields ["5"] 659 encode_cbor [$value] # yields ["5"]
288 660
289 # undef becomes null 661 # undef becomes null
290 encode_cbor [undef] # yields [null] 662 encode_cbor [undef] # yields [null]
293 665
294 my $x = 3.1; # some variable containing a number 666 my $x = 3.1; # some variable containing a number
295 "$x"; # stringified 667 "$x"; # stringified
296 $x .= ""; # another, more awkward way to stringify 668 $x .= ""; # another, more awkward way to stringify
297 print $x; # perl does it for you, too, quite often 669 print $x; # perl does it for you, too, quite often
670
671You can force whether a string is encoded as byte or text string by using
672C<utf8::upgrade> and C<utf8::downgrade> (if C<text_strings> is disabled):
673
674 utf8::upgrade $x; # encode $x as text string
675 utf8::downgrade $x; # encode $x as byte string
676
677Perl doesn't define what operations up- and downgrade strings, so if the
678difference between byte and text is important, you should up- or downgrade
679your string as late as possible before encoding. You can also force the
680use of CBOR text strings by using C<text_keys> or C<text_strings>.
298 681
299You can force the type to be a CBOR number by numifying it: 682You can force the type to be a CBOR number by numifying it:
300 683
301 my $x = "3"; # some variable containing a string 684 my $x = "3"; # some variable containing a string
302 $x += 0; # numify it, ensuring it will be dumped as a number 685 $x += 0; # numify it, ensuring it will be dumped as a number
313represent numerical values are supported, but might suffer loss of 696represent numerical values are supported, but might suffer loss of
314precision. 697precision.
315 698
316=back 699=back
317 700
701=head2 OBJECT SERIALISATION
318 702
703This module implements both a CBOR-specific and the generic
704L<Types::Serialier> object serialisation protocol. The following
705subsections explain both methods.
706
707=head3 ENCODING
708
709This module knows two way to serialise a Perl object: The CBOR-specific
710way, and the generic way.
711
712Whenever the encoder encounters a Perl object that it cannot serialise
713directly (most of them), it will first look up the C<TO_CBOR> method on
714it.
715
716If it has a C<TO_CBOR> method, it will call it with the object as only
717argument, and expects exactly one return value, which it will then
718substitute and encode it in the place of the object.
719
720Otherwise, it will look up the C<FREEZE> method. If it exists, it will
721call it with the object as first argument, and the constant string C<CBOR>
722as the second argument, to distinguish it from other serialisers.
723
724The C<FREEZE> method can return any number of values (i.e. zero or
725more). These will be encoded as CBOR perl object, together with the
726classname.
727
728These methods I<MUST NOT> change the data structure that is being
729serialised. Failure to comply to this can result in memory corruption -
730and worse.
731
732If an object supports neither C<TO_CBOR> nor C<FREEZE>, encoding will fail
733with an error.
734
735=head3 DECODING
736
737Objects encoded via C<TO_CBOR> cannot (normally) be automatically decoded,
738but objects encoded via C<FREEZE> can be decoded using the following
739protocol:
740
741When an encoded CBOR perl object is encountered by the decoder, it will
742look up the C<THAW> method, by using the stored classname, and will fail
743if the method cannot be found.
744
745After the lookup it will call the C<THAW> method with the stored classname
746as first argument, the constant string C<CBOR> as second argument, and all
747values returned by C<FREEZE> as remaining arguments.
748
749=head3 EXAMPLES
750
751Here is an example C<TO_CBOR> method:
752
753 sub My::Object::TO_CBOR {
754 my ($obj) = @_;
755
756 ["this is a serialised My::Object object", $obj->{id}]
757 }
758
759When a C<My::Object> is encoded to CBOR, it will instead encode a simple
760array with two members: a string, and the "object id". Decoding this CBOR
761string will yield a normal perl array reference in place of the object.
762
763A more useful and practical example would be a serialisation method for
764the URI module. CBOR has a custom tag value for URIs, namely 32:
765
766 sub URI::TO_CBOR {
767 my ($self) = @_;
768 my $uri = "$self"; # stringify uri
769 utf8::upgrade $uri; # make sure it will be encoded as UTF-8 string
770 CBOR::XS::tag 32, "$_[0]"
771 }
772
773This will encode URIs as a UTF-8 string with tag 32, which indicates an
774URI.
775
776Decoding such an URI will not (currently) give you an URI object, but
777instead a CBOR::XS::Tagged object with tag number 32 and the string -
778exactly what was returned by C<TO_CBOR>.
779
780To serialise an object so it can automatically be deserialised, you need
781to use C<FREEZE> and C<THAW>. To take the URI module as example, this
782would be a possible implementation:
783
784 sub URI::FREEZE {
785 my ($self, $serialiser) = @_;
786 "$self" # encode url string
787 }
788
789 sub URI::THAW {
790 my ($class, $serialiser, $uri) = @_;
791 $class->new ($uri)
792 }
793
794Unlike C<TO_CBOR>, multiple values can be returned by C<FREEZE>. For
795example, a C<FREEZE> method that returns "type", "id" and "variant" values
796would cause an invocation of C<THAW> with 5 arguments:
797
798 sub My::Object::FREEZE {
799 my ($self, $serialiser) = @_;
800
801 ($self->{type}, $self->{id}, $self->{variant})
802 }
803
804 sub My::Object::THAW {
805 my ($class, $serialiser, $type, $id, $variant) = @_;
806
807 $class-<new (type => $type, id => $id, variant => $variant)
808 }
809
810
319=head2 MAGIC HEADER 811=head1 MAGIC HEADER
320 812
321There is no way to distinguish CBOR from other formats 813There is no way to distinguish CBOR from other formats
322programmatically. To make it easier to distinguish CBOR from other 814programmatically. To make it easier to distinguish CBOR from other
323formats, the CBOR specification has a special "magic string" that can be 815formats, the CBOR specification has a special "magic string" that can be
324prepended to any CBOR string without changing it's meaning. 816prepended to any CBOR string without changing its meaning.
325 817
326This string is available as C<$CBOR::XS::MAGIC>. This module does not 818This string is available as C<$CBOR::XS::MAGIC>. This module does not
327prepend this string tot he CBOR data it generates, but it will ignroe it 819prepend this string to the CBOR data it generates, but it will ignore it
328if present, so users can prepend this string as a "file type" indicator as 820if present, so users can prepend this string as a "file type" indicator as
329required. 821required.
330 822
331 823
824=head1 THE CBOR::XS::Tagged CLASS
825
826CBOR has the concept of tagged values - any CBOR value can be tagged with
827a numeric 64 bit number, which are centrally administered.
828
829C<CBOR::XS> handles a few tags internally when en- or decoding. You can
830also create tags yourself by encoding C<CBOR::XS::Tagged> objects, and the
831decoder will create C<CBOR::XS::Tagged> objects itself when it hits an
832unknown tag.
833
834These objects are simply blessed array references - the first member of
835the array being the numerical tag, the second being the value.
836
837You can interact with C<CBOR::XS::Tagged> objects in the following ways:
838
839=over 4
840
841=item $tagged = CBOR::XS::tag $tag, $value
842
843This function(!) creates a new C<CBOR::XS::Tagged> object using the given
844C<$tag> (0..2**64-1) to tag the given C<$value> (which can be any Perl
845value that can be encoded in CBOR, including serialisable Perl objects and
846C<CBOR::XS::Tagged> objects).
847
848=item $tagged->[0]
849
850=item $tagged->[0] = $new_tag
851
852=item $tag = $tagged->tag
853
854=item $new_tag = $tagged->tag ($new_tag)
855
856Access/mutate the tag.
857
858=item $tagged->[1]
859
860=item $tagged->[1] = $new_value
861
862=item $value = $tagged->value
863
864=item $new_value = $tagged->value ($new_value)
865
866Access/mutate the tagged value.
867
868=back
869
870=cut
871
872sub tag($$) {
873 bless [@_], CBOR::XS::Tagged::;
874}
875
876sub CBOR::XS::Tagged::tag {
877 $_[0][0] = $_[1] if $#_;
878 $_[0][0]
879}
880
881sub CBOR::XS::Tagged::value {
882 $_[0][1] = $_[1] if $#_;
883 $_[0][1]
884}
885
886=head2 EXAMPLES
887
888Here are some examples of C<CBOR::XS::Tagged> uses to tag objects.
889
890You can look up CBOR tag value and emanings in the IANA registry at
891L<http://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml>.
892
893Prepend a magic header (C<$CBOR::XS::MAGIC>):
894
895 my $cbor = encode_cbor CBOR::XS::tag 55799, $value;
896 # same as:
897 my $cbor = $CBOR::XS::MAGIC . encode_cbor $value;
898
899Serialise some URIs and a regex in an array:
900
901 my $cbor = encode_cbor [
902 (CBOR::XS::tag 32, "http://www.nethype.de/"),
903 (CBOR::XS::tag 32, "http://software.schmorp.de/"),
904 (CBOR::XS::tag 35, "^[Pp][Ee][Rr][lL]\$"),
905 ];
906
907Wrap CBOR data in CBOR:
908
909 my $cbor_cbor = encode_cbor
910 CBOR::XS::tag 24,
911 encode_cbor [1, 2, 3];
912
913=head1 TAG HANDLING AND EXTENSIONS
914
915This section describes how this module handles specific tagged values
916and extensions. If a tag is not mentioned here and no additional filters
917are provided for it, then the default handling applies (creating a
918CBOR::XS::Tagged object on decoding, and only encoding the tag when
919explicitly requested).
920
921Tags not handled specifically are currently converted into a
922L<CBOR::XS::Tagged> object, which is simply a blessed array reference
923consisting of the numeric tag value followed by the (decoded) CBOR value.
924
925Future versions of this module reserve the right to special case
926additional tags (such as base64url).
927
928=head2 ENFORCED TAGS
929
930These tags are always handled when decoding, and their handling cannot be
931overridden by the user.
932
933=over 4
934
935=item 26 (perl-object, L<http://cbor.schmorp.de/perl-object>)
936
937These tags are automatically created (and decoded) for serialisable
938objects using the C<FREEZE/THAW> methods (the L<Types::Serialier> object
939serialisation protocol). See L<OBJECT SERIALISATION> for details.
940
941=item 28, 29 (shareable, sharedref, L<http://cbor.schmorp.de/value-sharing>)
942
943These tags are automatically decoded when encountered (and they do not
944result in a cyclic data structure, see C<allow_cycles>), resulting in
945shared values in the decoded object. They are only encoded, however, when
946C<allow_sharing> is enabled.
947
948Not all shared values can be successfully decoded: values that reference
949themselves will I<currently> decode as C<undef> (this is not the same
950as a reference pointing to itself, which will be represented as a value
951that contains an indirect reference to itself - these will be decoded
952properly).
953
954Note that considerably more shared value data structures can be decoded
955than will be encoded - currently, only values pointed to by references
956will be shared, others will not. While non-reference shared values can be
957generated in Perl with some effort, they were considered too unimportant
958to be supported in the encoder. The decoder, however, will decode these
959values as shared values.
960
961=item 256, 25 (stringref-namespace, stringref, L<http://cbor.schmorp.de/stringref>)
962
963These tags are automatically decoded when encountered. They are only
964encoded, however, when C<pack_strings> is enabled.
965
966=item 22098 (indirection, L<http://cbor.schmorp.de/indirection>)
967
968This tag is automatically generated when a reference are encountered (with
969the exception of hash and array references). It is converted to a reference
970when decoding.
971
972=item 55799 (self-describe CBOR, RFC 7049)
973
974This value is not generated on encoding (unless explicitly requested by
975the user), and is simply ignored when decoding.
976
977=back
978
979=head2 NON-ENFORCED TAGS
980
981These tags have default filters provided when decoding. Their handling can
982be overridden by changing the C<%CBOR::XS::FILTER> entry for the tag, or by
983providing a custom C<filter> callback when decoding.
984
985When they result in decoding into a specific Perl class, the module
986usually provides a corresponding C<TO_CBOR> method as well.
987
988When any of these need to load additional modules that are not part of the
989perl core distribution (e.g. L<URI>), it is (currently) up to the user to
990provide these modules. The decoding usually fails with an exception if the
991required module cannot be loaded.
992
993=over 4
994
995=item 0, 1 (date/time string, seconds since the epoch)
996
997These tags are decoded into L<Time::Piece> objects. The corresponding
998C<Time::Piece::TO_CBOR> method always encodes into tag 1 values currently.
999
1000The L<Time::Piece> API is generally surprisingly bad, and fractional
1001seconds are only accidentally kept intact, so watch out. On the plus side,
1002the module comes with perl since 5.10, which has to count for something.
1003
1004=item 2, 3 (positive/negative bignum)
1005
1006These tags are decoded into L<Math::BigInt> objects. The corresponding
1007C<Math::BigInt::TO_CBOR> method encodes "small" bigints into normal CBOR
1008integers, and others into positive/negative CBOR bignums.
1009
1010=item 4, 5, 264, 265 (decimal fraction/bigfloat)
1011
1012Both decimal fractions and bigfloats are decoded into L<Math::BigFloat>
1013objects. The corresponding C<Math::BigFloat::TO_CBOR> method I<always>
1014encodes into a decimal fraction (either tag 4 or 264).
1015
1016NaN and infinities are not encoded properly, as they cannot be represented
1017in CBOR.
1018
1019See L<BIGNUM SECURITY CONSIDERATIONS> for more info.
1020
1021=item 30 (rational numbers)
1022
1023These tags are decoded into L<Math::BigRat> objects. The corresponding
1024C<Math::BigRat::TO_CBOR> method encodes rational numbers with denominator
1025C<1> via their numerator only, i.e., they become normal integers or
1026C<bignums>.
1027
1028See L<BIGNUM SECURITY CONSIDERATIONS> for more info.
1029
1030=item 21, 22, 23 (expected later JSON conversion)
1031
1032CBOR::XS is not a CBOR-to-JSON converter, and will simply ignore these
1033tags.
1034
1035=item 32 (URI)
1036
1037These objects decode into L<URI> objects. The corresponding
1038C<URI::TO_CBOR> method again results in a CBOR URI value.
1039
1040=back
1041
1042=cut
1043
332=head2 CBOR and JSON 1044=head1 CBOR and JSON
333 1045
334CBOR is supposed to implement a superset of the JSON data model, and is, 1046CBOR is supposed to implement a superset of the JSON data model, and is,
335with some coercion, able to represent all JSON texts (something that other 1047with some coercion, able to represent all JSON texts (something that other
336"binary JSON" formats such as BSON generally do not support). 1048"binary JSON" formats such as BSON generally do not support).
337 1049
344CBOR intact. 1056CBOR intact.
345 1057
346 1058
347=head1 SECURITY CONSIDERATIONS 1059=head1 SECURITY CONSIDERATIONS
348 1060
349When you are using CBOR in a protocol, talking to untrusted potentially 1061Tl;dr... if you want to decode or encode CBOR from untrusted sources, you
350hostile creatures requires relatively few measures. 1062should start with a coder object created via C<new_safe>:
351 1063
1064 my $coder = CBOR::XS->new_safe;
1065
1066 my $data = $coder->decode ($cbor_text);
1067 my $cbor = $coder->encode ($data);
1068
1069Longer version: When you are using CBOR in a protocol, talking to
1070untrusted potentially hostile creatures requires some thought:
1071
1072=over 4
1073
1074=item Security of the CBOR decoder itself
1075
352First of all, your CBOR decoder should be secure, that is, should not have 1076First and foremost, your CBOR decoder should be secure, that is, should
1077not have any buffer overflows or similar bugs that could potentially be
353any buffer overflows. Obviously, this module should ensure that and I am 1078exploited. Obviously, this module should ensure that and I am trying hard
354trying hard on making that true, but you never know. 1079on making that true, but you never know.
355 1080
1081=item CBOR::XS can invoke almost arbitrary callbacks during decoding
1082
1083CBOR::XS supports object serialisation - decoding CBOR can cause calls
1084to I<any> C<THAW> method in I<any> package that exists in your process
1085(that is, CBOR::XS will not try to load modules, but any existing C<THAW>
1086method or function can be called, so they all have to be secure).
1087
1088Less obviously, it will also invoke C<TO_CBOR> and C<FREEZE> methods -
1089even if all your C<THAW> methods are secure, encoding data structures from
1090untrusted sources can invoke those and trigger bugs in those.
1091
1092So, if you are not sure about the security of all the modules you
1093have loaded (you shouldn't), you should disable this part using
1094C<forbid_objects>.
1095
1096=item CBOR can be extended with tags that call library code
1097
1098CBOR can be extended with tags, and C<CBOR::XS> has a registry of
1099conversion functions for many existing tags that can be extended via
1100third-party modules (see the C<filter> method).
1101
1102If you don't trust these, you should configure the "safe" filter function,
1103C<CBOR::XS::safe_filter>, which by default only includes conversion
1104functions that are considered "safe" by the author (but again, they can be
1105extended by third party modules).
1106
1107Depending on your level of paranoia, you can use the "safe" filter:
1108
1109 $cbor->filter (\&CBOR::XS::safe_filter);
1110
1111... your own filter...
1112
1113 $cbor->filter (sub { ... do your stuffs here ... });
1114
1115... or even no filter at all, disabling all tag decoding:
1116
1117 $cbor->filter (sub { });
1118
1119This is never a problem for encoding, as the tag mechanism only exists in
1120CBOR texts.
1121
1122=item Resource-starving attacks: object memory usage
1123
356Second, you need to avoid resource-starving attacks. That means you should 1124You need to avoid resource-starving attacks. That means you should limit
357limit the size of CBOR data you accept, or make sure then when your 1125the size of CBOR data you accept, or make sure then when your resources
358resources run out, that's just fine (e.g. by using a separate process that 1126run out, that's just fine (e.g. by using a separate process that can
359can crash safely). The size of a CBOR string in octets is usually a good 1127crash safely). The size of a CBOR string in octets is usually a good
360indication of the size of the resources required to decode it into a Perl 1128indication of the size of the resources required to decode it into a Perl
361structure. While CBOR::XS can check the size of the CBOR text, it might be 1129structure. While CBOR::XS can check the size of the CBOR text (using
362too late when you already have it in memory, so you might want to check 1130C<max_size>), it might be too late when you already have it in memory, so
363the size before you accept the string. 1131you might want to check the size before you accept the string.
364 1132
1133As for encoding, it is possible to construct data structures that are
1134relatively small but result in large CBOR texts (for example by having an
1135array full of references to the same big data structure, which will all be
1136deep-cloned during encoding by default). This is rarely an actual issue
1137(and the worst case is still just running out of memory), but you can
1138reduce this risk by using C<allow_sharing>.
1139
1140=item Resource-starving attacks: stack overflows
1141
365Third, CBOR::XS recurses using the C stack when decoding objects and 1142CBOR::XS recurses using the C stack when decoding objects and arrays. The
366arrays. The C stack is a limited resource: for instance, on my amd64 1143C stack is a limited resource: for instance, on my amd64 machine with 8MB
367machine with 8MB of stack size I can decode around 180k nested arrays but 1144of stack size I can decode around 180k nested arrays but only 14k nested
368only 14k nested CBOR objects (due to perl itself recursing deeply on croak 1145CBOR objects (due to perl itself recursing deeply on croak to free the
369to free the temporary). If that is exceeded, the program crashes. To be 1146temporary). If that is exceeded, the program crashes. To be conservative,
370conservative, the default nesting limit is set to 512. If your process 1147the default nesting limit is set to 512. If your process has a smaller
371has a smaller stack, you should adjust this setting accordingly with the 1148stack, you should adjust this setting accordingly with the C<max_depth>
372C<max_depth> method. 1149method.
1150
1151=item Resource-starving attacks: CPU en-/decoding complexity
1152
1153CBOR::XS will use the L<Math::BigInt>, L<Math::BigFloat> and
1154L<Math::BigRat> libraries to represent encode/decode bignums. These can
1155be very slow (as in, centuries of CPU time) and can even crash your
1156program (and are generally not very trustworthy). See the next section for
1157details.
1158
1159=item Data breaches: leaking information in error messages
1160
1161CBOR::XS might leak contents of your Perl data structures in its error
1162messages, so when you serialise sensitive information you might want to
1163make sure that exceptions thrown by CBOR::XS will not end up in front of
1164untrusted eyes.
1165
1166=item Something else...
373 1167
374Something else could bomb you, too, that I forgot to think of. In that 1168Something else could bomb you, too, that I forgot to think of. In that
375case, you get to keep the pieces. I am always open for hints, though... 1169case, you get to keep the pieces. I am always open for hints, though...
376 1170
377Also keep in mind that CBOR::XS might leak contents of your Perl data 1171=back
378structures in its error messages, so when you serialise sensitive 1172
379information you might want to make sure that exceptions thrown by CBOR::XS 1173
380will not end up in front of untrusted eyes. 1174=head1 BIGNUM SECURITY CONSIDERATIONS
1175
1176CBOR::XS provides a C<TO_CBOR> method for both L<Math::BigInt> and
1177L<Math::BigFloat> that tries to encode the number in the simplest possible
1178way, that is, either a CBOR integer, a CBOR bigint/decimal fraction (tag
11794) or an arbitrary-exponent decimal fraction (tag 264). Rational numbers
1180(L<Math::BigRat>, tag 30) can also contain bignums as members.
1181
1182CBOR::XS will also understand base-2 bigfloat or arbitrary-exponent
1183bigfloats (tags 5 and 265), but it will never generate these on its own.
1184
1185Using the built-in L<Math::BigInt::Calc> support, encoding and decoding
1186decimal fractions is generally fast. Decoding bigints can be slow for very
1187big numbers (tens of thousands of digits, something that could potentially
1188be caught by limiting the size of CBOR texts), and decoding bigfloats or
1189arbitrary-exponent bigfloats can be I<extremely> slow (minutes, decades)
1190for large exponents (roughly 40 bit and longer).
1191
1192Additionally, L<Math::BigInt> can take advantage of other bignum
1193libraries, such as L<Math::GMP>, which cannot handle big floats with large
1194exponents, and might simply abort or crash your program, due to their code
1195quality.
1196
1197This can be a concern if you want to parse untrusted CBOR. If it is, you
1198might want to disable decoding of tag 2 (bigint) and 3 (negative bigint)
1199types. You should also disable types 5 and 265, as these can be slow even
1200without bigints.
1201
1202Disabling bigints will also partially or fully disable types that rely on
1203them, e.g. rational numbers that use bignums.
1204
381 1205
382=head1 CBOR IMPLEMENTATION NOTES 1206=head1 CBOR IMPLEMENTATION NOTES
383 1207
384This section contains some random implementation notes. They do not 1208This section contains some random implementation notes. They do not
385describe guaranteed behaviour, but merely behaviour as-is implemented 1209describe guaranteed behaviour, but merely behaviour as-is implemented
394Only the double data type is supported for NV data types - when Perl uses 1218Only the double data type is supported for NV data types - when Perl uses
395long double to represent floating point values, they might not be encoded 1219long double to represent floating point values, they might not be encoded
396properly. Half precision types are accepted, but not encoded. 1220properly. Half precision types are accepted, but not encoded.
397 1221
398Strict mode and canonical mode are not implemented. 1222Strict mode and canonical mode are not implemented.
1223
1224
1225=head1 LIMITATIONS ON PERLS WITHOUT 64-BIT INTEGER SUPPORT
1226
1227On perls that were built without 64 bit integer support (these are rare
1228nowadays, even on 32 bit architectures, as all major Perl distributions
1229are built with 64 bit integer support), support for any kind of 64 bit
1230integer in CBOR is very limited - most likely, these 64 bit values will
1231be truncated, corrupted, or otherwise not decoded correctly. This also
1232includes string, array and map sizes that are stored as 64 bit integers.
399 1233
400 1234
401=head1 THREADS 1235=head1 THREADS
402 1236
403This module is I<not> guaranteed to be thread safe and there are no 1237This module is I<not> guaranteed to be thread safe and there are no
417Please refrain from using rt.cpan.org or any other bug reporting 1251Please refrain from using rt.cpan.org or any other bug reporting
418service. I put the contact address into my modules for a reason. 1252service. I put the contact address into my modules for a reason.
419 1253
420=cut 1254=cut
421 1255
422our $true = do { bless \(my $dummy = 1), "CBOR::XS::Boolean" }; 1256# clumsy and slow hv_store-in-hash helper function
423our $false = do { bless \(my $dummy = 0), "CBOR::XS::Boolean" }; 1257sub _hv_store {
424 1258 $_[0]{$_[1]} = $_[2];
425sub true() { $true }
426sub false() { $false }
427
428sub is_bool($) {
429 UNIVERSAL::isa $_[0], "CBOR::XS::Boolean"
430# or UNIVERSAL::isa $_[0], "CBOR::Literal"
431} 1259}
432 1260
1261our %FILTER = (
1262 0 => sub { # rfc4287 datetime, utf-8
1263 require Time::Piece;
1264 # Time::Piece::Strptime uses the "incredibly flexible date parsing routine"
1265 # from FreeBSD, which can't parse ISO 8601, RFC3339, RFC4287 or much of anything
1266 # else either. Whats incredibe over standard strptime totally escapes me.
1267 # doesn't do fractional times, either. sigh.
1268 # In fact, it's all a lie, it uses whatever strptime it wants, and of course,
1269 # they are all incompatible. The openbsd one simply ignores %z (but according to the
1270 # docs, it would be much more incredibly flexible indeed. If it worked, that is.).
1271 scalar eval {
1272 my $s = $_[1];
1273
1274 $s =~ s/Z$/+00:00/;
1275 $s =~ s/(\.[0-9]+)?([+-][0-9][0-9]):([0-9][0-9])$//
1276 or die;
1277
1278 my $b = $1 - ($2 * 60 + $3) * 60; # fractional part + offset. hopefully
1279 my $d = Time::Piece->strptime ($s, "%Y-%m-%dT%H:%M:%S");
1280
1281 Time::Piece::gmtime ($d->epoch + $b)
1282 } || die "corrupted CBOR date/time string ($_[0])";
1283 },
1284
1285 1 => sub { # seconds since the epoch, possibly fractional
1286 require Time::Piece;
1287 scalar Time::Piece::gmtime (pop)
1288 },
1289
1290 2 => sub { # pos bigint
1291 require Math::BigInt;
1292 Math::BigInt->new ("0x" . unpack "H*", pop)
1293 },
1294
1295 3 => sub { # neg bigint
1296 require Math::BigInt;
1297 -Math::BigInt->new ("0x" . unpack "H*", pop)
1298 },
1299
1300 4 => sub { # decimal fraction, array
1301 require Math::BigFloat;
1302 Math::BigFloat->new ($_[1][1] . "E" . $_[1][0])
1303 },
1304
1305 264 => sub { # decimal fraction with arbitrary exponent
1306 require Math::BigFloat;
1307 Math::BigFloat->new ($_[1][1] . "E" . $_[1][0])
1308 },
1309
1310 5 => sub { # bigfloat, array
1311 require Math::BigFloat;
1312 scalar Math::BigFloat->new ($_[1][1]) * Math::BigFloat->new (2)->bpow ($_[1][0])
1313 },
1314
1315 265 => sub { # bigfloat with arbitrary exponent
1316 require Math::BigFloat;
1317 scalar Math::BigFloat->new ($_[1][1]) * Math::BigFloat->new (2)->bpow ($_[1][0])
1318 },
1319
1320 30 => sub { # rational number
1321 require Math::BigRat;
1322 Math::BigRat->new ("$_[1][0]/$_[1][1]") # separate parameters only work in recent versons
1323 },
1324
1325 21 => sub { pop }, # expected conversion to base64url encoding
1326 22 => sub { pop }, # expected conversion to base64 encoding
1327 23 => sub { pop }, # expected conversion to base16 encoding
1328
1329 # 24 # embedded cbor, byte string
1330
1331 32 => sub {
1332 require URI;
1333 URI->new (pop)
1334 },
1335
1336 # 33 # base64url rfc4648, utf-8
1337 # 34 # base64 rfc46484, utf-8
1338 # 35 # regex pcre/ecma262, utf-8
1339 # 36 # mime message rfc2045, utf-8
1340);
1341
1342sub default_filter {
1343 &{ $FILTER{$_[0]} or return }
1344}
1345
1346our %SAFE_FILTER = map { $_ => $FILTER{$_} } 0, 1, 21, 22, 23, 32;
1347
1348sub safe_filter {
1349 &{ $SAFE_FILTER{$_[0]} or return }
1350}
1351
1352sub URI::TO_CBOR {
1353 my $uri = $_[0]->as_string;
1354 utf8::upgrade $uri;
1355 tag 32, $uri
1356}
1357
1358sub Math::BigInt::TO_CBOR {
1359 if (-2147483648 <= $_[0] && $_[0] <= 2147483647) {
1360 $_[0]->numify
1361 } else {
1362 my $hex = substr $_[0]->as_hex, 2;
1363 $hex = "0$hex" if 1 & length $hex; # sigh
1364 tag $_[0] >= 0 ? 2 : 3, pack "H*", $hex
1365 }
1366}
1367
1368sub Math::BigFloat::TO_CBOR {
1369 my ($m, $e) = $_[0]->parts;
1370
1371 -9223372036854775808 <= $e && $e <= 18446744073709551615
1372 ? tag 4, [$e->numify, $m]
1373 : tag 264, [$e, $m]
1374}
1375
1376sub Math::BigRat::TO_CBOR {
1377 my ($n, $d) = $_[0]->parts;
1378
1379 # older versions of BigRat need *1, as they not always return numbers
1380
1381 $d*1 == 1
1382 ? $n*1
1383 : tag 30, [$n*1, $d*1]
1384}
1385
1386sub Time::Piece::TO_CBOR {
1387 tag 1, 0 + $_[0]->epoch
1388}
1389
433XSLoader::load "CBOR::XS", $VERSION; 1390XSLoader::load "CBOR::XS", $VERSION;
434
435package CBOR::XS::Boolean;
436
437use overload
438 "0+" => sub { ${$_[0]} },
439 "++" => sub { $_[0] = ${$_[0]} + 1 },
440 "--" => sub { $_[0] = ${$_[0]} - 1 },
441 fallback => 1;
442
4431;
444 1391
445=head1 SEE ALSO 1392=head1 SEE ALSO
446 1393
447The L<JSON> and L<JSON::XS> modules that do similar, but human-readable, 1394The L<JSON> and L<JSON::XS> modules that do similar, but human-readable,
448serialisation. 1395serialisation.
449 1396
1397The L<Types::Serialiser> module provides the data model for true, false
1398and error values.
1399
450=head1 AUTHOR 1400=head1 AUTHOR
451 1401
452 Marc Lehmann <schmorp@schmorp.de> 1402 Marc Lehmann <schmorp@schmorp.de>
453 http://home.schmorp.de/ 1403 http://home.schmorp.de/
454 1404
455=cut 1405=cut
456 1406
14071
1408

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines