然后火了之后，不约而同的做起了贷款业务，古代成为放印子钱

https://github.com/Shilyx/DisableMicrosoftPinyinIMESlash

我的改键的程序，稍微一改就行，开机自启就完事了

岳母眼中的工具人+软柿子，悲。。。

又是就差一个程序员
而且这个项目不能过多说，因为这里面有“创意”，说了被人复制了怎么办？到时候他用我的想法颠覆了世界，我不就亏了？

敏感啥啊 

看起来你需要一个长 hdmi 线

ntfs 特性，这个文件可以作为 abc 的附属，在 ntfs 上转移的时候会自动跟随

https://github.com/Shilyx/SlxCom/blob/297a5a484229429df984854b3215702f6a53aa98/SlxCom/SlxComExpandDirFiles.cpp#L83

这个项目就是利用这一点扁平化处理文件夹内容

rust 很丑，不建议使用

基本上 C/C++的一些不便不必要用 rust 来填补，golang 、c#分担一些就很舒适了。

其实这个题在问:
"既然你说你懂 JS，那么能否用 JS 证明你不懂 JS ？“

第一步，用 c++实现这个功能，代码保存好，不要编译（重要）

第二步，写一个脚本，自动编译 C++代码并执行

第三步，用操作系统计划任务定时调用这个牛逼的脚本

NAT 给一般人提供了极大的保护

没有 NAT，网络世界会很不安全

适合的从业者在开始都是这种状态

但不是所有这种状态的人都成为了适合的从业者

认知曲线了解一下，四个阶段你只处于第一阶段而已

楼主考虑的对，很多留言者没考虑到需求点在哪

有人说 tls，那是对过程加密。过程上的监听者就是个假想敌，如果有人想从链路上截获你的数据的话，你基本拒绝不了。技术上拒绝，生理上也拒绝不了，多说无益。几乎没有人在链路上截获你。
但不是说不用 tls，有条件还是要上。

解压密码，最简单的是调用 7z.exe 解压，密码很容易在使用中被抓到。就算你继承了动态库、静态库，关键调用还是很容易被分析出来。如果是源码级魔改并融合 7z，那工作量是直线上升。
就算解决了加密问题，100M 的文件常规思路还是解压到临时目录来使用，很容易被发现的。全加载到内存，按数据结构组织后轻松上 500M 。

楼主的需求可以总结为：
1 、文件到了终端，依然作为一个格式不明的加密文件存在
2 、加密文件支持随机读取，不一定要读取就全部解密

推荐基于 aes 搞一个自己的加密算法。
aes 仅仅是对 16 字节的输入给出 16 字节的输出而已，距离直接应用还有一段距离。需要选择一种模式，简单的 ecb 或好一些的 cbc，密码用二进制，加密文件格式分好段，做好 padding 和校验。这一切自己完成的话，光凭一个文件，几乎是破解不了。

很多公司不需要多么高质量的项目或产品。

研发上的诸多问题最容易被发现，解决的很少。

然而很多真的不需要去解决，公司死不了的。

5 、文件内容几乎被变换全部覆盖，不存在未变换的超过 10 字节的区域，部分恢复无望

不应当是格式转化的问题，可以观察出这个文件依然是正常 xlsx 文件的变换结果，中间没有 xls 或 csv 的痕迹

正常 xlsx 本质上是 zip 文件，非固实，内容是分段存储的，会有大片连续的 0 值，和其余更多的杂乱到极致的压缩空间。观察这个错误的文件，能够发现 0 值的痕迹。

真正的 0 值是空白，这个文件中的 0 值区域仿佛是薄纱覆盖。可以得出文件被加密变换的结论。

文件可能内容并未丢失，但是被加密了。可能的加密者是电脑加密软件或勒索病毒。

从文件头 PK 变为 pK 向下推，可知错误文件和正常文件的差异是：
20 00 80 40 80 00 80 00 00 。。。。。。

观察 65 字节以后（正常文件是 0 值区域），差异是：
00 00 00 02 00 00 。。。
后边还有：
20 00 00 80 20 01 。。。

后续还有不少 0 值区域，还有文件名字符串区域，可以看出加密变换的痕迹很明显。

加密向量随机性不强，很多不变换或只变换高 16 比特，肯定不是 aes 等算法来的。加密向量是不断变化的，不是循环往复的，不容易破解。

结论：
1 、是 xlsx 直接加密变换的结果
2 、加密向量随机性低，保留了部分文件原貌，但足以破坏文档格式
3 、难以破解
4 、请查找是否有安装加密软件，或中招勒索病毒