印象中弃用的原因，好像是因为这个 APP 实质的原理是 ctrl+c 复制选中的文字之后再做操作，这样就导致了不少和剪贴板有关的小问题。

然后这个 APP 之所以这样做，好像是因为 macOS 并没有一个取当前选中文本的 API，只能这样来实现。


V2 上搜一下，也能看到不少相关的讨论：
https://www.v2ex.com/t/351750
https://www.v2ex.com/t/335208
https://www.v2ex.com/t/308828
https://www.v2ex.com/t/300874

记忆中很久以前就买了，但是因为小 bug 的原因，已经弃用了一两年……

@chomoon #5
哈哈哈哈哈差不多，应该是：这还不走难道等着过年嘛？

除非你本身已经有部分前端经验，否则的话，能提出这种要求的公司，我觉得属于典型的 “等过年” 问题了……

天要下雨娘要嫁人员工要吃饭

这个问题的本质似乎来自于双方对于产出的预期有差异。

作为甲方，产品经理对产出的要求似乎是：“一份有准确描述的设计稿，调整字体即可，其它的交给前端搞掂”，
楼主作为 “设计外包” 的一方，要求似乎是：“一份有足够质量的设计稿，以及一份有足够质量的实现稿”

港真，你们这个角色错位我感觉很奇怪啊……
大部分情况下，不应该是甲方一直加戏，乙方一直懒得做么 https://ws3.sinaimg.cn/bmiddle/62e721e4gw1et02ek7u61j200k00k3y9.jpg


我觉得楼主你在这件事情上，超出权责范围过多了，在甲方看来，这原本似乎只是个 “改动字体” 的事情，却变成了 “结构和排版细节方面的优化” ，虽然在楼主看来这属于服务周到，但也许甲方会感受到一些冒犯。

“今后的项目” “字体之外的问题” “凭空增加的工期” “对实现方式的干涉”
以上这些东西，如果大家是同一个团队的，也许会是打磨项目、提升团队的好方式。
但是作为 “外包” 身份，这些都大大超出了自己的权责边界，既搞的自己很累，对面也大概率不领情。

https://ws2.sinaimg.cn/large/760b39b3gy1fy6to00opcj214s08c0wj.jpg

忘了正题了，这里实际牵扯到的问题，印象中之前看到过文章是这样讲的（来源已经记不清了，不确保细节正确）：

GCJ02 的加解密资质和相关设备，是需要相关资质、需要花钱买的，而且买回来就是个整体，对外黑箱状态，你输入进去参数，它输出结果给你，还限制频次和使用规模，完全就是一个贼难用的东西。

这么难用，实际中真正完全使用它的人就很少了，即使自身有资质的大厂，用着也觉得难受啊。
那大家都怎么用呢？用破解版呗~~
没错，就是游戏玩家喜闻乐见的买了正版以后下盗版玩儿的状态~~

于是各家就根据自己的手头数据，搞起了逼近算法，网络上也开始出现了各种公式和 API 服务，但是别忘了，这些都是 “盗版” 啊，都是 “逼近” 啊，也就是说，都不精确啊。

而如果你作为 APP，取到了地球坐标，那更闹心了，因为加密也是 “逼近” 公式啊，于是乎，一个坐标，从取出来，到被展示在地图上，经历了 N 次 “逼近”，总算是偏离了原始坐标了。

获取坐标 --(转成火星)--> 发给地图 SDK --(转回地球)--> 展示在地图
地球坐标 1 --(逼近算法 A)--> 火星坐标 2 --(逼近算法 B)--> 地球坐标 3

注意，A B 都是猜的逼近算法，并不配套，这样一来一回，坐标已经偏了不少了。
于是，一万种逼近算法，就产生了一万个火星，和一万种火星坐标~~

好奇楼上上来就说火星坐标的朋友，你们是否有仔细看楼主的帖
https://ws2.sinaimg.cn/large/760b39b3gy1fy6s2h0ynij20ws068jsg.jpg

楼主明明是知道 “火星坐标” 这件事儿的，让楼主难受的是：每一次 “加解密”，都在丢失精度。

按道理来说，地图坐标虽然改来改去，但是大体上是三种：
（引用自 https://tool.lu/coordinate/ ）
WGS84 坐标系 地球坐标系，国际通用坐标系
GCJ02 坐标系 火星坐标系，WGS84 坐标系加密后的坐标系； Google 国内地图、高德、QQ 地图 使用
BD09 坐标系 百度坐标系，GCJ02 坐标系加密后的坐标系

但是你们注意楼主贴的图里，给出的居然是五套不同的坐标。
这里的 “谷歌地图” “腾讯高德” “图吧地图” 按道理来说，应该使用的都是 GCJ02 火星坐标才对，然而他们的火星居然还不是同一个火星。（根据谷歌地球坐标不一致可以推断此处谷歌地图为国内版）
这就给楼主带来了一些困扰，即使想尽办法，都使用火星坐标，也无法确保位置都精确性，给楼主做地图相关的产品带来了很大困扰。


BTW：楼主使用的查询页面是这个：
http://www.gpsspg.com/maps.htm

0:01 翻车

再次强调，这个问题本质上并不是一个 “ UDP 广播” 的问题。
你需要研究的是二层的数据帧，而不是 UDP 协议。

关于 airkiss，网上也是有一些分析文章的，简单看一下就可以发现，它仍然是基于对二层帧的修改的：
https://blog.csdn.net/flyingcys/article/details/50248537

>在实际应用中，我们采用 UDP 广播包作为信息的载体。信息发送方向空间中发送一系列的 UDP 广播包，其中每一包的长度(即 Length 字段)都按照 Air Kiss 通信协议进行编码，信息接收方利用混杂模式监听空间中的无线信号，并从数据链路层截取 802.2 SNAP 格式数据包，便可得到已编码的 Length 字段，随后接收方便可根据 Air Kiss 通信协议解析出需要的信息。

BTW：
楼主请仔细看 5 楼的回复，他回复的内容，对实现这个功能很重要。
这个功能并不是一个简单的 “ UDP ” 通信问题，而是如何巧妙的构造携带有数据的 “二层帧” ，至于 UDP，那只是构造这个帧的 “副产品” 而已。

@smallgoogle #8
没看我的回复？我以为我已经讲的很清楚了

https://ws2.sinaimg.cn/large/760b39b3gy1fy3tg45ohcj20j004it9q.jpg

放个多年前的回复，当时研究的是庆科的 easylink

/t/183822