如何为42,866个阿尔卑斯地点设计永不改变的URL？

从哈希到语义URL：为什么需要稳定链接

biwak.info 是我做的阿尔卑斯山地图，收录小屋、露营地和具名山峰，数据全部来自 OpenStreetMap：9,429 个小屋/露营地，33,437 个具名山峰，加起来 42,866 个地点。来源：BPPA 很长一段时间里，这个站点唯一的链接方式是一个 `#Name` 哈希——它做精确名称匹配，名称不唯一时就回退到搜索。这种链接能打开页面，但有个要命的缺陷：你把它发给朋友，对方看到的是带 `#` 的 URL，聊天工具里不会生成像样的预览卡片，而且一旦名称有变，链接就指向错误的地方。

我想要真正可分享的 URL。我希望是 `/p/matterhorn` 这样的短路径，能显示预览卡片，能稳定指向同一个地点。来源：BPPA 这件事听起来简单——把名字转成 URL 而已。但把 42,866 个地点全转一遍，我才发现真正难的不是生成 URL，而是保证它永远不失效。

顺带一提，Hacker News 上这篇帖子的标题写的是 "42,000 Huts and Peaks"，而文章里精确统计是 42,866。差出来的 866 是标题做了四舍五入，不是数据对不上。来源：HH 这个帖子目前只有 1 分、0 评论，说明这个技术细节还没引起社区讨论，但不妨碍它值得拆开看看。

slugify 实现：从德语变音到 ASCII 的确定性转换

转 URL 的第一步是 slugify，也就是把任意名称变成 URL 安全的 slug。作者用 Python 写了一段相当干净的代码。先用 `str.maketrans` 定义一张映射表，专门处理德语变音：`ä→ae`、`ö→oe`、`ü→ue`，大小写都覆盖，再加上 `ß→ss` 和 `ẞ→ss`，共 8 条规则。来源：BPPA 这张表是硬编码的，不是通用方案，但处理德语地名足够用了。

接下来用 `unicodedata.normalize('NFKD', text)` 做 Unicode 规范化，把重音字符拆成基字符加组合符号，再编码为 ASCII 并忽略错误。这一步把 `Štuhecov dom` 里的 `š` 折叠成 `s`，把 `Rifugio Città di Busto` 里的 `à` 折叠成 `a`。最后用正则 `re.sub(r'[^a-z0-9]+', '-', text)` 把连续的非字母数字字符替换成单个连字符，`strip('-')` 去掉首尾多余的连字符。来源：BPPA

效果很直观：`Oberaletschhütte` 变成 `oberaletschhuette`，`Štuhecov dom` 变成 `stuhecov-dom`，`Rifugio Città di Busto` 变成 `rifugio-citta-di-busto`。来源：BPPA 作者特意验证过，全部 42,866 个名称经 slugify 后没有任何一个是空字符串。这个结果本身不意外，但放在大规模地名数据库里，它意味着第一步的确定性转换不会吞掉任何地点。

重名与稳定性：注册表机制与反直觉发现

真正的难点不在 slugify，而在重名。阿尔卑斯山的地名重复率极高：每个山谷都有它的 Jagdhütte 和 Rosskopf。作者做了一个统计，最常见的前五个 slug 分别是 jagdhuette（70 处）、schwarzkogel（37 处）、buchberg（32 处）、rosskopf（32 处）、mitterberg（31 处）。来源：BPPA 也就是说，只用名字做 slug，70 个不同的地方会撞进同一个 URL。

作者测试了四种后缀方案，看它们能消除多少重名。只用名字：2,181 个共享 slug，影响 6,690 个地点，占 15.6%，最坏情况 70 个地点共用一个 slug。加上国家代码：共享 slug 降到 1,993 个，但影响面仍有 5,936 个地点，占 13.8%，最坏 64 个。加上区域（region）：共享 slug 降到 1,516 个，影响 3,932 个地点，占 9.2%，最坏 27 个。最后加上海拔：共享 slug 只剩 118 个，影响 394 个地点，占 0.9%，最坏 21 个。来源：BPPA 海拔是个强判别维度，但即便这样也没法彻底消除重名。

作者的解决策略是分层消歧义：唯一名称直接用简化 slug；共享名称则依次附加区域、海拔、OpenStreetMap ID，直到唯一。但这还不够，因为 URL 一旦分享出去，就不能再变。于是作者引入了一个"已提交注册表"（committed registry）机制，确保 slug 永远不会指向另一个地点——URL 一旦分配就固定不变。来源：BPPA 这个机制背后有个反直觉的洞察：生成 URL 容易，长期稳定难。用作者自己的话说，"a URL, once shared, should keep pointing to the same place, even when the data changes underneath"。来源：BPPA 旧方案 `#Name` 依赖精确名称匹配，名称不唯一时回退搜索，链接天生不稳定；新方案用确定性规则加注册表，把"名称→URL"变成一次性提交，后续数据变化不影响已分配的链接。

多源交叉验证与社区反馈

数据源是 OpenStreetMap，一个由社区贡献的开放数据库，内容随时会变。作者特别强调，正是因为数据会变，注册表机制才如此重要——否则你今天分享的链接，下周可能就指向另一座山了。来源：BPPA 来源：OSM 这个思路放在更广的语境下也成立：任何依赖外部数据的系统，只要对外暴露 URL，就得考虑数据变动对链接稳定性的冲击。

再看社区反应。HN 标题的 "42,000" 和文章的 42,866 差了 866，这是四舍五入的产物，说明标题用了约数，实际数据更精确。来源：HH 目前 HN 上 0 条评论，1 分，这在小众技术方案里不稀奇——它解决的问题很具体，不值得大众讨论，但做地理信息系统或 URL 设计的人应该留意。来源：HH 我会这样判断：这个方案对单站点有效，但如果哪天有人想推广到全世界的山峰数据库，注册表机制需要处理跨站合并和冲突，那才是真正考验它的时候。

原文：

Stable URLs for 42,000 Huts and Peaks · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年11月8日