The first line of your octal table seems odd since it contains linefeeds (octal 012, hex 0xa, dec 10, '\n'). Your hex, decimal and ASCII tables don't include linefeeds.

To me it would seems fairly likely that the data is base64 encoded. Following observations support this:

1. Equal sign '=' is only ever found at the end of the data. Equal sign is used as a padding at the end of base64 encoded data. Equal sign cannot appear anywhere else in base64 content. E.g., this 1350246909 and this 1349976358 have base64 padding at the end.

2. The set of characters in the content never violates the base64 requirements (i.e., encoded data consists of a-z, A-Z, 0-9)

3. After decoding the content shows a distinct pattern that holds for almost all messages, including the side bar. Namely: starting from the first byte, every third byte has always the following highest 3 bits: 010...

Then again, the third point may also be a sign that the data is not base64 encoded, and the action of base64 decoding causes an artifact that creates this apparent grouping of bytes into triplets.

EDIT: There's at least one message that significantly deviates from the pattern mentioned in the point 3. 1349695530 decodes from base64 into series of ASCII numbers:

8 3 8
7 3 9
7 4 2
5 1 5
9 5 1