我已经阅读了大量与此问题相关的网络信息，但仍未找到明确的答案。
我的目标是建立一个国际象棋棋局数据库，能够识别移位（通常是哪些棋子在哪些位置）。
编辑：它还应该能够识别相似（但不完全相同）的棋局。
这是一个20年前的讨论（当时空间是个问题）：https://groups.google.com/forum/#!topic/rec.games.chess.computer/wVyS3tftZAA
其中一位参与者谈到了如何将棋子编码到一个方形矩阵中，使用4 x 64位加上额外信息（如王车易位、吃兵等）的几个比特： 有六种棋子（步兵、车、马、象、后、王）加上一个空格，需要3比特（2^3），再加上1比特来表示棋子的颜色。
总共会有4个64位数字，再加上一些额外信息。
问题：是否有其他更有效的存储国际象棋棋局的方法？
我应该提到这个问题是以数据库为中心，而不是以游戏为中心的（也就是说，我的唯一兴趣是高效地存储和检索，而不是创建任何人工智能或生成任何棋招）。
谢谢， Adrian
这是一个22字节的快速内部建议（受到哈夫曼编码的启发）。解码/编码不是很容易，但也不难。严肃的程序可能有更好的技巧。
现在来看特殊情况：
因此，不考虑升变的情况下：164 + 1 + 3 = 168位 = 21字节； 如果考虑到8个皇后升变的极端情况：22字节；
这是我能够为内部解决方案做出的最好贡献。
紧凑且相对易懂，最坏情况下（或者总是这样方便的话）完整位置规范需要25个字节：
000：普通兵；001：刚刚向上移动两个位置的兵；010：马；011：象；100：未移动过的车或其王；101：已经移动过的车或其王；110：后；111：王。
附加信息需要1个字节：
0y111用于跳过空格。由于许多情况下片段是相邻的，因此您省略了位置信息： All pieces are followed by color bit
0y000c 0 Pawn
0y001c 1 Rook
0y010c 2 Knight
0y011c 3 Bishop
0y100c 4 Queen
0y101c 5 King
0y110 6 Empty space
0y111 7 Repeat next symbol (count is next 6 bits, then symbol)
12354321 Literal white encoding from a1 to h1 32 bits
7 8 0 repeat white pawn 8 times 13 bits
7 32 6 repeat 32 empty spaces 12 bits
7 8 8 repeat black pawn 8 times 13 bits
9abcdba9 Literal encoding of black 32 bits
---------
102 bits total
话虽如此，变长编码的额外复杂性和不确定性可能不值得节省空间。此外，在某些情况下，它可能比固定宽度格式更糟糕。
存储棋盘信息有两种简单方法：一种是存储每个棋子的位置，另一种是为每个方格存储其中的内容。
正如Mitch所解释的那样，可以使用RLE进行一定程度的压缩，但给出的示例是起始位置，这特别容易描述。在棋子分布在棋盘上的另一种情况下，你可能会看到空间和棋子交替，而RLE不会压缩任何东西。因此，除非使用更复杂的算法，否则无法进行压缩。
我认为jlahd在计算中犯了一个错误，将中心兵算了两次，因此实际上存储每个棋子位置所需的空间不是188位，而是168位。此外，还需要存储兵是否已晋升。因此，就兵而言，有(32 + 4x64)^16种可能性。总共需要223位=28字节。
如果我们为每个方格存储其内容，我们需要计算一个方格上的可能性。对于大多数方格，有6种可能的白色棋子和同样数量的黑色棋子。对于顶部和底部行，一种颜色的兵不能出现。因此，中心方格有13种可能性，顶部和底部方格有12种可能性，因此有13^48 x 12^16 种可能性。吃过路兵的位置有17种可能性。因此，大约需要240位。
总之，似乎通过存储棋子位置而不是每个方格的内容可以节省12.5%的空间。
我的两分钱
32字节（4 * 64位）是相当少的数据量。1000万个国际象棋位置可以放入30GB中。192位是24字节，这将变成23GB。可能数据库使用某种压缩技术，因此磁盘上的数据可能比这些数字少。我不知道存储的限制是什么，但由于这些编码似乎非常紧凑，所以尝试进一步最小化可能没有价值。
因为需要查找相似位置，所以我认为编码应该使比较不同位置变得容易。最好能够在不解码的情况下进行计数。为了实现这一点，编码可能应该是恒定长度的（无法想到使用可变长度编码的简单方法）。
索引可能加速相似性搜索。天真的方法是通过数据库中的位置索引所有位置。这将使得有32个索引（也许还有其他附加信息）。至少在理论上，这将使搜索变得非常快。
索引需要占用相当多的空间。可能比实际的位置数据还要多。而且它们可能并没有那么大的帮助。例如，查找黑色国王所在或接近e4的位置需要使用索引进行9次搜索，然后在30GB的位置信息中跳来跳去，这很可能需要随机访问磁盘位置。而且可能需要为一个以上的棋子查找类似的位置...
如果存储格式高效，仅仅通过暴力搜索所有位置数据并逐个检查相似位置就足够了。这将有效地利用CPU缓存。此外，由于记录长度恒定，因此可以轻松地将工作分配给多个处理器或计算机。
使用以棋子为中心或基于棋盘的存储格式取决于您将如何计算两个位置之间的相似性。以棋子为中心的方法可以轻松计算两个不同位置中一枚棋子的距离。然而，在以棋子为中心的方法中，每个棋子都是单独标识的，因此在特定位置找到一个兵并不容易。必须检查每个兵的位置。如果棋子的身份不是很重要，则基于棋盘的存储使得仅需检查兵是否在所需位置变得容易。另一方面，无法检查确切的兵是哪一个。