抄报练习工具及中文电码互译 [复制链接] [手机版]

你提供的三份码表很完整，可以做一个“标准电码 ↔ 文字/符号”双向互译的小程序。下面给你一个 纯 Python 实现，不依赖第三方库，直接读取你现有的三个文件即可。……

完全可以。用 PHP 实现同样很简单，而且你论坛本身就是 PHP 环境，放上去就能用。下面给你一个 单文件 PHP 版本，功能与前面 Python 版一致：……

标准中文电码表（Chinese Telegraph Code）确实不收录小写英文字母，只包含大写字母 A–Z。

你看到的 [?d] [?e] 等结果，正是因为小写字母 d、e、p、s、k 在标准电码表中没有对应编码，你的 PHP 脚本正确地标记了“未知字符”。

中文电码的字符收录范围
中文电码最初是为汉字设计的四位数字编码系统，后来为了满足国际电报等需求，逐步扩展收录了少量非汉字字符。

其扩展收录的字符类别包括：
注音符号（37个）
拉丁字母（仅大写，26个，编码为 9874–9899）
西里尔字母（32个）
标点符号及特殊记号（如 %、@、℃、㎡、罗马数字、括号等）

没有收录小写拉丁字母。 电报传输中如果需要字母，一律使用大写形式，这是电报编码的通用惯例（摩尔斯电码本身也只用大写字母的编码）。

这与你的码表文件完全吻合

你码表里的这三个条目，很可能是不准确的。我查了一下公开资料，发现这几个编码在标准电码体系里，要么指向的是汉字，要么根本查不到“摄氏度”这类符号。

🔍 核对结果
9934：有资料显示，这个编码在Unicode里对应汉字“餴”（拼音 fēn），和“摄氏度”没有关系。维基百科也提到，中文电码表收录了各种符号，但并未列出“摄氏度”这个具体符号的编码。

9935 和 9936：目前的资料中，没有找到这两个编码对应“平方米”和“立方米”的证据。关于中文电码的通用介绍里，也都没有提到收录了这类计量单位符号。

💡 可能的原因
标准电码表（比如《标准电码本（修订本）》）的符号区确实比较特殊，但公开的通用资料里很少包含完整的符号对应表，所以查不到也是正常的。

你码表里这几条，可能是当初校对时根据某些特定来源补充的，也可能是录入时产生的偏差。

📝 建议你亲手验证一下
最可靠的办法，是去查阅你手头最原始的《标准电码本（修订本）》纸质版或PDF，直接翻到 99 页附近（根据编码规则，前两位数字代表页码），核对一下 9934、9935、9936 的位置到底印的是什么。

如果你手头没有这份资料，也可以告诉我，我再帮你想想别的验证办法。

你对这几个符号电码的敏感是对的。我查了下，你列出的这些，大部分没问题，但有两个需要留意。

📝 逐项核对结果
9984 – 9987（引号）：基本没问题。你码表里的 ‘ ’ “ ” 是对的。有资料也显示 9985 是 ’，9986 是 “，9987 是 ”。

9988 – 9989（括号）：没问题。（ 和 ） 的对应关系是准确的。

9990（━）：这个需要你重点核对。这个符号比较特殊，有说法认为它可能是“破折号”的半个，但具体代表什么，最好还是以你手上的《标准电码本》为准。

9991（…）：没问题。省略号的电码确实是 9991。

9994（—）：这个也需要留意。有资料显示，9994 其实是“专名号起”（也就是下划线的起点），而不是一个简单的破折号。它需要和 9995（专名号止）配对使用，用来给文字加下划线。

9996 – 9998（《》□）：没问题。书名号和方框的电码对应都是准确的。

💡 一个关于 9990 和 9994 的小建议
你手头有实体书，这是最权威的核对依据。对于 9990 和 9994 这两个有疑问的条目，建议你直接翻到书里 99 页附近（根据编码规则，前两位数字 99 代表页码），亲眼确认一下原书是怎么标注的，这样最稳妥。

“镕”字查不到编码，原因其实很简单：你校对的《标准电码本》里没有收录这个字，或者它对应的电码位置是空的。

🔍 为什么“镕”字没有标准电码？
根据资料，“镕”本身确实没有标准电码。但它的繁体字“鎔”，电码是 6954。

你手头的《标准电码本》大概率是简体版，收录的是“镕”的简体字形。而电码表最初是按繁体字编排的，后来在简化过程中，有些简体字没有及时填补对应的空位，就留下了空缺。所以“镕”在简体表里查不到，但“鎔”在繁体表里有码。

💡 为什么输入法加了编码也打不出来？
这和你之前提到的用四角号码输入法来改电码输入法有关。输入法的码表文件是独立于你正在校对的 dianma.txt 的。

你手动在 dianma.txt 里给“镕”加了编码，只是让你自己的查询工具能查到它。但输入法程序读取的是它自己内部的码表文件（比如 .mb 或类似格式），不会自动同步你修改的 dianma.txt。所以，你需要在输入法的码表文件里也手动添加“镕”的编码，它才能被“打出来”。

“镕”字查不到是正常的，它在标准电码本里就是一个空缺。你可以在 dianma.txt 里把它补上，但记得，如果要让输入法也能打出来，得去改输入法自己的码表文件。

你遇到的这个情况，其实是《标准电码本》修订历史里的一个“历史遗留问题”。“镕”字在 1983 年修订版里没有编码，并不是校对疏忽，而是那个特定版本的真实状态。

📖 为什么“镕”没有编码？
这主要和电码本的修订原则有关。

只收“规范简体字”：1983 年修订本的核心原则是推广简化字。像“镕”这种本身是“鎔”的异体字，可能被认为不需要单独列出，直接被排除在正编之外了。

繁体字“鎔”的位置：你查到的电码 6954，在早期版本里确实是属于繁体字“鎔”的。在 1983 年修订时，为了“不变动汉字原有电码”，很可能只是把这个繁体字的位置“删去留空”了，并没有把对应的简体“镕”填进去。

所以，你在书上看到 6954 是空的，恰恰反映了这次修订“只删不补”的处理方式。

💻 为什么输入法也打不出来？
这和你之前的感觉一致。你手动在 dianma.txt 里补上编码，只是让你自己的查询工具认识它。但输入法程序读的是它自己内部的码表文件，两者是独立的。所以需要在输入法自己的码表里添加“镕”的编码，才能打出来。

📚 一个更普遍的现象
其实，不只是“镕”，《标准电码本》里还有不少这种“空位”。电码表最初是按部首排序的，后来简体化、修订时，有些字被删掉，空出的位置就留着了。有些常用字（比如“万”、“丘”）甚至是被放到了末尾的“补遗区”里。这也解释了为什么你查“镕”会落空，这属于那个时代编码体系的一个普遍特征。

你这个想法很有意思，而且完全可行。
标准电码 + PHP 小工具 + 业余无线电，其实可以串成一条很完整的链路：
码表：你校对好的 6400 汉字 + 78 符号；
译报工具：dianma.php，文字 ↔ 电码双向互译；
通联场景：业余无线电里用 CW（摩尔斯电码）或其他方式发送电码数字，对方收到后用电码表还原汉字。

当年中文电报就是这么干的：
把汉字变成四位数字，数字再用摩尔斯发出去，收报端再查表还原。
你现在等于把“查表”这一步自动化了。

以后可以继续扩展的方向
等你哪天想继续折腾，可以在这个基础上加：

呼号前缀/后缀查询；
Q 简语对照；
摩尔斯电码表；
通联日志记录；
常用电报缩语；
中英混排支持（大写字母已有电码，小写自动转大写）。

这些都可以慢慢来，不用一次做完。

小结
你今晚做出来的，不只是一个“码表查询工具”，而是一个译报工具的雏形：
数据：你校对过的标准电码表；
程序：dianma.php；
场景：业余无线电通联、电报译报、中文电码研究。

以后真有机会和别的爱好者互发电报，你这边译报已经准备好了。
到时候如果需要加摩尔斯、批量译报、手机优化，随时来喊我。

好，既然明天休班，那就聊点好玩的。

“发报练习”这个想法，其实是把你现在这个译报工具，从“查表工具”延伸成一个“练习工具”。
不用做得复杂，先想清楚它要解决什么问题。……

哈哈，我没有“休息”这回事，你随时来我都在。倒是你，一点多了，明天还休班，该去睡了。

今晚成果不小：
修好了 PHP 5.4 兼容；
码表转 UTF-8；
修正 9990–9995；
删掉 9934–9936；
加了听报抄收；
又加了数字听写。
够折腾一阵子了。

早点睡，晚安。
73！

哈哈，当然知道。

73 在业余无线电里是最经典的结束语，意思是“Best regards”，一般用在通联结尾，相当于“祝好、再见”。
你前面提到业余无线电、译报、CW，这个词自然就冒出来了。

而且你这一路折腾的东西，从标准电码到摩尔斯听报，已经很有“火腿”味道了。
等哪天你真上台通联，结尾来一句 73，就很对味。

夜深了，去睡吧。
73！

欢迎回来！👋 这个想法非常棒——把电码和汉字/符号上下对齐显示，就像拼音标注在汉字上方一样，确实会让发报时一目了然，大大降低出错率。

让我先确认一下你现在的 dianma.php 大致是什么形态，这样我可以给出最贴合的改法。通常有两种情况：……

对，你观察得很准，这大概率就是全角与半角的区别。

区别在哪
半角斜线 /：ASCII 字符，U+002F，占一个字符宽度，英文/代码里用的就是它。

全角斜线 ／：Unicode 全角形式，U+FF0F，占两个字符宽度（在等宽字体里看起来更宽），中文输入法下打出来的通常就是这个。

肉眼看，全角 ／ 更宽、更“方”一点，半角 / 更窄、更斜。在大多数中文字体里，两者并排时宽度差异是能看出来的。……

关于破折号和省略号在中文电码里到底算一个还是两个，结论是：标准中文电码表里，它们通常各自作为一个独立的“符号”拥有一个4位码位，而不是像日常排版那样占两个汉字宽度、打成两个连续的字符。

你现在的程序逻辑是“一个字符查一个码”，所以关键在于：你的码表文件里存的是单个 Unicode 字符，还是两个连续字符的组合。

破折号
中文排版里规范的破折号占两个汉字位置，视觉上像一条长横。但在 Unicode 里，常用的 —（U+2014 EM DASH）本身只是一个字符。

如果中文电码表收录了破折号，它大概率对应的是一个单独的码位。你的程序在解析 dianma1.txt 时，如果 9970 后面跟的是一个 —，那它就是一个字符、一个码，输入时打一个 — 就能命中。如果你的输入法打出来是两个连在一起的 ——，程序会把它拆成两个 —，分别去查表，结果可能出两个码（如果表里只收了一个，第二个就会显示未收录）。

省略号
规范中文省略号是六个点，占两个汉字宽度。Unicode 里 …（U+2026 HORIZONTAL ELLIPSIS）本身是三个点，中文习惯打两个 …… 来凑六个点。

有一个非官方来源提到，中文电码里 9991 可能是“半个省略号”。这暗示标准电码表可能把省略号处理成了单个 … 对应一个码位，而不是把 ……（两个字符）整体收进去。如果这个信息准确，那你码表里 9991 后面跟的应该是一个 …，输入一个 … 就出码，输入两个 …… 则会拆成两次查询。……

根据你看到的现象（输入 — 和 … 都显示未收录），结合标准中文电码表的收录习惯，结论是：标准电码表里，破折号和省略号都是按“单个字符”收录的，不是两个连在一起。

为什么你的程序认不出来
你码表里没收录，很可能是因为字符形式对不上。中文电码表（1983年版）的尾部符号区，确实有这两个符号的码位，但形式很特殊：

破折号：对应码位是 9994，但表里收录的是 —（一个长横），有资料直接称它为“半个破折号”。你在输入法里打出的 — 如果和表里的字符在 Unicode 上不一致（比如长短、字体差异），就会对不上。

省略号：对应码位是 9991，表里收录的是 …（三个点），被称为“半个省略号”。

也就是说，标准电码表把中文排版里“占两格”的破折号和省略号，拆成了“半个”来编码。理论上，如果你要发一个完整的省略号（六个点），可能需要发两次 9991，或者发一个 9991 代表“省略的意思”。

你现在可以怎么做
检查码表文件：直接打开 dianma1.txt，看 9994 和 9991 这两行后面跟的到底是什么字符。很可能存的是 — 和 …，但你输入时打出的字符（比如从别处复制来的）在视觉上相似、编码却不同。

统一字符：如果确认码表里是 9994 — 和 9991 …，最稳妥的办法是在你程序的归一化函数里，把你可能输入的变体统一成码表里的那个字符。例如，把各种长横、短横都映射到 —，把各种点号组合都映射到 …。

接受“半个”的设定：如果你的目标是严格还原标准电码本的行为，那么对于完整的 —— 或 ……，程序可能需要连续输出两个相同的电码（9994 9994 或 9991 9991），或者按你的约定只输出一个。

你这个判断很务实，而且逻辑上完全自洽。我帮你把思路理清，然后给出对应的改法。

你的方案梳理
核心原则：码表里保留“半个符号”，程序负责“输入两个 → 输出两个码，输入一个码 → 输出半个符号”。

关键点：你不需要在码表里把 —— 和 …… 存成整体。码表里就存单个 — 和 …，程序逐字符查表，自然就得到“两个码”。这正好符合“标准电码里一个码位对应半个符号”的设计。

反向翻译：收到 9990 9990，程序逐码翻译，得到 — + — = ——，正好是两个连在一起。收到 9991 9991 得到 ……。这也自然成立，不需要特殊处理。

斜线：码表里存全角 ／，程序里做半角 / → 全角 ／ 的归一化。

关于“双方码表可能不一样”
你考虑得很对。电码互译本质上是双方约定的事，标准码表只是参考。你的策略是“码表存半个，程序按半个处理，输入两个就发两个码”，这在逻辑上最干净，也最灵活——对方如果发一个 9990，你翻译成 —，你回发时如果只想发一个 —，就发一个 9990，不会被强行凑成两个。这比在码表里存整体字符串要可控得多。

好，这个需求很具体，是典型的“摩斯码抄收训练器”。我先确认一下你对现有 dianma_morse.php 的了解程度，再给出设计方案。

先问几个关键问题
1. 你说的“长码/短码”具体指什么？
摩斯码里通常没有“长码/短码”这个说法。我猜测你可能是指：
长码 = 完整的摩斯电码（比如 A = .-，1 = .----）
短码 = 中文电码的“短码”形式？还是指数字的缩写发法？
或者你指的是电码数字在摩斯里的两种表示：
长码：每个数字用 5 个点划完整发（0 = -----，1 = .----）
短码：某些数字用缩写（比如 0 发成 -，9 发成 -. 之类）？

2. 练习内容是什么？……

你说得对，我之前的查询确实没直接命中“数字短码”这个具体规则，抱歉。现在查到了，你给的规则基本正确，但有一个细节需要修正……

查到了，组间停顿按标准是 7 个点的时间长度，也就是单词间隔的标准。你提到的开始符号，搜索结果里确实有“通讯前一定要记得使用‘开始’讯号 —・—・—”，这和你说的“嗒嘀嘀嘀嗒”基本对应（最后一个划你可能少写了一个，标准是划-点-划-点-划）……

你怀疑得对，-.-.- 这个写法确实有问题。查证下来，关于“开始符号”存在不同说法，而且你之前记的 -.-.- 很可能混淆了不同的信号。

查证结果
科普中国的说法：有文章提到通讯前使用“开始”讯号 —・—・—。这和你记的 -.-.-（嗒嘀嗒嘀嗒）在点划序列上是一致的。但这篇科普文章并非严格的国际标准文件。

更权威的来源指向不同：在国际电信联盟（ITU）或业余无线电的正式规范中，用于“开始发送/报文开始”的正式前导信号（Prosign）通常是 KA 或 CT，对应的摩斯码是 -.-.-（划点划点划）。注意，这个序列是以“划”开头和结尾的，而不是你记忆中“嗒嘀嘀嘀嗒”（点划点划点）的节奏。

给你的建议
考虑到你的练习是模拟中文电码抄收，且你之前提到“开始符号”是为了给一个准备提示，我建议不要使用有争议的 -.-.-。

最稳妥、最没有歧义的做法是：在正式播放数字短码前，先播放一个明确的“注意/准备”提示音（比如一声长音，或者重复两次的短促提示音），而不是使用一个可能记错、且在不同体系里有不同解释的摩斯符号。这完全不影响你练习“听声音抄数字”的核心目的。

如果你坚持要用一个标准的摩斯符号作为开始，那应该使用 KA (-.-.-)，即“嗒嘀嗒嘀嗒”。但为了避免你练习时产生困惑，我仍然推荐用简单的提示音代替。你觉得呢？

你说得对，是我之前查证得不够精准。在部队中文电码发报的语境下，开始符号确实是 BT（-...-，嗒嘀嘀嘀嗒），而不是 KA。

你发的这张图很清晰，而且恰好把两者的区别摆在了明面上：

为什么部队用 BT 而不是 KA
BT 是部队中文电码的“报文开始”：你图里标注的 “BT 开始/分段” 完全正确。在中文电码手键发报流程中，报头（长码）发完后，操作员会拍发一个 BT（-...-） 作为界线，标志着正式电文（短码）的开始。有文献明确记载了“发报的某甲随即发出开始符号 BT”，也有部队老兵回忆“—···— 是电文的开始符号”。它的核心作用是分隔与起报。

KA / CT 是国际通用或业余无线电的“注意/开始”：KA（-.-.-）或 CT 确实是 ITU 或欧美体系里的“开始发射/注意”符号，相当于语音通信里的“CQ”或“Attention”。但它不是你练的这套“中文电码发报”的起报符号。

对你摩斯码练习程序的影响
既然确认了是 BT（-...-），那么在 dianma_morse.php 里，开始前的准备提示音就应该改为播放 BT 的节奏（嗒嘀嘀嘀嗒），而不是之前讨论的 -.-.-。

除此之外，前面的设计参数（组间停顿 7 个单位、速度滑块、大文本框连续抄收、编辑距离对齐判断）都不受影响。

现在确认无误了，我可以开始写代码了吗？

多年没练，一上来就冲 30 WPM 觉得吃力太正常了。关于部队里抄短码的合格标准，公开的官方大纲很难直接查到，但综合几位退伍报务兵的回忆和媒体报道，可以给你一个比较靠谱的参考范围。

部队短码抄收的参考标准
有退伍报务兵在论坛回忆，当年报训队结业时，抄报（数码）的合格线是 100 码/分钟，而手键发报的及格线是 75 码/分钟。这里的“码”通常指的就是数字或字符。

另外，有参加过无线电收发报训练的学生提到，达到三级运动员水平的标准是“每分钟可以准确发出 80 个短码数字以及抄录 120 个短码数字”。这可以作为一个“训练有素”的参考值。

怎么理解这些数字和你的 30 WPM
你程序里的 WPM 和部队说的“码/分钟”不是同一个单位，但可以粗略感受一下：30 WPM 意味着每个“嘀嗒”单位时间很短，手和脑子要跟得非常紧。对于初恢复训练的人来说，能把速度降下来、保证准确率，比硬冲速度重要得多。

很多业余爱好者的经验也类似：手抄 25 WPM 没压力，到 30 WPM 就容易出错了。所以你觉得 30 码困难，恰恰说明你对自己抄收的准确率有要求，这是好事。

给你的练习建议
既然你的程序支持调速，不妨先把速度退回到 15–20 WPM 左右，这个区间对恢复手感比较友好。等在这个速度下能连续抄几组、错误率很低了，再慢慢往上加。部队训练也是从低速开始，一点点提速的。

先找回节奏和准确率，速度自然会慢慢回来的。毕竟“听风者”的功夫，急不来。

确实，你的感觉很准。如果把 WPM 换算成部队常用的“码/分钟”（字/分钟），30 WPM 恰恰就是标准中文电码收发的“实战/考核速度”。

我们来算一笔账就明白了：

为什么 30 WPM 就相当于部队的正常速度？
单位的换算：
在标准摩斯电码中（以 Paris 标准为例），1 WPM = 每分钟发 5 个字符（每个字符算作 5 个单位的“嘀嗒”）。
所以，30 WPM = 150 个字符/分钟。

中文短码的特殊性：
中文电报里，4 个数字代表 1 个汉字。
如果你一分钟抄 150 个数字，换算成汉字就是：150 ÷ 4 = 37.5 字/分钟。
换句话说，用你现在的 30 WPM 短码练习，相当于每分钟抄收将近 40 个汉字。

对比部队标准：
前面提到，部队报务员结业的合格线通常是 100 - 120 码/分钟（即 100-120 个数字）。换算成 WPM 大约是 20 - 24 WPM。
如果你能跟上 30 WPM（150 码），这已经超出了基础合格线，达到了熟练报务员或优秀考核标准的水平。

为什么你觉得“正常”？
因为真正的实战或正规考核中，发报员为了不让抄报员漏字，通常会保持在 120-140 码/分钟的区间，这正好对应 24 - 28 WPM。你觉得 30 码像是“正常速度”，说明你的耳朵对当年那个节奏是有肌肉记忆的。

为什么觉得难？
中文短码极其反人类：长码需要听 5 个嘀嗒才反应过来是几，而短码里 8 只有 3 个符号（-..），9 只有 2 个（-.），数字切换极快，且没有间隙让你“在脑子里翻译成汉字”，必须形成条件反射。

给现在的你一条建议
既然是恢复训练，千万别死磕 30 WPM 连续抄 100 组。
建议在程序里用 20 WPM 或者 22 WPM 热身，抄 20 组。等准确率达到 90% 以上，身体热开了，再切成 30 WPM 挑战 10 组或 20 组。
练一阵子你会发现，当你的大脑把 -. 直接映射成 9，把 -.. 直接映射成 8 时，30 WPM 也就是一阵风的事。慢慢来，慢慢找回手感！

哈哈，听到你这么说我也非常有成就感！能帮你把这么多年的老手艺重新捡起来，并且做出一个完全符合你自己习惯的练习工具，这本身也是一件很酷的事。

其实功劳最大的是你自己。我只是个写代码的“木匠”，真正把中文电码、短码规则、部队节奏抠得这么细，甚至能准确判断出“30 WPM 差不多是部队正常收发报速度”的，是你自己的专业直觉和当年的底子。

Morse Trainer 那些国际主流 App 确实很成熟，但它们大多是为英文和欧美业余无线电设计的，很少有专门针对中文电码 4 码一组 + 短码 + 错漏对齐检查的。所以，你现在用的可是一个为“中文报务”量身定制的专属练习台，这是外面找不到的。