比如回复别人CQ的时候： YU1EA BI1RLR -18 已经16个字符了，能正常发出去，对方也能正常解码

这里放不了ft8cn作者YOZ老师的微信聊天记录……截了几张图大伙勉强看一下吧[upl-image-preview uuid=550bc2b8-a5ec-4366-bd68-fae557049416 url=https://storage.hamcq.cn/2025-06-16/1750080763-221544-screenshot-2025-06-16-21-30-53-51-e39d2c7de19156b0683cd93e8735f348.jpg alt={TEXT?}] [upl-image-preview uuid=67351151-cb63-4049-8a8b-f2792e6186bb url=https://storage.hamcq.cn/2025-06-16/1750080784-914371-screenshot-2025-06-16-21-30-58-52-e39d2c7de19156b0683cd93e8735f348.jpg alt={TEXT?}] [upl-image-preview uuid=100ee988-8fb2-4525-8381-0ca69c275068 url=https://storage.hamcq.cn/2025-06-16/1750080956-79478-screenshot-2025-06-16-21-31-02-46-e39d2c7de19156b0683cd93e8735f348.jpg alt={TEXT?}] [upl-image-preview uuid=6a193dd2-d504-4f25-bb5f-ed72c2b7dc8f url=https://storage.hamcq.cn/2025-06-16/1750081009-758764-screenshot-2025-06-16-21-31-05-93-e39d2c7de19156b0683cd93e8735f348.jpg alt={TEXT?}] [upl-image-preview uuid=c0027d06-bdce-4c9d-833d-a43324a490ee url=https://storage.hamcq.cn/2025-06-16/1750081020-438575-screenshot-2025-06-16-21-31-09-30-e39d2c7de19156b0683cd93e8735f348.jpg alt={TEXT?}] [upl-image-preview uuid=13f61722-8c8a-478a-a51b-6b7ab9908e7f url=https://storage.hamcq.cn/2025-06-16/1750081026-935166-screenshot-2025-06-16-21-31-13-79-e39d2c7de19156b0683cd93e8735f348.jpg alt={TEXT?}] [upl-image-preview uuid=b925ba52-2c00-4b30-87e9-fb0363f7506d url=https://storage.hamcq.cn/2025-06-16/1750081034-578432-screenshot-2025-06-16-21-31-17-38-e39d2c7de19156b0683cd93e8735f348.jpg alt={TEXT?}] [upl-image-preview uuid=96e99395-d2ef-4901-a397-1d16e63b2132 url=https://storage.hamcq.cn/2025-06-16/1750081040-384943-screenshot-2025-06-16-21-31-21-26-e39d2c7de19156b0683cd93e8735f348.jpg alt={TEXT?}] [upl-image-preview uuid=2cfeed22-848a-4a38-93b3-d85f550d0969 url=https://storage.hamcq.cn/2025-06-16/1750081045-276576-screenshot-2025-06-16-21-31-24-74-e39d2c7de19156b0683cd93e8735f348.jpg alt={TEXT?}]

使用了某种数据压缩协议以减少呼号及网格所占用的数据位数，比如使用快速哈希算法将呼号映射为固定长度的哈希值，传输时仅需发送该哈希值。https://do1alx.de/2021/the-pitfalls-of-ft8-grid-locators-and-special-calls/ [upl-image-preview uuid=a8d66d21-2b9e-48d8-9664-5f1921662b29 url=https://storage.hamcq.cn/2025-06-15/1749946946-809955-ft8-encoding.png alt={TEXT?}]

哈希不是单向的算法吗？

@"BG5LU"#p70016 所以你时不时能看到无法解码的呼号

@"BG5LU"#p70016 呼号超限后会把呼号转换为哈希值计算哈希值不可逆也就是说别人必须先前接收到你的CQ信息后对照哈希值才能知道你是谁你的CQ对方没收到的情况下 tx2 tx3对面解不出来，tx1 tx4 tx5 tx6可以打个通俗易懂的比方:转换哈希值就像是5 * 6=30这个式子你只发tx2 tx3时就像你只告诉你的结果等于30 别人不知道具体是几乘几当你发过tx1 tx4 tx5 tx6时表明了你是5 * 6=30 以后别人一看你等于30就知道你是5 * 6，大体意思就是这样的

哈希值不可逆，需要接收方缓存呼号的哈希字典表

以前也有同样的疑问，知识+1

那为什么我的wsjt能正常输入超长文字（16个字符），但发送时却看到后面几位被截断了？

把WSJT-X相关的文献看一下就都知道了...... https://wsjt.sourceforge.io/refs.html [upl-image-preview uuid=07f108d7-7c80-4a5e-a60f-ed00474985e4 url=https://storage.hamcq.cn/2025-06-16/1750051311-584073-image.png alt={TEXT?}]

这个视频有点长，但是讲的很清楚： https://www.bilibili.com/video/BV1wm421G7py 每次看都有新收获（甚至连偶尔在频谱上看到信号开头和结尾出现的展宽是怎么回事都讲到了）

FT8最多只能傳輸13個字，為什麼常常在WSJTX上看到超長的訊息？

swimmingcat

例如，回覆對方使用 CQ 的情況：
YU1EA BI1RLR -18
已經有 16 個字，可以正常發送出去，對方也可以正常解碼。

BG6QED

為了減少呼號和網格所佔用數據位數，使用了某種數據壓縮協定，例如使用快速哈希演算法將呼號映射為固定長度的哈希值，在傳輸時僅需傳送該哈希值。https://do1alx.de/2021/the-pitfalls-of-ft8-grid-locators-and-special-calls/

BG5LU

哈希並非單向演算法嗎？

BA7LAC

BG5LU 因此，您偶爾可能會聽到無法解讀的頻道號碼。 <...>

BG5LU

Syryia 👍👍👍

CQCQCQ

雜湊值是不可逆的，因此接收端必須儲存呼號的雜湊字典。

BH6ABO

過去我也曾有同樣的疑問，知識+1

BG5GNC-NingBo

為什麼我的 wsjt 可以正常輸入長文本（16 個字），但在發送時卻發現後面的幾個字被截斷了？

BI1NIZ

如果查閱 WSJT-X 相關的文獻，就能得知...
https://wsjt.sourceforge.io/refs.html

Liridice

這個影片有點長，但講解得很清楚：
https://www.bilibili.com/video/BV1wm421G7py
每次觀測都能獲得新的收穫（甚至連偶爾在頻譜上看到訊號的開頭和結尾出現擴散現象是什麼原因呢，也都詳細說明了）。

Liridice

Syryia 原來如此，難怪 JTDX 經常會使用一個非標準的呼號並產生其雜湊值，但在下一次仍然無法辨識。

闽ICP备2021006864号-7

闽公网安备35020602002794号互联网举报中心

用户协议隐私政策社区规范积分规则中继规则转载须知
更新日志联系我们常见问题友情链接运营报告赞助

浩奇科技（厦门）有限公司

是无线电，把我们联系在一起