编程与软件工程blog.jgc.org
10:10 编码：把坐标塞进极短字符串
The 10:10 Code
2010 — 2014，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇博文介绍了作者设计的“10:10 Code”：一种把经纬度编码成简短、便于口头或短信传达的字符串的方案。根据评论可知，其核心做法是对经纬度做线性缩放后用 Base32 编码，并在末尾加入校验信息。文章也引出了与 GeoHash 等地理编码方案在精度、可存储性和输入便利性上的权衡。
为什么经久不衰：它用一个简单巧妙的短码设计，引出地理编码中精度、校验、可读性和国际化等经典权衡，今天仍是理解位置短编码的好例子。
HN 评论精选
指出方案本质是线性缩放加 Base32 和校验，并追问校验算法的性质与选择理由。
据我所知，“10:10 Code”只是对经度和纬度做线性重新缩放，然后用 Base32 编码（最后四个比特是校验和）。如果确实如此，为什么不这样解释？这样误差行为就很清楚：因为是线性编码，去掉校验和之前的比特就能平滑降低精度。这个校验和有什么编码性质？它看起来不像 CRC32 或 Adler，具体是什么？为什么选它？
dododo查看英文原文
as far as i can tell, the "10:10 code" is just a linear rescaling of the longitude and lattitude then encoding in base 32 (with a checksum for the last four bits). if the above is correct, why not explain it thus? if you do this, it becomes obvious what happens to errors; we know you can gracefully degrade the accuracy (since it's a linear encoding) by dropping the bits before the checksum. what are the coding properties of the checksum? it doesn't look like crc32 or adler. what is it? why did you choose it?
对比 GeoHash 的可变精度，并提醒短码不宜替代可查询的空间存储格式。
也可参考 GeoHash，它允许从末尾删除字符并逐步损失精度。我认为这类编码的大问题是：虽然便于传输，但不应直接用来存储位置，因为那样会失去邻近查询或“点是否在多边形内”搜索的能力。
showerst查看英文原文
See also the GeoHash, which lets you remove characters from the end at a gradual loss of precision: http://en.wikipedia.org/wiki/Geohash In my mind the big issue with these is that while they're easy to transmit, you don't actually want to store them because then you lose the ability to do proximity or point in polygon searches.
提出用上下文补全缺失前缀的后缀式短码，以兼顾短小和任意精度。
这用了不少位数。有意思的是把经纬度比特交错排列，使任意前缀都是低分辨率的有效编码，并能任意追加位数提高精度；GeoHash 似乎就是这样？但短码只精确到一英里左右多半没用，用后缀比前缀更好。可以先固定一个精度单位（比如 10 米），短码被理解为最低有效位，缺失的前缀由接收者当前位置补全：同城的人告诉对方 YA9 即可，若要更精确就写成 YA9.7R。甚至可像 Mapcode 那样用 US-DC、YA9 让地点提供上下文。
adamtj查看英文原文
That's a lot of digits. It would be interesting to interlace the latitude and longitude bits in such a way that any prefix is a valid code of reduced resolution, and you can add arbitrarily many digits for increased precision. I think geohash does this? Or does reducing precision give you a geohash that isn't a prefix? Anyway... Each digit of such a code might be roughly equivalent to one decimal digit of both latitude and longitude. For example, maybe the first three digits would get you to within about a nautical mile. But that's dumb. While short codes are nice, a short code that only gets you within a mile is mostly useless. It would be better to use a suffix than a prefix. You can still get arbitrary precision with a decimal point. First, specify a fixed "unit" of precision. Say 10m. Any short code is assumed to be the least significant digits. If my math is right, you could specify any point closer than 2 km +/- 10 m using maybe 2 digits. Most buildings in most cities will need maybe 3-5 digits. You could invite somebody from the same city to your house, telling them you live at YA9. Their GPS would assume that the missing prefix digits match their current location. If you want to give them the location of the centerpiece on your dining room table, you could add a decimal point and more precision: YA9.7R. You could even use short-codes that look like Mapcodes: US-DC, YA9. The location provides the context for the missing prefix digits. But you always have the option of specifing the full code to avoid ambiguity or lookup tables. One problem is the check digit. Maybe there's a way to interlace the check bits too, so you don't need a full check digit for every code. Is there a checksum algorithm where a prefix of the checksum is a checksum of a prefix? That obviously couldn't detect a one-digit typo. Or, maybe just put a check digit at end. All codes become 2 digits minimum. The checksum algorithm wouldn't need to be fancy since you can assume the rest of the digits based on your current location. Another easily fixed problem is mentioned on the Geohash wikipedia page: locations near the equator and prime meridian could have wildly different codes than other locations nearby. The solution to that is easy: Translate lat/lon into a different system. Translate latitude into a number from 0 to 180, with 0 being the south pole. Similarly translate longitude to a number from 0 to 360, with 0 being at the international date line. Then encode those translated numbers. Nobody would ever see those intermediate numbers. You always display either lat/lon or the code, but the translation ensures that you don't have vastly different codes for nearby places (at least in any place with a significant number of people).
指出基于字母表的编码会受语言和键盘差异影响，通用性有限。
一个问题是字母差异，所以它并不完全通用。例如不少语言没有字母 Q（比如斯拉夫语系）。
ErrantX查看英文原文
One problem is letter differences; so it's not quite universal. For example a surprising number of languages do not have the letter Q (slavic languages for example)
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选