… | |
… | |
64 | |
64 | |
65 | package CBOR::XS; |
65 | package CBOR::XS; |
66 | |
66 | |
67 | use common::sense; |
67 | use common::sense; |
68 | |
68 | |
69 | our $VERSION = 1.11; |
69 | our $VERSION = 1.12; |
70 | our @ISA = qw(Exporter); |
70 | our @ISA = qw(Exporter); |
71 | |
71 | |
72 | our @EXPORT = qw(encode_cbor decode_cbor); |
72 | our @EXPORT = qw(encode_cbor decode_cbor); |
73 | |
73 | |
74 | use Exporter; |
74 | use Exporter; |
… | |
… | |
330 | and you need to know where the first CBOR string ends amd the next one |
330 | and you need to know where the first CBOR string ends amd the next one |
331 | starts. |
331 | starts. |
332 | |
332 | |
333 | CBOR::XS->new->decode_prefix ("......") |
333 | CBOR::XS->new->decode_prefix ("......") |
334 | => ("...", 3) |
334 | => ("...", 3) |
|
|
335 | |
|
|
336 | =back |
|
|
337 | |
|
|
338 | =head2 INCREMENTAL PARSING |
|
|
339 | |
|
|
340 | In some cases, there is the need for incremental parsing of JSON |
|
|
341 | texts. While this module always has to keep both CBOR text and resulting |
|
|
342 | Perl data structure in memory at one time, it does allow you to parse a |
|
|
343 | CBOR stream incrementally, using a similar to using "decode_prefix" to see |
|
|
344 | if a full CBOR object is available, but is much more efficient. |
|
|
345 | |
|
|
346 | It basically works by parsing as much of a CBOR string as possible - if |
|
|
347 | the CBOR data is not complete yet, the pasrer will remember where it was, |
|
|
348 | to be able to restart when more data has been accumulated. Once enough |
|
|
349 | data is available to either decode a complete CBOR value or raise an |
|
|
350 | error, a real decode will be attempted. |
|
|
351 | |
|
|
352 | A typical use case would be a network protocol that consists of sending |
|
|
353 | and receiving CBOR-encoded messages. The solution that works with CBOR and |
|
|
354 | about anything else is by prepending a length to every CBOR value, so the |
|
|
355 | receiver knows how many octets to read. More compact (and slightly slower) |
|
|
356 | would be to just send CBOR values back-to-back, as C<CBOR::XS> knows where |
|
|
357 | a CBOR value ends, and doesn't need an explicit length. |
|
|
358 | |
|
|
359 | The following methods help with this: |
|
|
360 | |
|
|
361 | =over 4 |
|
|
362 | |
|
|
363 | =item @decoded = $cbor->incr_parse ($buffer) |
|
|
364 | |
|
|
365 | This method attempts to decode exactly one CBOR value from the beginning |
|
|
366 | of the given C<$buffer>. The value is removed from the C<$buffer> on |
|
|
367 | success. When C<$buffer> doesn't contain a complete value yet, it returns |
|
|
368 | nothing. Finally, when the C<$buffer> doesn't start with something |
|
|
369 | that could ever be a valid CBOR value, it raises an exception, just as |
|
|
370 | C<decode> would. In the latter case the decoder state is undefined and |
|
|
371 | must be reset before being able to parse further. |
|
|
372 | |
|
|
373 | This method modifies the C<$buffer> in place. When no CBOR value can be |
|
|
374 | decoded, the decoder stores the current string offset. On the next call, |
|
|
375 | continues decoding at the place where it stopped before. For this to make |
|
|
376 | sense, the C<$buffer> must begin with the same octets as on previous |
|
|
377 | unsuccessful calls. |
|
|
378 | |
|
|
379 | You can call this method in scalar context, in which case it either |
|
|
380 | returns a decoded value or C<undef>. This makes it impossible to |
|
|
381 | distinguish between CBOR null values (which decode to C<undef>) and an |
|
|
382 | unsuccessful decode, which is often acceptable. |
|
|
383 | |
|
|
384 | =item @decoded = $cbor->incr_parse_multiple ($buffer) |
|
|
385 | |
|
|
386 | Same as C<incr_parse>, but attempts to decode as many CBOR values as |
|
|
387 | possible in one go, instead of at most one. Calls to C<incr_parse> and |
|
|
388 | C<incr_parse_multiple> can be interleaved. |
|
|
389 | |
|
|
390 | =item $cbor->incr_reset |
|
|
391 | |
|
|
392 | Resets the incremental decoder. This throws away any saved state, so that |
|
|
393 | subsequent calls to C<incr_parse> or C<incr_parse_multiple> start to parse |
|
|
394 | a new CBOR value from the beginning of the C<$buffer> again. |
|
|
395 | |
|
|
396 | This method can be caled at any time, but it I<must> be called if you want |
|
|
397 | to change your C<$buffer> or there was a decoding error and you want to |
|
|
398 | reuse the C<$cbor> object for future incremental parsings. |
335 | |
399 | |
336 | =back |
400 | =back |
337 | |
401 | |
338 | |
402 | |
339 | =head1 MAPPING |
403 | =head1 MAPPING |
… | |
… | |
798 | perl core distribution (e.g. L<URI>), it is (currently) up to the user to |
862 | perl core distribution (e.g. L<URI>), it is (currently) up to the user to |
799 | provide these modules. The decoding usually fails with an exception if the |
863 | provide these modules. The decoding usually fails with an exception if the |
800 | required module cannot be loaded. |
864 | required module cannot be loaded. |
801 | |
865 | |
802 | =over 4 |
866 | =over 4 |
|
|
867 | |
|
|
868 | =item 0, 1 (date/time string, seconds since the epoch) |
|
|
869 | |
|
|
870 | These tags are decoded into L<Time::Piece> objects. The corresponding |
|
|
871 | C<Time::Piece::TO_CBOR> method always encodes into tag 1 values currently. |
|
|
872 | |
|
|
873 | The L<Time::Piece> API is generally surprisingly bad, and fractional |
|
|
874 | seconds are only accidentally kept intact, so watch out. On the plus side, |
|
|
875 | the module comes with perl since 5.10, which has to count for something. |
803 | |
876 | |
804 | =item 2, 3 (positive/negative bignum) |
877 | =item 2, 3 (positive/negative bignum) |
805 | |
878 | |
806 | These tags are decoded into L<Math::BigInt> objects. The corresponding |
879 | These tags are decoded into L<Math::BigInt> objects. The corresponding |
807 | C<Math::BigInt::TO_CBOR> method encodes "small" bigints into normal CBOR |
880 | C<Math::BigInt::TO_CBOR> method encodes "small" bigints into normal CBOR |
… | |
… | |
972 | service. I put the contact address into my modules for a reason. |
1045 | service. I put the contact address into my modules for a reason. |
973 | |
1046 | |
974 | =cut |
1047 | =cut |
975 | |
1048 | |
976 | our %FILTER = ( |
1049 | our %FILTER = ( |
977 | # 0 # rfc4287 datetime, utf-8 |
1050 | 0 => sub { # rfc4287 datetime, utf-8 |
978 | # 1 # unix timestamp, any |
1051 | require Time::Piece; |
|
|
1052 | # Time::Piece::Strptime uses the "incredibly flexible date parsing routine" |
|
|
1053 | # from FreeBSD, which can't parse ISO 8601, RFC3339, RFC4287 or much of anything |
|
|
1054 | # else either. Whats incredibe over standard strptime totally escapes me. |
|
|
1055 | # doesn't do fractional times, either. sigh. |
|
|
1056 | # In fact, it's all a lie, it uses whatever strptime it wants, and of course, |
|
|
1057 | # they are all incomptible. The openbsd one simply ignores %z (but according to the |
|
|
1058 | # docs, it would be much more incredibly flexible indeed. If it worked, that is.). |
|
|
1059 | scalar eval { |
|
|
1060 | my $s = $_[1]; |
|
|
1061 | |
|
|
1062 | $s =~ s/Z$/+00:00/; |
|
|
1063 | $s =~ s/(\.[0-9]+)?([+-][0-9][0-9]):([0-9][0-9])$// |
|
|
1064 | or die; |
|
|
1065 | |
|
|
1066 | my $b = $1 - ($2 * 60 + $3) * 60; # fractional part + offset. hopefully |
|
|
1067 | my $d = Time::Piece->strptime ($s, "%Y-%m-%dT%H:%M:%S"); |
|
|
1068 | |
|
|
1069 | Time::Piece::gmtime ($d->epoch + $b) |
|
|
1070 | } || die "corrupted CBOR date/time string ($_[0])"; |
|
|
1071 | }, |
|
|
1072 | |
|
|
1073 | 1 => sub { # seconds since the epoch, possibly fractional |
|
|
1074 | require Time::Piece; |
|
|
1075 | scalar Time::Piece::gmtime (pop) |
|
|
1076 | }, |
979 | |
1077 | |
980 | 2 => sub { # pos bigint |
1078 | 2 => sub { # pos bigint |
981 | require Math::BigInt; |
1079 | require Math::BigInt; |
982 | Math::BigInt->new ("0x" . unpack "H*", pop) |
1080 | Math::BigInt->new ("0x" . unpack "H*", pop) |
983 | }, |
1081 | }, |
… | |
… | |
1019 | } |
1117 | } |
1020 | |
1118 | |
1021 | sub URI::TO_CBOR { |
1119 | sub URI::TO_CBOR { |
1022 | my $uri = $_[0]->as_string; |
1120 | my $uri = $_[0]->as_string; |
1023 | utf8::upgrade $uri; |
1121 | utf8::upgrade $uri; |
1024 | CBOR::XS::tag 32, $uri |
1122 | tag 32, $uri |
1025 | } |
1123 | } |
1026 | |
1124 | |
1027 | sub Math::BigInt::TO_CBOR { |
1125 | sub Math::BigInt::TO_CBOR { |
1028 | if ($_[0] >= -2147483648 && $_[0] <= 2147483647) { |
1126 | if ($_[0] >= -2147483648 && $_[0] <= 2147483647) { |
1029 | $_[0]->numify |
1127 | $_[0]->numify |
1030 | } else { |
1128 | } else { |
1031 | my $hex = substr $_[0]->as_hex, 2; |
1129 | my $hex = substr $_[0]->as_hex, 2; |
1032 | $hex = "0$hex" if 1 & length $hex; # sigh |
1130 | $hex = "0$hex" if 1 & length $hex; # sigh |
1033 | CBOR::XS::tag $_[0] >= 0 ? 2 : 3, pack "H*", $hex |
1131 | tag $_[0] >= 0 ? 2 : 3, pack "H*", $hex |
1034 | } |
1132 | } |
1035 | } |
1133 | } |
1036 | |
1134 | |
1037 | sub Math::BigFloat::TO_CBOR { |
1135 | sub Math::BigFloat::TO_CBOR { |
1038 | my ($m, $e) = $_[0]->parts; |
1136 | my ($m, $e) = $_[0]->parts; |
1039 | CBOR::XS::tag 4, [$e->numify, $m] |
1137 | tag 4, [$e->numify, $m] |
|
|
1138 | } |
|
|
1139 | |
|
|
1140 | sub Time::Piece::TO_CBOR { |
|
|
1141 | tag 1, $_[0]->epoch |
1040 | } |
1142 | } |
1041 | |
1143 | |
1042 | XSLoader::load "CBOR::XS", $VERSION; |
1144 | XSLoader::load "CBOR::XS", $VERSION; |
1043 | |
1145 | |
1044 | =head1 SEE ALSO |
1146 | =head1 SEE ALSO |