可调节哑铃片的一对哑铃，发现份量不对。经过称量和讨论，确定了折算公式，缺1/4。

1. 偶然发现

一对哑铃，2根杆，4个锁紧螺丝；哑铃片共4种不同份量，每种4个。4种哑铃片分别标称2.5kg、2kg、1.25kg、0.75kg。组合出不计杆每只 (2+1.25+0.75)*2 =8kg，兴致勃勃练了一段时间。觉得小有进步，可以调高份量了。

忘了因为什么，可能是想把杆重算进去，也可能为了方便以前一直用的固定重量哑铃对比，总之偶然想到称重一下。不称要不紧，一称发现份量不对，缺斤少两。

如下两图所示，标称750g的，称重结果为431g；标称1.25kg的，称重808kg。标称相同的4个哑铃片重量上下略有浮动，十几或几十克，容易理解。但是标称与称重结果差距这么大，就没法用误差解释了。

我锻炼的时候写日志，要记录重量。以后吹牛时，哑铃片的份量也得如实才行啊。不然，在家里举8kg，在别的地方别人面前一显摆，8kg根本举不起来，岂不尴尬。哑铃仅仅重量不准，毕竟这么沉重，又不能扔了，那么想办法找到真实重量标定一下吧。

2. 猜测

猜测上面写的数字的单位不是kg，而是磅，这个重小的重量单位。

换算了一下，手头现有的数字不符合磅和公斤的换算关系。

标称	称重（g）
0.75	443
1.25	808

在网上查到 https://forum.xitek.com/thread-1772754-1-1.html 在 bing 的 cache 中，PCM120说的情况跟我的差不多。

: 我的哑铃用了将近有二十年了，一直没注意重量是否符合要求，当年是按重量付款的，价格约为5元/千克。

: 看了楼主的帖子，下午把哑铃也称了一下，结果如下（标称/实际 单位 ：千克）：

: 哑铃片：0.75 / 0.49 1.50 / 0.976 2.0 / 1.495。

: 附件重量（手柄及两个固定螺母）：1.329千克。

盎司？也不对。

以前见过向龙的壶铃只有数字，没有单位，也好奇过是磅还是公斤。后来用称重确认了，所以还是用秤吧，别猜了。

3. 称重

最简单的称重方法是，4种、每种4个，共16个哑铃片，每个称重一下，贴个不干胶贴标上数值。但是我的工具不行。

我手头现有两个秤。一个是厨房用秤，如上两图所示。量程/最大1kg，精度0.1g。另一个是体重秤（此刻才想到体重秤有两个，但是不影响接下来的方法和结论）。最大重量不清楚，能称大活人，精度也不精楚。最大重量远超过我要称重的哑铃片、杆、螺丝的总和，但是量程不仅是最大重量，还包括最小重量，与精度又有不同。说起细节来挺麻烦，简而言之，从现象上看，哑铃片放在体重秤上“打不起砣”，显示为0。

解决方案是这样的。

(1) 人先站在体重秤上，作为空白。体重秤没有“去皮”功能，所以记录下这个重量，称为H。接着，人拿着哑铃片D，称得新的重量N。计算，哑铃片的重量D=N-H。

(2) 小的哑铃片按上述方法称重得到0，因为体重秤的精度不够。所以用厨房秤称。

(3) 大的和小的之间的重量，比如空杆，人和体重秤联合测量，得到结果0，又超出厨房秤的范围。在厨房秤旁边搭个差不多等高的小台子，把重物同时放在小台子和厨房秤上，得到一侧的读数L。把重物旋转180度，测另一侧的读数R。L+R得到空杆的重量1kg多一点。

以上方案中包括以下假设和需要讨论的地方。

(1) 根据现象，可以推得体重秤的误差分布是不均匀的。因为，在0附近，测得存在哑铃片和不存在哑铃片间的差额为0；在人体重附近，这个差额不是0。既然误差分布不均匀，那么在哪个范围内误差是可忽略的。

(2) 记录数据时假设了体重秤和厨房秤的误差相同。更有甚者，假设了如果二者量程无限，那么同一重物在这两个秤上的结果相同，不然无法比较或求和。有同学可能提到，都是法定用于计量的秤，应该不会有问题吧。如果以此为依据，那么哑铃上还标着数字呢，也作不得准。

(3) 印象里方案(3)中的称量方法对重物放得有多平是有要求的，但是细节不记得了，人懒没有查。所以，假设两次称量之和就是准确的重量。

称了几个组合，得到一些数字。笔记粗糙而乱，除了记录还有猜测和推算（以及暴露口算和笔算能力有多么弱）。下面有表格，此处仅展示，可跳过，不影响阅读。

4. 拟合

实验得到以下几组数据。之所以有斤，还有kg，是因为体重称有时候单位是公斤(kg)，有时候是斤。这样记录保留了原始数据，虽然没有表明哪个才是原始的。

在测量过程中，我就开始猜测，感觉像是 哑铃片实际重量为标称的3/4。所以在笔记的左侧用测得的其他数据验证了一下，感觉差不多。这可以作为一个结论，即3/4不知道从哪里来的，经验公式。

不过经验公式不够“科学”，说服力还可以更强一些。我把这些数据用XY散点图绘图，如下图所示。再拟合一下，Excel中称为 趋势线。

拟合的结果是公式的参数。用于拟合的数据有了，先验公式/曲线的函数是什么呢？我们可以通过观察发现，差不多是线性的。也可以猜测一下缺斤少两的做法，在什么情况下不易被用户发现。缺斤少两的直接收益是厂商可以用更少的铁，毕竟哑铃价格中的重要因素是铁的价格。如果每个哑铃减去相同的重量，对较高重量的哑铃获益不多，在较低重量的哑铃上更容易暴露出来。那么按标称乘以一个因数，即线性的缺斤少两，是更佳方案。线性的结果拟合的就挺好，更复杂的，就略过不讨论了。

从图示和R²上都可以看出，线性拟合对于所有数据的误差都不大。

所以，得出结论 标称重量*3/4 或者 标称重量*0.75，即哑铃片的真实重量。缺1/4。以前的哑铃片组合表格，修订如下。我以为去杆8kg的，加杆和螺丝以后，刚好8kg多一点。

5. 讨论

为什么追究这个问题呢，一个因素当然是考虑在工具有限的情况下如何得到有说服力并且易用的结果，是件好玩的事。

也有更实际点的用途。网上有报道，有人在家里用哑铃或杠铃锻炼，以为自己厉害到这个数值了，结果在健身房举了真实重量的哑铃，导致受伤了。

邢ZP老师提到，有百米跑道只有九十米，比实际短十米。受测小朋友误以为自己是天赋异秉不可多得的短跑人才，长期为没能在奥运会上为国争光而遗憾。直到后来这位同学家乡的新闻爆出体育设施建设中的贪污才让他终于把心放下。

我们讨论到，哑铃不是计量器具，不能当作法码用，所以缺斤少量不受计量法管束吧。邢ZP老师还提到，计量器具里，健身房的体重秤的数值说不定也有偏。不过，体重秤并不用于称肉卖，所以并没有顾客多花钱少得肉，没有这方面的损失，还得到了情绪价值。这个，又怎么看呢？

https://younggift.net/

https://www.zhihu.com/people/yang-gui-fu-52

微信公众号 杨贵福

繁体中文的字幕读起来不那么顺畅，转成简体中文就容易多了。对于电视剧有很多字幕文件的情况，需要批量转换。这个实验过程可以帮助理解简繁对应关系、编码，实践命令行工具使用和批处理编写，可以涉及环境变量、搜索路径、cmd和shell知识，以及word、记录本、Total Commander使用。

1. 解决方案

本文把字幕批量从繁体转换为简体，涉及到的命令行工具为 OpenCC 和 iconv。工具的下载路径、简要的原理、其他替代工具将在后文给出。使用如下所示的bat代码。

for %%i in (*.ass) do (

 iconv -f UTF-16le -t utf-8 "%%i" > "%%i.utf8"

 opencc -i "%%i.utf8" -o "%%i" -c c:\tools\opencc\share\opencc\t2s.json

 del "%%i.utf8"

)

2. 繁体转简体，其他工具 及 原理

电影的单个字幕文件转换，可以用word完成。常用的字幕格式 srt, ass 都是纯文本文件，可以用word打开。使用word的"繁转简"功能即可达到目的。

简体 繁體

在原理上，如下图所示，两个“体”字，在同一个文件中可以同时出现。这两个“体”字的的不同并非由于 编码、国别、本地化locale、字体 的差异，而是不同的字符。在编码上互不相关，二者的对应关系完全由于自然语言汉语决定——在技术上，任意两个字符（严格地说，还有多对一、一对多等情况，在此略过）都可以对应——人为规定“体”与“體”之间为简-繁对应。

电视剧的字幕每集一个文件，逐个用word打开操作，有点麻烦。这种任务，一般适合使用命令行操作。

有个 OpenCC 项目，支持命令行下的繁简转换。

https://github.com/BYVoid/OpenCC

我运行时报错，但是没有找到详细手册。猜测 OpenCC 只能读入 UTF-8编码。

3. 编码，其他工具 及 原理

（1）判定当前编码

我当前要处理的字幕文件是不是utf-8，查看文件编码可以用 Linux 下的 file 命令。或者用记事本 | 另存为，或者用 Total Commander | F3 查看 等诸多方式。这几种方式间可以相互补充印证。

（2）转换编码

在原理上，编码的不同是更一般性的问题，在各种语言中普遍存在，而不仅在中文中存在。通过 记事本 | 另存为，保存为 UTF-8，可以完成编码的转换，从而符合 OpenCC 的输入条件。也可以使用 SubtitleEdit 另存时转换编码。

批量处理的话，可以使用 iconv。

Iconv 在 https://gnuwin32.sourceforge.net/packages/libiconv.htm。下载 Binaries 和 : Dependencies，解压到同一目录中。

4. 批处理

了解以上原理、试用命令行工具对单个文件转换成功后，选用 iconv 和 opencc 写 bat代码 完成批量转换。

（1）遍历目录

遍历当前目录，并以扩展名 ass 作为筛选文件的条件，形成下面的循环。

for %%i in (*.ass) do (

rem 对每个文件执行的操作

)

（2）对每个文件执行编码转换，然后由繁体转换为简体

在循环体中对遍历的每个文件执行类似操作。

第一步，用iconv转换编码，由utf-16 小端 unicode 到 utf-8。

第二步，用opencc执行由繁体到简体的转换。

第三步，删除临时文件。

for %%i in (*.ass) do (

iconv -f UTF-16le -t utf-8 "%%i" > "%%i.utf8"

opencc -i "%%i.utf8" -o "%%i" -c c:\tools\opencc\share\opencc\t2s.json

del "%%i.utf8"

)

其中 %%i 是对应当前遍历的文件名的变量；

c:\tools\opencc\share\opencc\t2s.json 是繁体到简体的配置文件及其所在路径；

%%i.utf8 是临时文件。

Iconv 和 opencc 需要放在搜索路径%path%下，或者像下面这样使用如下绝对路径。

先备份，然后把所有字幕文件放在当前目录下，执行上述批处理（名字就叫“字幕文件 unicode2utf8 繁2简 - go.bat”）。一瞬间以后，所以字幕文件完成了编码和繁简转换。在此案例中，只有一个文件 a.ass。

使用 Total Commander | F3 功能或者上述提到的其他方法，可以验证编码转换完成。

打开文件查看内容，可以检验，已由繁体转换为简体。

在Windows10中，误触 win+; 或 win+. （左windows键和分号 或 左windows键和点）组合键，会弹出如下窗口，挡在你正看着的地方。

如果正在写东西，无论是写代码还是写文字，这时的体验都相当不好，想骂人。功能并非越多越好，不管三七二十一全都展示出来就更加糟糕。

这个窗口叫作表情输入面板，在网上找到两种禁用方法。第一种是改注册表。我尝试过至少两个流派，都无效。并且，改注册表这么高权限的操作，应该慎用，尽可能不用。能完成任务的话，取得的权限越少越好。第二种是按特别操作步骤，能够得到特定的窗口/界面，再操作就能禁用。我尝试过至少两个流派，在我的机器都找不到期待的界面。这种Windows GUI风格修改配置与Unix/Linux或Windows ini相比，虽然对初学者友好，但是对稍微复杂一点的修改相当不适用。版本小修改、位置或文字变动，都可能使以前的操作方法失败。

写了一小段AHK脚本，代码如下。

<#;:: ; 禁用 表情输入面板

return

<#.:: ; 禁用 表情输入面板

Return

已经安装了AHK，我把下述代码保存为 ahk扩展名，放在启动执行中。问题解决，世界终于清净了。

代码的含义如下。

拦截了 左win+. 和 左win+分号。这两种组合键是我经常会按到的，在本想按 win+L 或 ctrl+L 的时候。右win+. 和 右win+; 没有拦截，仍然可以使用。不常用的功能，入口应该避免误触。要隐蔽，因为不常用，隐蔽不会妨碍工作效率。

此外，我的键盘有个小缺欠。这款键盘没有上下文菜单，或称鼠标右键菜单，或称快捷菜单。它们略有区别，在此略过。总之，就是按下以后，弹出下图中菜单的那个键。

也写了一段AHK脚本，如下。

^F1:: ;上下文菜单

; msgbox ,,, here

Send, {AppsKey}

; MouseClick , right

这样，我按 ctrl-f1时，会弹出上下文菜单。最后一行的注释，对应的是在鼠标当前位置按下鼠标右键，这个功能我不常用，并且用 keynavish 完成，所以在此注释，只留作备忘。

https://younggift.net/

https://www.zhihu.com/people/yang-gui-fu-52

微信公众号 杨贵福