使用有限的信息计算总批量上传传输百分比
我有一个系统，它按文件上传到服务器，并在文件上传进度上显示一个进度条，然后在第二个进度条下方，我想指示所有排队上传的文件的批处理完成百分比。
我可以计算出的信息和算法是：
发送的字节数/发送的总字节数 = 第一个进度条（例如 1024KB 中的 512KB (50%)）
效果很好。 但是，假设我还有另外两个文件要上传，但两个文件大小都是未知的（因为只有在文件即将开始上传时才知道，此时文件被压缩并确定文件大小）我将如何制作我的第三个进度条？
我认为这是不可能的，因为我需要“发送的总字节数”/“发送的总字节数”来更大规模地复制我的第一个进度条的逻辑，但是我确实得到了一个有效的版本： “我们当前所在的文件编号”/“要发送的文件总数”返回批次的百分比，但显然不会增量更新，而且非常粗糙。
因此，经过进一步思考，我想如果我可以将当前文件％与该算法合并，我也许可以获得批次当前点的正确进度百分比。
我尝试了这个算法，但可惜没有这样的效果（对任何数学家来说很抱歉，这可能很明显为什么它不起作用）
(“我们当前所在的文件号”/“要发送的文件总数” ) * (“发送的字节数”/“发送的总字节数”)
例如，我认为在使用此示例进行测试时我处于正确的轨道上：2/3（第三个文件的第二个）= 66%（这是到目前为止是正确的）但当我添加 * 0.20（表示仅上传了第二个文件的 20%）时，我们又回到了 13%。我需要的只是33%多一点！我确实尝试了 0.80 和 a (2/3 * (2/3 * 0.2)) 的逆，
这可以在不知道要批量上传的整个字节的情况下完成吗？
请帮忙！谢谢你！
I have a system which uploads to a server file by file and displays a progress bar on file upload progress, then underneath a second progress bar which I want to indicate percentage of batch complete across all files queued to upload.
Information and algorithms I can work out are:
Bytes Sent / Total Bytes To Send = First progress bar (eg. 512KB of 1024KB (50%))
That works fine.
However supposing I have two other files left to upload, but both file sizes are unknown (as this is only known once the file is about to commence upload, at which point it is compressed and file size is determined) how would I go about making my third progress bar?
I didn't think this would be possible as I would need "Total Bytes Sent" / "Total Bytes To Send", to replicate the logic of my first progress bar on a larger scale, however I did get a version working:
"Current file number we are on" / "total number of files to send" returning the percentage through the batch, however obviously will not incrementally update and it's pretty crude.
So on further thinking I thought if I could incorporate the current file % with this algorithm I could perhaps get the correct progress percentage of my batch's current point.
I tried this algorithm, but alas to no such avail (sorry to any math heads, it's probably quite apparent why it won't work)
("Current file number we are on" / "total number of files to send") * ("Bytes Sent" / "Total Bytes To Send")
For example I thought I was on the right track when testing with this example: 2/3 (2nd of 3rd file) = 66% (this is right so far) but then when I added * 0.20 (for indicating only 20% of 2nd file has uploaded) we went back to 13%. What I need is only a little over 33%! I did try the inverse at 0.80 and a (2/3 * (2/3 * 0.2))
Can this be done without knowing entire bytes in batch to upload?
Please help! Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您不知道其他排队文件有多大，则无法准确显示与所需时间相关且成比例的百分比值。
我想到了许多解决方法：
一种看似您知道但实际上欺骗用户的方法是假设所有排队的文件与正在进行的文件大小相同，或者处理的文件的平均值相同远的。基于此，如果所有文件的大小确实相同，则进度条将显示“真相”，如果大小差异很大，则进度条将显示“真相”。
另一种方法是让第二个进度条不显示传输的字节百分比，而是显示文件的百分比。因此，如果您有 4 个文件，该栏将从 0 跳到 25%、50%、75% 到 100%。它不会准确地反映所花费的时间，但至少您不会撒谎。
您可以使用 Microsoft 等方法做得更糟：当进度条接近 100% 时，让进度条的增长逐渐变慢，这样它就永远不会真正到达终点。用户看到的只是不断接近“即将完成”的值。这样的显示看起来很酷，但实际上给用户提供的信息最少。
If you don't know how big the other queued files are, then there's no way to accurately display a percentage value that's relevant and proportional to the required time.
A number of workarounds come to mind:
One approach that looks like you know but are in fact deceiving the user would be to assume all the queued files are the same size as the file in progress, or the average of files processed so far. Based on this, the progress bar would be showing "the truth" if all files are indeed the same size, and would be very off if sizes differ significantly.
Another approach would be for your second progress bar to show not the percentage of bytes transferred but the percentage of files. Thus, if you have 4 files, that bar would hop from 0 to 25% to 50% to 75% to 100%. It wouldn't accurately reflect time taken but at least you wouldn't be lying.
You can do even worse with an approach like Microsoft's: Make your progress bar's growth asymptotically slower as it approaches 100%, so that it never actually reaches the end. All the user sees is constantly closer values of "almost finished." Such a display looks cool but is in effect giving the user the least possible information.
正如@Carl 所观察到的，如果不知道还需要发送多少内容，您就无法对已发送的比例进行真实的估计。暂时把科学准确性和完整性放在一边，您的计算：
应该扩展以包含文件分数的想法。比如说，如果您发送了 11 个文件中的 6 个文件，并且发送了第 7 个文件的 30%，那么您需要计算将
发送的文件数乘以当前已发送文件的比例，即计算
0.66*0.2=0.13，而不是添加当前文件的比例。再次拾起科学的准确性和完整性，为什么不使用第二个进度条上的传输速率呢？如果你在一段合理的时间内将其整合起来，它应该会给观察者一种令人满意的感觉，即有些事情正在发生并且正在取得进展。
As @Carl has observed, without knowing how much there is still to send you can't produce a true estimate of the proportion already sent. Putting aside scientific accuracy and integrity for a moment, your calculation:
should be extended to incorporate the idea of fractions of files. If, say, you've sent 6 files out of 11 and 30% of the 7th file, you'd want to calculate
Somewhere along the line you multiplied the number of files sent by the proportion of the current file already sent, ie you calculated
0.66*0.2=0.13, rather than adding the proportion of then current file.Picking up scientific accuracy and integrity again, why not use the rate of transmission on the second progress bar ? If you integrate that over a sensible period it should give the watcher the satisfying sense that something is happening and progress is being made.
天哪，我没有考虑最简单的方法：（
其中processedFileCount始终指示完全传输和完整的文件）
和3个文件批次的证明测试用例：
工作得很好！感谢你们的意见，我会考虑所有外部建议。
Oh my gosh, I didn't consider the simplest approach:
(where processedFileCount always indicates fully transferred and complete files)
and proof test case on 3 file batch:
Works a treat! Thanks for your input though guys I will consider all external advice.