区块格式(Chunk_format)

a

区块（Chunks）以16*256*16立方块为单位存储地形和实体信息。为了提高Minecraft的运行效率，区块同时储存预处理的光照、等高线数据及其他元数据信息。

“区块”概念在Minecraft Infdev阶段时首次引进。 在Beta 1.3版本引进MCRegion之前, Minecraft以36进制编码的区块坐标为文件名，将区块信息储存在独立的“.dat”文件中（Alpha level format）。为了减少磁盘占用，MCRegion将地平面上32*32平方块内的所有区块打包存储在以十进制编码的区块坐标为文件名的“.mcr”文件中；这种存储方式降低了Minecraft运行时同时打开的文件数量。MCRegion后来被当下的Anvil文件格式取代，新格式沿用了MCRegion打包存储的方法，并使用了新的“.mca”文件格式。

Anvil文件格式相比MCRegion最大的改进是将区块分割，一个16*256*16大小的区块最多能分割出16个16*16*16的部分，所以全空区域的数据可以不被保存。支持的方块ID也从以前的0到255调整为0到4095，不过现在（2012年11月22日时）Minecraft还不能完美实现ID从0到4095的所有方块的存储，且256到4095的这些方块ID有很多已经被物品占用。

现在（2012年11月22日时），方块的辅助信息独立地被保存在区块信息内，特别的，天空光照（SkyLight）和（BlockLight）两个数组信息不在挂在方块ID后。Anvil文件格式出现后, 开发组在Notch原先设想的基础上对NBT格式（二进制命名标签格式）做出了改变，添加了一个和字节数组标签（byte array tag）相近的整数数组标签（integer array tag）——只有区块的等高线信息使用NBT格式存储。

又见: information from the Anvil format page 区块使用NBT格式存储时遵循以下结构：

In the Anvil format, block positions are ordered YZX for compression purposes.

The coordinate system is as follows:

Each section in a chunk is a 16x16x16-block area, with up to 16 sections in a chunk. Section 0 is the bottom section of the chunk, and section 15 is the top section of the chunk. To save space, completely empty sections are not saved. Within each section is a byte tag "Y" for the Y index of the section, 0 to 15, and then byte arrays for the blocks. The "Block" byte array has 4096 partial block IDs at 8 bits per block. Another byte array "Add" is used for block with IDs over 255, and is 2048 bytes of the other part of the 4096 block IDs at 4 bits per block. When both the "Block" and "Add" byte arrays exist, the partial ID from the "Add" array is shifted left 8 bits and added to the partial ID from the "Blocks" array to form the true Block ID. The "Data" byte array is also 2048 bytes for 4096 block data values at 4 bits per block. The "BlockLight" and "SkyLight" byte arrays are the same as the "Data" byte array but they are used for block light levels and sky light levels respectively. The "SkyLight" values represent how much sunlight or moonlight can potentially reach the block, independent of the current light level of the sky.

The pseudo-code below shows how to access individual block information from a single section. Hover over text to see additional information or comments.

Every entity is an unnamed TAG_Compound contained in the Entities list of a chunk file. The sole exception is the Player entity, stored in level.dat, or in <player>.dat files on servers. All entities share this base:

每个生物都有额外的标签来储存它们的血量, 状态，效果. Players 是一个生物的子类.

Projectiles are a subclass of Entity and have very obscure tags such as X,Y,Z coordinate tags despite Entity Pos tag, inTile despite inGround, and shake despite most projectiles not being arrows.

Items are a subclass of Entity.

Vehicles are subclasses of Entity.

Dynamic tiles are a subclass of Entity and are used to simulate realistically moving blocks.

Other entity types that are a subclass of Entity but do not fit into any of the above categories.

Tile Entities (not related to Entities) are used by Minecraft to store information about blocks that can't be stored in the 4-bits of block data the block has.

All tile entities share this base:

Only the first 16 characters of each line are read, the rest are discarded.

Tile Ticks represent block updates that need to happen because they could not happen before the chunk was saved. Examples reasons for tile ticks include redstone circuits needing to continue updating, water and lava that should continue flowing, recently placed sand or gravel that should fall, etc. Tile ticks are not used for purposes such as leaf decay, where the decay information is stored in the leaf block data values and handled by Minecraft when the chunk loads. For map makers, tile ticks can be used to update blocks after a period of time has passed with the chunk loaded into memory.