V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  amiwrong123  ›  全部回复第 2 页 / 共 39 页
回复总数  777
1  2  3  4  5  6  7  8  9  10 ... 39  
@ho121
规则下面的命令的缩进没了
@ho121
%.d: %.c
@set -e; rm -f $@; \
$(CC) -M $(CPPFLAGS) $< > $@.$$$$; \
sed 's,\($*\)\.o[ :]*,\1.o $@ : ,g' < $@.$$$$ > $@; \
rm -f $@.$$$$
@ho121
意思$*是$* 代表所有命令行参数呗?

但是放在这里是啥意思啊,是给 sed 的命令行参数吗?还是我给 make 的命令行参数啊?
@llxvs
OK ,感谢解答。

:: 验证用户输入的选择是否在范围内
for %%i in (%selection%) do

其实我这个循环里也有 注释,但这个循环没有问题,,看来是出问题是有概率的呗
@llxvs #1
所以,这全是 注释的锅了呗?
@llxvs #1
Available files:
1 type1.bin
2 type2.bin

Please select the file numbers you want to copy (1-2).
For example: 1 2 to select all files.
Press Enter to use the default selection: 1.
Your selection [default: 1]: 1 2

1 type1.bin
Copying type1.bin from new to current folder...
已复制 1 个文件。
type1.bin md5 is "def8bca03fab3781b90158550d40d377ab57e906"

2 type2.bin
Copying type2.bin from new to current folder...
已复制 1 个文件。
type2.bin md5 is "2137abf34c69627d936177dbd5d80e6540bc3cfd"
Done
请按任意键继续. . .

按你说的。我干脆把 最后那个双层循环里的 注释都删掉了,然后居然好了,神奇
@kkocdko #3
好的,后面我去尝试一下。

我做 gif 的目的,只是用语雀写个人技术博客时,某篇文章需要有动图来表现操作步骤(这样效果比较好)。用视频的话,也能达到我的目的。

目前的需求 只是记录一个几秒钟的操作即可。唯一一个强需求是,需要能 显示我的按键(比如我按了 ctrl+C 之类的)。层主有推荐的软件也可以推荐下,哈哈。
@Boyang #1
哦哦,好吧。那大小差异就不影响 书籍里的内容了。应该都是一样的内容了。
@PTLin
谢谢,这应该就是我想要的官方链接~
@YGHMXFAL
谢谢解释。
是别人写的 sh 脚本里面的一句,因为不是很懂,就拿来问一下了~

确实你这个写法好得多,学习了。
@ho121
然后"$code"会变成'FF',这么理解吗?
然后 这三个 单引号对(都是单引号对了),就合成了一个字符串。
@ho121
好吧,原来是这么看的呀,我还理解错了。我还以为是单引号,里面又有单引号
@Xheldon #29
哈哈,没想到有你这个应用场景。
@mark2025 #41
authorized_keys 我知道是服务器用来验证客户端的身份的。
你说的“认证服务端”,是指那个客户端保存的 known_hosts 文件吗?

但我看了 known_hosts 的用法:
A 通过 ssh 首次连接到 B ,B 会将公钥 1 传递给 A ,A 将公钥 1 存入 known_hosts 文件中,以后 A 再连接 B 时,B 依然会传递给 A 一个公钥 2 ,OpenSSH 会核对公钥,通过对比公钥 1 与公钥 2 是否相同来进行简单的验证,如果公钥不同,OpenSSH 会发出警告, 避免你受到 DNS Hijack 之类的攻击。

---------

只是一个很简单的对比 公钥 1 和公钥 2 啊
@expy #39
那如果是不省事的做法呢,还会做啥呀
@churchmice
为什么没有这种说法啊?签名操作的本质不就是一个加密操作吗
@NessajCN #18
OK ,感谢回答,理解了。这中间会有一步算哈希的步骤。

签名:
发送方计算 data.txt 的哈希值,然后使用自己的私钥对哈希值进行签名,生成 signature.txt 。
接收方使用发送方的公钥验证 signature.txt ,确保 data.txt 未被篡改且来自预期的发送方。

-------------------------

问一个比较笨的问题,把上面的过程改成:
用私钥对 data.txt 全文加密。这种方式不常用吗?或者本身这种有什么弊端?

主流的,应该还是,发送方先算出哈希值,再对哈希值进行加密吧。
@NessajCN #15
我好像懂 你意思了,我之前一直误解了。。

假设有一个文件 data.txt ,我们分别对其进行加密和签名:
加密:
发送方使用接收方的公钥对 data.txt 进行加密,生成 data_encrypted.txt 。
接收方使用自己的私钥对 data_encrypted.txt 进行解密,恢复 data.txt 。
签名:
发送方计算 data.txt 的哈希值,然后使用自己的私钥对哈希值进行签名,生成 signature.txt 。
接收方使用发送方的公钥验证 signature.txt ,确保 data.txt 未被篡改且来自预期的发送方。

上面这段是大模型的回答,所以“用自己的私钥对哈希值进行签名”就是指,用私钥加密呗。
@NessajCN #11
啊?我理解错了吗。。
加密是:原 content -> 加密的 content
签名是:原 content -> 原 content+一个签名值
这不是两种操作吗
@NessajCN #7
而且我开始以为“私钥加密,公钥解密”这种没有用呢,差点被自己误导了。

也就是说,
“公钥加密,私钥解密”
“私钥加密,公钥解密”——软件的数字签名
“私钥签名,公钥验证”——httts 证书
都有应用场景。
只是最后两种应用场景的目的,都是一样的目的。
1  2  3  4  5  6  7  8  9  10 ... 39  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2578 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 20ms · UTC 15:38 · PVG 23:38 · LAX 07:38 · JFK 10:38
Developed with CodeLauncher
♥ Do have faith in what you're doing.