看了一下，你提供的字节码文件的 major version 是 49 （ 0x31 ），也就是 Java 1.5 ，如果你的反编译软件在 1.8 下工作，反编译并修改后重新生成的字节码文件的 major version 会变成 52 （ 0x34 ）。

你可以用十六进制编辑器确认下生成的字节码文件的第 7 和第 8 字节是不是 0x00 0x34 ，是的话，那肯定不能在 Java 1.6 下运行，Java 1.6 支持的最大 major version 版本是 50 （ 0x32 ）,有一定概率可以直接把 0x00 0x34 修改成 0x00 0x31 后就能运行。

何止 4444 ，你多试试以下接口，看有几个能用的：

TCP 42 135 137 138 139 445 593 1025 1434 1068 3127 3128 3129 3130 4444 5554 9996

UDP 1026 1027 1434 1068 5554 9996 1028 1433 135 ~ 139

我上次对接阿里和腾讯的 API 时也发现了，由于项目不能使用外部库，所以只能自己写，当时那叫一个恼火，一个功能有多个页面重复描述，多个页面描述得还不一致，参数给得不全，链接跳来跳去，请看这，请看那的……

还发现一点，腾讯阿里两家的 API 设计以及文档都很像，不知道是不是一伙人设计的还是谁抄谁的？

@cnbatch 我并不是想要说扒古典，而是想说难度稍微大点的就量化不来，只有那些单音儿歌或者套路和弦的曲子才能量化好。

@wongtk lomorage +1 ，它最吸引我的功能是可以删除本地照片后还可以查看远程的预览图，这是最接近 iCloud 的体验了，其他软件貌似都没有这个功能，可惜它是款国产闭源软件，且 UI 有点潦草。

@cjd6568358 你说的钢琴谱如果是指图片形式的谱，那你要找的是 Optical Music Recognition （光学音乐识别）软件，将图片谱转换成数字谱（ musicxml ），然后随便一个打谱软件都能生成音频。我用过的 OMR 软件有：

- 收费
- [CapellaScan （体验较好）]( https://www.capella-software.com/us/index.cfm/products/capella-scan/info-capella-scan/)
- [PhotoScore （体验较好）]( https://www.neuratron.com/photoscore.htm)
-
- [SmartScore （体验一般）]( https://www.musitek.com/)
- [ScanScore （体验一般）]( https://scan-score.com/en/)
-
- [SharpEye （体验较差）]( http://www.visiv.co.uk/)
- [PDFtoMusic Pro （体验较差）]( https://www.myriad-online.com/en/products/pdftomusicpro.htm)
-
- [PlayScore 2 （ IOS 端）]( https://www.playscore.co/)
- 开源
- [Audiveris （ Java ）]( https://github.com/Audiveris/audiveris)
- [Mozart （ Python ）]( https://github.com/aashrafh/Mozart)
- [Oemer （ Python ）]( https://github.com/BreezeWhite/oemer)
- 在线
- [Soundslice （收费，基于深度学习）]( https://soundslice.com)
- [Maestria （收费，基于深度学习）]( https://newzik.com/maestria)

@murmur 你能推荐一个将人类弹奏的 midi 量化得比较好的软件吗，就钢琴流行曲五六级级别的曲子就行，我试了很多，没一个量化后能达到友好可读级别的，更别说古典奏鸣曲哪些难度的了。

音轨分离和音符转录反倒不是最难的，已经有较为成熟的开源项目，最难的反倒是最后一步，如何将提取到的音符的音高和时值转化为谱子。
因为人类弹奏时的时值是不标准的，比如同样是四分音符，前一个按下的可能是 0.5 秒，后一个按下的是 0.3 秒，很难确定该把它量化成四分音符还是十六分音符，时值更短的音符就更会出现这种情况了，这会导致音符对不齐，得到的谱子是错乱的。

太难了，钢琴应该是最好处理的了，都无法做到。
比如 2020 年时字节就发了篇钢琴转录的论文，并提供了代码，准确度有百分之九十五以上，虽然生成的 midi 用来听还不错，但想生成人类友好可读的谱子，感觉很难。

妹吻

@SoyaDokio 玄学的尽头是迷信

19 年买的，21 年左右召回计划换新过一次，现在症状和你的一样，还多了个破音的毛病，不过高强度用了四年挺值的，反倒是同一时间买的头戴 1000xm3 没用几次，耳罩全都老化裂开了，有点亏。

@qixinwuchen 为什么你认为印度人读的就是对的

你直接参考 Bitwarden 实现吧，和你的需求符合，它把用户名邮箱作为盐，然后经过多次 PBKDF2 处理。地址： https://bitwarden.com/help/bitwarden-security-white-paper/

貌似我理解错了，你是假设服务器被入侵，用户传原密码到服务器验证时原密码泄漏，那前端的盐确实只能用固定值了，否则无法验证。

你可以去看看 Bitwarden 的安全架构，或许有帮助，好像它的登录原密码貌似也不传到后端。

“但如果黑客连这个盐值也获取了，重新制作彩虹表也是可以的”，一个密码一个随机盐，然后将盐和哈希一起发送到后台，黑客能获取到盐那必然能获取到哈希甚至原密码，还考虑什么彩虹表。还是你以为前端直接写死一个固定的盐，然后被黑客查看代码获取？盐要在内存中随机生成，一个密码生成一个盐，不要固定用一个值。

@elevioux 用 Abbyy 效果还可以更好，会自动分析哪些是图片哪些是表格，也可以手动框选哪些是图片哪些是表格，Acrobat 也有用 Abbyy 家的技术。

用 Abbyy Finereader 先转换成 docx ，然后再转换成 md

@janwarlen 一个针对所有代码，一个针对 python 代码，一个针对自然语言指令