八张图里多出来的一次转义

有一段时间，这个博客的八篇文章在句子中间显示的是 — 这七个字符，而且是在图表里。不是破折号。是文字本身。此后所有语言都已修正。

81 行，91 处。而在同样这八篇文章的正文里：一处都没有。

多转义了一次

图表是内嵌 SVG，写在文章正文里。一条想要破折号的标签带的是 —，浏览器会把它变成破折号，和在段落里完全一样。

但存下来的是 —。浏览器老老实实把它变成拼出一个实体的那几个字符，然后画了出来。正文没有受影响，因为它从来没有经过那个多加转义的环节；经过的只有标签，而且只有那些标签是在当时生成的文章。

成因很小，也很乏味。值得写下来的是：它为什么在众目睽睽之下待了那么久，以及是什么结束了它。

检查看见了它，说的却是别的

有一个检查在量图表标签是否放得进它所在的图。它已经报告这些标签好几天了 — 说它们太宽。

它们确实太宽。一条画七个字符而不是一个字符的标签，比预想的宽了大约四十五像素，所以测量是对的，报告也是对的。不对的是读这份报告的人会得出的结论。数字说的是几何太紧。真相是这段文字并不是它看上去的那个东西。

这就是这件事的形状。检查回答的是交给它的问题，它无法报告说问题问错了。这里没有任何东西被量错；只是这次测量涉及的问题，和它看上去涉及的那个并不相同。

是什么找到了它

渲染一张图，然后看它。无窗口的 Chromium，一张截图，十秒钟。那个实体就在图的第三行，字号和其他一切一样大。

修复是一次迁移：把 & 换成 &，只针对一份固定的实体名单，也只在 <svg class="dg"> 块里面，这样一个本来就该是与号的与号仍然是与号。不在名单上的一律报告出来、原样留着，而不是去猜。全部 81 行在每种语言里都已更正；博客里剩下的，只有本文有意引用的那些。

这件事的一般化

这个项目里的每一个自动检查量的都是数值上的东西，因为数字才是程序能比较的。没有一个能看出一张图变成了胡话，一个框空着，或者一个该用符号的地方被拼成了字。

由此得出的规则很短：图表每改一次，就渲染一张出来看看，用最占地方的那种语言。它已经抓到了两件任何测量都抓不到的事 — 这一件，以及一个图注被挪走之后留下的空框。