对了，还可以试用视频播放器 nPlayer。去广告买 Lite 版本就行了。应用本身支持启动密码（应该够了吧，因为 iOS 有文件隔离机制，所以也许不需要真正“加密保存”），支持 WiFi 传输照片和视频（并且视频播放的本职做得很好）。

我也用过很长一段时间的计算器+，不过不确定是哪个版本。按理文件传进去应该是不会改变的，楼主可以试试 App Store 上其他同名应用。

哇。我计划工资的时候设立了专项补票基金。这下待购买软件 +1

@shintendo 让我想到以前论坛里用加密压缩包，哈哈。

@lovestudykid
@auchan
我说的隔壁是 Magi 啦（逃

堪萨斯的吗？刚看某群里说已经恢复了，试着重启看看。

@pi1ot 唔，你域名打错了。请看 https://www.hi-pda.com/robots.txt

原则上如果真的给挡了，百度甚至就不该显示这条索引结果。个人认为这还是在打擦边球，你看隔壁就清新很多：

> 一些其他的搜索引擎有时会利用 anchor 等信息，对特定被禁止抓取的路径（如首页），生成和 nosnippet 等同效果的展现，但我们会慎重处理这种灰色地带的行为。

转网后可能出现第三方话费充值失败，不能参加新运营商营销活动的情况。具体不清楚，以前的活动细则好像写过。以后可能会好转吧。

看楼主发了几个帖子没人回复，我还是回帖支持一下吧。顺便 Mark 一下。

NAT 类型是 F 好像是 UDP 不通的意思，可能服务商不提供 UDP 转发。
CN2 裸连可以试试 udp2raw、udpspeeder 一类的工具。

完全可以。但是 AES 256 要求密钥长度为 256 位，一个照片文件会刚好固定在 256 位吗？到头来还是要 hash。

@Mohanson 信道安全不安全不能一概而论，看是要防止窃听者还是中间人。诸如 DH 这类密钥交换算法，可以在不安全的信道中安全地交换密钥，不过不能防止中间人攻击。

有意投递。应该不限福建学校吧。

感觉氛围不错，Mark 一下。

楼主竟然在代码里投毒！

因为基于花密做了自己的修改版（ https://shansing.com/read/477/ ），我看到楼主也是记忆密码＋区分代号的形式（之后也从代码看出借鉴花密的地方），想稍微看看优缺点（其实主要是看缺点的，逃）。花一会儿工夫看懂代码以后，却怎么也调试不出预期结果。费了好几番心思才发现，楼主提供的 .js 和 .min.js 不一致！我调试时用网页加载的 .min.js ，然而看代码用的 .js 。进一步分析认为是 punctuation 变量不同值导致的。

然后来说说我的拙见。

楼主的可选项确实比我的丰富一些：我的沿袭花密，没有让用户决定更多东西。让我感兴趣的是，楼主是怎么将“使用标点”和“禁用标点”融合在一起的。看代码，原来是使用了可改变的字母表（ alphabet 变量）。然后根据 hash hex 每个字符的 ASCII 码，每次累加，索引字母表。初看我觉得这个想法很好，不过越想越觉得不优雅。

现在讨论 .min.js 那一套，也就是网页上使用的算法；默认设置，即使用标点，字母区分大小写。根据 hash hex 的特性，每个字符只有 16 种可能，加上大小写的指定，有 22 种。那么对应的 ASCII 码也是 22 种可能（ 48~57，65~70，97~102 ）。由此得出，最终密码的第一个字符必然是 GHIJKLMNOPXYZabc456789 其中之一。之后的累加，也只有 22 种特定分布的步长，也许会造成最终密码中一些字符比另一些更可能出现。话说回来，即使步长是均匀分布的，也会造成类似情况。当然这不是硬伤，只是最终密码没有看上去那么强壮。

我能想到的暂时是这样。不知道楼主为什么要混淆 hash 值，在我看来这既没必要（除非坚持可变字母表）也增加安全风险，好似篡改了 hash 算法。而密码学最佳实践要求，不要自造加密算法。我想 hash 算法是类似的道理吧。

不错诶。之前就经常有单线程速率不如多线程的情况，这下可以提速了。

刷新 csrf token ？