说到这，你可能会有疑问了，在实际工作中，用户对应的都是实际的地理位置坐标，那它和二维空间的区域编码又是怎么联系起来的呢？别着急，我们慢慢说。
实际上，我们会将地球看作是一个大的二维空间，那经纬度就是水平和垂直的两个切分方向。在给出一个用户的经纬度坐标之后，我们通过对地球的经纬度区间不断二分，就能得到这个用户所属的区域编码了。这么说可能比较抽象，我来举个例子。
我们知道，地球的纬度区间是[-90,90]，经度是[-180,180]。如果给出的用户纬度（垂直方向）坐标是 39.983429，经度（水平方向）坐标是 116.490273，那我们求这个用户所属的区域编码的过程，就可以总结为 3 步：
- 在纬度方向上，第一次二分，39.983429 在[0,90]之间，[0,90]属于空间的上半边，因此我们得到编码 1。然后在[0,90]这个空间上，第二次二分，39.983429 在[0,45]之间，[0,45]属于区间的下半边，因此我们得到编码 0。两次划分之后，我们得到的编码就是 10。
- 在经度方向上，第一次二分，116.490273 在[0,180]之间，[0,180]属于空间的右半边，因此我们得到编码 1。然后在[0,180]这个空间上，第二次二分，116.490273 在[90,180]之间，[90,180]还是属于区间的右半边，因此我们得到的编码还是 1。两次划分之后，我们得到的编码就是 11。
- 我们把纬度的编码和经度的编码交叉组合起来，先是经度，再是纬度。这样就构成了区域编码，区域编码为 1110。
你会发现，在上面的例子中，我们只二分了两次。实际上，如果区域划分的粒度非常细，我们就要持续、多次二分。而每多二分一次，我们就需要增加一个比特位来表示编码。如果经度和纬度各二分 15 次的话，那我们就需要 30 个比特位来表示一个位置的编码。那上面例子中的编码就会是 11100 11101 00100 01111 00110 11110。
这样得到的编码会特别长，那为了简化编码的表示，我们可以以 5 个比特位为一个单位，把长编码转为 base32 编码，最终得到的就是 wx4g6y。这样 30 个比特位，我们只需要用 6 个字符就可以表示了。
这样做不仅存储会更简单，而且具有相同前缀的区域属于同一个大区域，看起来也非常直观。这种将经纬度坐标转换为字符串的编码方式，就叫作 Geohash 编码。大多数应用都会使用 Geohash 编码进行地理位置的表示，以及在很多系统中，比如，Redis、MySQL 以及 Elastic Search 中，也都支持 Geohash 数据的存储和查询。
那在实际转换的过程中，由于不同长度的 Geohash 代表不同大小的覆盖区域，因此我们可以结合 GeoHash 字符长度和覆盖区域对照表，根据自己的应用需要选择合适的 Geohash 编码长度。这个对照表让我们在使用 Geohash 编码的时候方便很多。
不过，Geohash 编码也有缺点。由于 Geohash 编码的一个字符就代表了 5 个比特位，因此每当字符长度变化一个单位，区域的覆盖度变化跨度就是 32 倍（2^5），这会导致区域范围划分不够精细。
因此，当发现粒度划分不符合自己应用的需求时，我们其实可以将 Geohash 编码转换回二进制编码的表示方式。这样，编码长度变化的单位就是 1 个比特位了，区域覆盖度变化跨度就是 2 倍，我们就可以更灵活地调整自己期望的区域覆盖度了。实际上，在许多系统的底层实现中，虽然都支持以字符串形式输入 Geohash 编码，但是在内存中的存储和计算都是以二进制的方式来进行的。
