比如回复别人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-xが頻繁に非常に長いメッセージを受信できるのでしょうか？

swimmingcat

例えば、誰かのCQへの返信の場合：
YU1EA BI1RLR -18
すでに16文字で、正常に送信でき、相手も正常にデコードできます。

BG6QED

特定のデータ圧縮プロトコルを使用して、コールサインおよびグリッドで使用されるデータのビット数を削減します。例えば、高速ハッシュアルゴリズムを使用してコールサインを固定長のハッシュ値にマッピングし、送信時にはそのハッシュ値を送信するだけです。https://do1alx.de/2021/the-pitfalls-of-ft8-grid-locators-and-special-calls/