Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>When looking at what characters are encoded by the hexadecimal strings, you can see that the first one decodes to</p> <pre><code>'\x81\xa7api_key\xd9 ad09739ac168ff2a199fb24eb4e24db8' # Python's version </code></pre> <p>while the second one decodes to</p> <pre><code>'\x81\xa7api_key\xda\x00 ad09739ac168ff2a199fb24eb4e24db8' # ObjC's version </code></pre> <p>The third, 30 bytes long string, decodes to </p> <pre><code>'\x81\xa7api_key\xbead09739ac168ff2a199fb24eb4e24d' # both versions </code></pre> <p>Intrigued by the problem, I googled for MsgPack's specs and came across <a href="https://github.com/msgpack/msgpack/blob/master/spec.md#formats-str" rel="nofollow">this</a>.</p> <p>Now things are getting clearer.</p> <ul> <li><code>\x81</code> says that the following is a one-element map.</li> <li><code>\xA7</code> says that the following is a seven-character string.</li> <li><code>api_key</code> is that seven-character string. </li> </ul> <p>So far, so good. Now the differences begin:</p> <ul> <li><code>\xd9</code> says that a <code>str8</code> string follows. The byte after <code>\xd9</code> is <code>\x20</code> (<code>hex 20 == dec 32 == ASCII space</code>). It denotes the length of that string (32). That's what Python uses, correctly, because <code>str8</code> is usable for strings of up to 255 characters in length.</li> <li><code>\xda</code> says that a <code>str16</code> string follows. The following two bytes are <code>\x00\x20</code> (<code>hex 0020</code> == <code>dec 32</code>, as before). They also denote the length of the following string (32 again). That's what ObjC does, apparently. This is just as legal from the spec's point of view, just a little wasteful (one wasted byte).</li> <li>For strings of less than 32 characters, both implementations use a <code>fixstr</code> type that encodes a length of 1-31 characters in the bitfield <code>101xxxxx</code> which becomes <code>\xbe</code> for a 30-character string (<code>bin 10111110</code>). </li> </ul> <p>So it seems that all the serializations are correct, but the deserializer you're using can't handle the <code>str8</code> datatype used by Python's serializer. The <a href="https://github.com/msgpack/msgpack/blob/master/spec.md#impl" rel="nofollow">implementation guidelines</a> state that dut to format changes, not all releases support <code>str8</code>, so that serializers should provide a compatibility mode without it. Python's <code>msgpack</code> package doesn't, though.</p> <p><strong>UPDATE:</strong> Just a few hours after the <a href="https://github.com/msgpack/msgpack/issues/156" rel="nofollow">bug report</a>, the developer of <a href="https://github.com/vsergeev/u-msgpack-python" rel="nofollow"><code>msgpack-Python</code></a> has added a compatibility switch to force Python to create <code>str16</code> serializations instead of <code>str8</code>. Well done!</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload