Protocols

For being an extremely simple format, NBT has a few different "flavors" that are all widely used to add some more challenge in creating a single API surface that covers all of them. While SharpNBT abstracts all this away to consumers of the library with a single enumeration setting, it is important to understand the differences for what you might encounter in the wild if building tooling based on this library.

Java

While there are a few minor changes since the original Notchian version since Mojang took over, this is the "standard" format that is most synonymous with what the NBT format is, and is used as the "baseline" from which the differences in the others is described.

Numeric types are all typical signed fixed-length integers, of the 8-bit, 16-bit, 32-bit, and 64-bit variety, with the sole exception of strings being prefixed with an unsigned 16-bit value. All use big-endian for their byte order, which is the only real issue to be aware of in a little-endian dominated ecosystem.

Bedrock

Here is where things begin to get interesting. Since Microsoft acquired Mojang, there have been some rather large changes to the NBT format used in Bedrock editions of Minecraft.

File

When writing to a file, the Bedrock format is identical to the Java version with the exception that it uses little-endian for all numeric types. No big deal, easily accounted for since byte order is already going to be something being checked for.

Network

When transporting over a network, the Bedrock format makes some rather drastic changes.

• All numeric types use variable-length integers
• Most numeric types are also use Zig-zag encoding with the VarInt and VarLong types. This encoding differs from the VarInt and VarLong types common to the Minecraft protocol, and is based on the Protobuf varint.
• Length prefixes for strings is a VarInt, but it is not Zig-zag encoded, but in the Minecraft-compatible style.

...thank you, Microsoft.