但这不适用于您遇到的
> 似乎一级目录 vger.kernel.org/没有链接或者列出二级目录
> 但维护网站的人最好能提供链接吧？这个网站有好多有用的 pdf 和 ppt

wget -r 不过就是像爬虫那样去跟踪下载到的 html 中所有 url 并递归下载下来

win 上也有个类似 wget -r 的商业软件 https://metaproducts.com/products/offline-explorer
我以前用过破解版 archive 过几个小网站

wget --recursive
https://www.gnu.org/software/wget/manual/html_node/Recursive-Retrieval-Options.html
https://stackoverflow.com/questions/273743/using-wget-to-recursively-fetch-a-directory-with-arbitrary-files-in-it

所以拥有 aes 解密密钥的 shc 程序并不位于`不信任的环境`之中？
shc 只是负责解密变回合法 bash 字符串后把 bash 字符串传给`不信任的环境`来 eval ？

您需要控制{}的插值也就是那个 id 变量的取值区间，如果他来自程序内部那还比较容易保证其合法（比如您 1 楼所说的`query.order 是请求接口传过来的值，是一个枚举类型`），如果是用户输入您必须得假定恶意对它做合适的过滤甚至白名单

#15 @h0099 所说的 `给 query builder 传入 raw 部分如 selectRaw(用户输入)`实际上就是
#21 的`同时混用 字符串拼接 和 prepared statement 的传参插值`
您可能会觉得我从来都没有做过 在 prepared statement 里又直接拼接了用户输入 的罪恶行径
但实际上 orm 的 query builder 通过抽象隔离使得您在使用其提供的 selectRaw()等 api 时也忘记了这实际上就是危险的拼接

@GreatAuk 他的意思是前后端分离做好后前端就只是一大堆静态资源 htmljscss ，所以这些静态文件随便托管在哪儿都可以只要用户能在访问域名时下载到这些文件
那么前端静态资源的并发就是看您托管的地方的并发了，而这基本是不用担心的
因为 oss 和 cdn 服务端所做的不过是去缓存（当然可能 cache miss ）里读取一些文件响应而已，也就是 nginx 等 webserver 最擅长的事

win8.1 50~60 个
https://i.imgur.com/j0kt669.png
https://i.imgur.com/pQyBsta.png

回顾上个月的新闻： 微软希望通过将功能与 explorer.exe 解耦来提高 Windows 11 的运行速度
https://www.windowslatest.com/2022/12/22/microsoft-wants-to-make-windows-11-faster-by-decoupling-features-from-explorer-exe/

#19 @IvanLi127 phpdelusions.net/pdo/sql_injection_example 所举的例子就是典型的同时混用 字符串拼接 和 prepared statement 的传参插值以实现将用户输入用于无法作为 prepared statement 的传参插值的地方（原文例子中是用于 UPDATE ... SET 子句，现实中更常见的就是 SELECT ...子句的字段名，或是楼上 ORDER BY ...子句的字段名），所以字符串拼接是这的短板

#20 @IvanLi127 byte0x39=字符串 9 是 ASCII 里的，不论什么 EASCII 编码都不可能修改掉这个 0x39 对应 9 的关系（顶多像 SHIFT-JIS 那样把\改成￥），那么您所说的转了几手难道是传输给使用远古的 BCDIC 编码的环境里了吗？还是阁下直接在前端验证用户输入白名单，所以无法保证后端收到的就是 0x39 byte ？

@sorcerer 单纯的没有，但只要遇到有意无意的把用户输入直接拼接进字符串那就需要对用户输入做严格的过滤（如正则）甚至白名单（如只允许已知字段名）

@opengps nginx 当然可以设置非 localhost 的其他局域网甚至公网 ip upstream server
http://nginx.org/en/docs/http/ngx_http_upstream_module.html
http://nginx.org/en/docs/http/ngx_http_proxy_module.html
因此 nginx 也可以跑在一个独立机器系统上，而前后端跟 nginx 可以有也可以没有物理上的关系（只要能通过网络访问就行）
那些 load balancer 不就是这种模式

/dev/random 无疑是密码学的更好选择。即使 /dev/urandom 相对安全，也没有理由选择后者。

事实： /dev/random 有一个非常讨厌的问题：它会阻塞。

但这很好！/dev/random 给出的随机性与其池中的熵一样多。/dev/urandom 会给你不安全的随机数，即使它早已耗尽熵。

事实：不。即使不考虑可用性和随后的用户操纵等问题，熵“耗尽”的问题也是一个稻草人。大约 256 位的熵足以在很长很长一段时间内获得计算上安全的数字。

#23 @wangyu17455 https://www.2uo.de/myths-about-urandom/ 早已指出（机翻）：

/dev/urandom 是一个伪随机数生成器，一个 PRNG ，而 /dev/random 是一个“真”随机数生成器。

事实： /dev/urandom 和 /dev/random 都使用完全相同的 CSPRNG （一种加密安全的伪随机数生成器）。它们仅在极少数方面有所不同，与“真正的”随机性无关。

/dev/random 无疑是密码学的更好选择。即使 /dev/urandom 相对安全，也没有理由选择后者。

---
因此，要明确一件事：/dev/random 和 /dev/urandom 都由同一个 CSPRNG 提供。根据一些估计，只有当它们各自的池耗尽熵时的行为不同：/dev/random 阻塞，而 /dev/urandom 没有。

从 Linux 4.8 开始
在 Linux 4.8 中，/dev/urandom 和 /dev/random 之间的等效性被放弃了。现在 /dev/urandom 输出不是来自熵池，而是直接来自 CSPRNG 。

另外对于搜索标签这种类似 https://www.v2ex.com/t/900089 的场景
我合理怀疑您现在是直接把每个 item 所具有的 tags 直接序列化后存在 item record 的某个 field 中
就好比 item1 有 3 个 tags：a 和 b 和 c ，那么您直接把这仨 abc 拼在一起变成`a,b,c`然后作为这个 item 在数据库行（ record ）中的一个列（ field ）的值

从关系代数的角度看，这是违反 1NF https://en.wikipedia.org/wiki/First_normal_form 的，因为您没有将符合一对多关系的 item->tags 关系给拆出单独的 item-tag 中间表

而为了 1NF 您需要建立 `表述所有可能存在的 tag 表` 和 `表述所有 item 与 tag 的一对多关系的表`
前者我假设您已经有了

后者就是一个只有两个字段的表：itemId 和 tagId ，同时 UNIQUE 约束建立在这两个字段上（因为对于单个 item 不应该具有多个完全相同的 tags ，除非这也是您的需求）
把关系数据填充进这个表之后
想要查询某个 item 有哪些 tag 只需要`SELECT tagId FROM 这个表 WHERE itemId = 您要查的 item`
想要查询某个 tag 下有哪些 item 只需要`SELECT itemId FROM 这个表 WHERE tagId = 您要查的 tag`

#41 @yezheyu 阁下又凭什么假定浏览器内部实现这些 dom event 时写的是 js 代码用的是 js object ？
什么又叫“区别于一般的任务”？什么是您所说任务？

我已于#38 解释
> 那为啥 button 点击事件的回调函数中 this 会指向事件的触发对象 button 呢？而不是 window ？

您可以理解为有一个`buttonClickCallback.call(buttomElement, clickEvent)`的 js 被执行
您也可以自己执行这个`.call(buttomElement)`，同样会改变回调（只要不是用 arrow fun 语法声明的）的 this 为 button

#40 @Al0rid4l 不过也不是什么很难的东西, 规则就一句话的事
一句话解释 js 的奇妙深刻 this：
函数的闭包作用域是在声明时从声明处的词法作用域向上捕获所有会被函数引用到以及不论是否用到都捕获的 this 的上下文符号集合。对于使用 function()语法声明的函数，允许使用.bind/apply/call(thisArg)来重新定义该函数闭包作用域中的 this 指向，但对于 arrow fun 语法() => {}则不允许（因此 arrow fun 的 this 指向是 immutable 的）

这就像一句话解释 monad：
单子是自函子范畴上的幺半群
一样的正确但又令萌新完全听不懂
如同 https://www.v2ex.com/t/900380

#10 @wtfedc ASCII 0x39 不是`9`吗，纯数字有啥风险？
#12 @IvanLi127 prepared statement 也不是银弹：
https://www.v2ex.com/t/908249#reply15
> phppdo/jdbc/dbdriver 层提供的 prepated statment 不是银弹，无脑 escape 掉用户输入中的所有 sql 语法所使用的特殊字符也不是银弹：phpdelusions.net/pdo/sql_injection_example#escaping

`请不要在每一个回复中都包括外链，这看起来像是在 spamming`

让我康康您的
- 表结构（ SHOW CREATE TABLE ）
- 执行的 SQL
- `EXPLAIN SQL`结果
不然您说这么多也都是模糊的

@ragnaroks 这是使用大多数 orm 附带的 query builder 来构造您要查询的各个 clause 组成，最后由 query builder 来把他们变成 rawsql ，只要您不给 query builder 传入 raw 部分（ query builder 通常会把所有是字符串的都作为 prepared statement 的插值参数），如`selectRaw(用户输入)`那就是安全的