完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
电子发烧友论坛|
Heloi需要向文件中添加CRC以确保它没有被破坏。有没有和谐的函数来计算CRCs，或者我应该自己实现它吗？我在CB模块中看到了一些功能，非常感谢，Stephane。
以上来自于百度翻译 以下为原文 Hello I need to add a CRC to a file to insure it is not corrupted. Is there any functions in HARMony to calculate CRCs or should I implement it myself? I see some function in the CLASSB module. Thank you very much, Stephane. 
0
|
|
相关推荐
15个回答
|
|
|
HelloIt用HTTP将文件从客户端传送到服务器时，似乎已经有CRC了，这是真的吗？我需要添加CRC吗？谢谢史蒂芬！
以上来自于百度翻译 以下为原文 Hello It seems there is already a CRC when transferring a file from a client to the server with HTTP, is this true? Do I need to add a CRC? Thank Stephane.! |
|
|
|
|
|
嗨，它认为HTTP协议API调用TCP层API，因此CRC已经在TCP协议中得到注意（这是UDP的主要区别之一）。
以上来自于百度翻译 以下为原文 Hi, It think http protocol APIs call TCP layer APIs and therefore CRC is already taken care in TCP protocol (this is one of the major differences with UDP) Regards |
|
|
|
|
|
事实上，UDP也应该受益于32位CRC…如果我没有错（低级以太网）
以上来自于百度翻译 以下为原文 Mmmm actually also UDP should have benefit from a 32bit CRC... if I'm not wrong (low level Ethernet) |
|
|
|
|
|
HI，问题是UDP，包可能丢失、复制、无序和UDP不关心…没有应答没有请求重新发送…TCP负责所有这些问题。您在接收插座中读取的是100%有效的。因此UDP对于流来说是好的，因为更高级别的协议可以使用这些问题（MPEG音频和视频编解码器）。因此，如果你做一个UDP应用程序，你需要在你的应用程序中关心这些问题。这就是为什么TCP协议栈比UDP一个要大得多的原因。
以上来自于百度翻译 以下为原文 Hi, The issue is that with UDP, packets can get lost, duplicated, out of order and UDP does not take care....no acknowledge no request for resending...TCP takes care of all these issues what you read in the receiving socket is 100% valid. So UDP is good for streaming because higher level protocol can live with these issues (MPEG audio and video codecs). So if you do a UDP application, you'll need to take care yourself of these issues in your application. That is why TCP protocol stack is much larger than UDP one ;=) Regards |
|
|
|
|
|
Hellook谢谢，所以你确认用TCP/HTTP验证接收数据的完整性是没有用的吗？我需要下载/上传的文件是我的系统的整个配置，一个比特错误可以改变行为。非常感谢你的帮助！Stephane。
以上来自于百度翻译 以下为原文 Hello Ok thank you, so you confirm it is useless to verify the integrity of received data using TCP/HTTP? The file I need to download/upload is the whole configuration of my system, a single bit error can change the behavior. Thank you very much for your help! Stephane. |
|
|
|
|
|
我认为这可能取决于你如何发送文件。如果它是一个大文件，而你的更高级别的程序正在把它分解成更小的块，那么这些块会出故障吗？我不确定。如果你将文件作为一个消息发送，那么它将完全到达另一端，即使栈已经把它分解成更小的数据包。
以上来自于百度翻译 以下为原文 I think it may depend how you send the file. If it is a large file and your higher level program is breaking it down into smaller chunks to be sent, can those chunks arrive out of order? I'm not sure. If you send the file as one message, then it will arrive at the other end fully intact even if the stack has broken it down into smaller packets. |
|
|
|
|
|
是的，我认为数据完整性是通过校验和来保证的：但是病毒、意外的改变、“中间人”攻击可能是一个不同的问题，所以散列或类似的东西可以用于进一步的安全。
以上来自于百度翻译 以下为原文 Yeah, I'd say that data integrity is guaranteed by the checksum: but viruses, unintended changes, "man-in-the-middle" attacks can be a different problem so a Hash or alike can be used for further safety. |
|
|
|
|
|
TCP中没有CRC——有一个校验和，这是不同的。如果数据是关键的，将CRC（哈希甚至更好）添加到整个传输的文件/数据中是一个好主意，而不是每包都需要。
以上来自于百度翻译 以下为原文 There is no CRC in TCP - there is a checksum, which is something different. If data is critical, it is a good idea to add a CRC (a hash is even better) to the whole transferred file/data, not really needed per packet. |
|
|
|
|
|
瞧！谢谢你的确认。当你说散列时，这是以Sh256整个文件为例的吗？Stephane。
以上来自于百度翻译 以下为原文 Hello OK ! Thanks for the confirmation. When you say a Hash, this is to sha256 the whole file for example? Stephane. |
|
|
|
|
|
对。MD5也会这样做，但会提供更少的安全性-取决于你的应用程序：你关心的是数据完整性或一些攻击。
以上来自于百度翻译 以下为原文 Yes. MD5 will also do for this, but will offer less security - depends on your application: you're concerned about data integrity or some attacks. |
|
|
|
|
|
你好，谢谢。我已经在服务器和客户端上使用了Sa256，所以我将使用它来实现数据完整性。因此，这也是回答第一个问题的第一个问题。谢谢！Stephane。
以上来自于百度翻译 以下为原文 Hello OK thank you. I have sha256 already available both on the server and client so I will use it for data integrity. This therefore also answer the first question of the very beginning. Thank you! Stephane. |
|
|
|
|
|
很难看出两者之间的区别：但我同意，它们是一个“完全内容”CRC，即散列是有用的。
以上来自于百度翻译 以下为原文 Hard to spot the difference |
|
|
|
|
|
Heloi猜想校验和是所有字节的一个简单的总和或异或，而CRC是基于一个多项式，它是基于可以更好地检测错误的应用类型来选择的。
以上来自于百度翻译 以下为原文 Hello I guess the checksum is a simple sum or XOR of all Bytes whereas a CRC is based on a polynomial which is chosen based on the type of application which can better detect errors. Stephane. |
|
|
|
|
|
嗯，但是每一个以太网帧都应该有一个CRC32校验和，多项式，在上面：HTTPS://IT.WiKiTo.Org/Wik/FrimeCuffixStaseStand，然后你可能想要一个“完整文件”CRC，哈希。
以上来自于百度翻译 以下为原文 Mmmm yeah but each Ethernet frame should have a CRC32 checksum, polynomial, over it: https://it.wikipedia.org/wiki/Frame_Check_Sequence then you may want a "full-file" CRC, the hash. |
|
|
|
|
|
你好！谢谢！我想如果使用Sa256，我将确保它，因为我已经在堆栈中的Sa256。谢谢Stephane。
以上来自于百度翻译 以下为原文 Hello OK thank you! I guess if using SHA256 makes it, I will secure it since I have sha256 in the stack already. Thank you Stephane. |
|
|
|
|
只有小组成员才能发言，加入小组>>
5079 浏览 9 评论
1954 浏览 8 评论
1888 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比？
3115 浏览 3 评论
请问电源和晶体值之间有什么关系吗？PIC在正常条件下运行4MHz需要多少电压？
2186 浏览 5 评论
633浏览 1评论
506浏览 1评论
有偿咨询，关于MPLAB X IPE烧录PIC32MX所遇到的问题
370浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
535浏览 0评论
440浏览 0评论
/6 
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
1466
评论
淘帖
4667
