复制&； 糊一时爽，频繁出臭虫火葬场。 对开发人员来说，堆栈溢出和GitHub是两个最不为人知的平台，这些平台充满了大量的开源项目信息和解决各种问题的代码片段。 最近，一个叫Aioobe的开发人员在一项调查中发现了自己十年前写的代码。 此代码是堆栈覆盖中复制次数最多、最广泛的答案，也存在于GitHub的许多项目中。 但是，这个开发人员表示这个代码其实有错误，最近更新了回答并进行了说明。
这个代码是什么？
2010年，我想整天沉浸在堆栈溢出中回答问题，提高自己的知名度。 当时，有一个引起我关注的问题。 如何以人类可读的格式输出字节数？ 举个例子，将“123456789字节”转换为“123.5 MB”的格式并输出。
这是现在的截图，但问题确实是这个
这里的隐式范例是得到的字符串值在1到999.9之间，后面跟有适当大小的单位。 那时已经有人回复了。 回答的代码基于循环，基本思路非常简单。 尝试从最大(EB )或1018字节)到最小(b )或1字节)的所有单位，使用的单位数量少于实际字节数。 用伪代码写的话，基本上是这样的意思：
复制代码
suffixes=[ 'EB '、' PB '、' TB '、' GB '、' MB '、' kB '、' b ' ] magnitudes=[ 1018、1015、1012、109、106， 103] 100 ) I=0while (imagnitudes.length magnitudes [ I ] bytecount ) Iprintf('%.1f%s '，bytecount/magnitudes(I () 但是，我觉得这个答案有缺陷，所以打算重新改变。 我意识到，无论是千字节、兆字节还是千兆字节，所有单位的本质实际上都是1000的幂。 当然，IEC标准是1024。 这意味着应该可以使用对数而不是循环来计算精确的订单单位。
基于以上想法，我发表了以下内容：
复制代码
publicstaticstringhumanreadablebytecount (长字节，布尔型si ) { int unit=si？ 1000 : 1024； if (字节单元)返回字节' b )； intexp=(int ) ) math.log(Bytes )/math.log (unit )； stringpre=(si？' kMGTPE' : 'KMGTPE ' ).charat(exp-1 ) ) si？' : 'i '； returnstring.format('%.1f%sb '，bytes/math.pow(unit，exp )，pre )； }当然，这段代码可读性不高，log/pow也可能在一定程度上影响执行效率，但至少这里没有循环，很少涉及到分支，所以我觉得很清晰。
这里使用的数学方法很简单。 字节数由byeCount=1000s表示，其中s表示小数点以下的位数，如果用二进制数表示，则以1024为基数。 解s后，得到s=log1000(bytecount )。
虽然API中没有现成的log1000，但让我们用/log (字节)log1000 )的自然对数表示一下。 接下来，去掉s的底部。 也就是说取整数。 因为得到1 MB以上的结果时，想继续使用MB作为显示单位。
此时，在s=1情况下，单位为KB； s=2时，单位为MB； 同样，将byteCount值除以1000s，得到对应的单位。
接下来，你能做的就是等待社区是否喜欢这个答案。 当时的我绝对没有想到会成为堆栈概述中复制最多的代码片段。
臭虫在哪里？
我想很多人看到这里，都在想这个代码有什么错误。
再看一下代码：
复制代码
publicstaticstringhumanreadablebytecount (长字节，布尔型si ) { int unit=si？ 1000 : 1024； if (字节单元)返回字节' b )； intexp=(int ) ) math.log(Bytes )/math.log (unit )； stringpre=(si？' kMGTPE' : 'KMGTPE ' ).charat(exp-1 ) ) si？' : 'i '； returnstring.format('%.1f%sb '，bytes/Mat
h.pow(unit, exp), pre);}在 EB，即 1018 之后，接下来的单位应该是 ZB，即 1021。难道是输入量过大导致“kMGTPE”字符串的索引超出范围？不是的，long 的最大值是 263-1≈9.2×1018，因此任何 long 值都不会超出 EB 范围。那么，是 SI 与二进制之间存在混杂吗？也不是。答案的早期版本中确实有这个问题，但很快就得到了修复。
那么，是不是 exp 可以为 0 会导致 charAt(exp-1) 发生错误？不是的。第一个 if 语句也涵盖了这种情况，因此 exp 值将始终至少为 1。
那就只剩最后一种情况了，输出结果中是否存在某些奇怪的舍入错误？这正是我们接下来要讨论的部分……
太多个 9
这套解决方案一直运作良好，直到字节数量达到 1 MB。假定输入为 999999 字节，那么结果(在 SI 模式下)将为“1000.0 kB”。尽管 999999 比 999.9 x 10001 更接近于 1000 x 10001，但根据规范，1000 的“有效位数”超出了范围。正确的结果应该是“1.0 MB”。
无论如何，在这个帖子的所有 22 个答案中(包括使用 Apache Commons 以及 Android 库的答案)截至本文撰稿之时都存在这个错误(或者其变体)。那么，我们该如何解决？
首先，我们会注意到，一旦字节数比 999.9 x 10001(999.9 k)更接近于 1 x 10002(1 MB)，则指数(exp)就应由“k”变更为“M”。例如，9999950 就符合这种情况。同样的，当我们输入 999950000 时，我们应该从“M”切换为“G”，依此类推。为了达成这一目标，我们会计算该阈值，一旦字节数超过阈值，则增加 exp：
复制代码
if (bytes >= Math.pow(unit, exp) * (unit - 0.05)) exp++;调整之后，代码即可正常工作，直到字节数接近 1 EB。以输入为 999,949,999,999,999,999 为例，其目前的结果为 1000.0 PB，但正确结果应该是 999.9 PB。但从数学上讲，代码结果又是准确的，这又是怎么回事？这里，我们就遇到了 double(双)精度机制的局限性。
浮点运算基础知识
由于采用 IEEE 754 表示方式，因此近零浮点值会非常密集，但大值则非常稀疏。实际上，所有浮点值中的一半都位于 -1 与 1 之间；而在谈到大双精度浮点数时，像 Long.MAX_VALUE 那么大的值已经没有任何意义了。
复制代码
double l1 = Double.MAX_VALUE;double l2 = l1 - Long.MAX_VALUE;System.err.println(l1 == l2); // prints true下面来看两项有问题的计算：
String.format 参数中的除法；exp 进位阈值我们当然可以切换为 BigDecimal，但这么干就没意思了。另外，由于标准 API 中没有 BigDecimal log 函数，所以问题其实仍然存在。
缩小中间值
对于第一个问题，我们可以将字节值缩小至更合理的精度范围，同时相应调整 exp。无论如何，最终结果都会四舍五入，因此我们要做的就是不要舍弃最低有效数字。
复制代码
if (exp > 4) { bytes /= unit; exp--;}调整最低有效位
对于第二个问题，我们当然关心最低有效位(999、949、99…9 与 999,950,00…0 应该以不同的单位结尾)，因此必须得想个不同的解决方案。
首先，我们注意到阈值存在 12 种不同的可能值(每种模式 6 种)，而且其中只有一种最终会发生故障。通过以 D0016 结尾这一迹象，可以准确识别出错误结果。一旦发生这种情况，我们将其调整为正确值即可。
复制代码
long th = (long) (Math.pow(unit, exp) * (unit - 0.05));if (exp < 6 && bytes >= th - ((th & 0xFFF) == 0xD00 ? 52 : 0)) exp++;由于我们在浮点结果中需要使用特定数位模式，因此下手的对象自然就是 strictfp，旨在保证其不受硬件运行代码的影响。
负输入
目前我还没想到什么情况下有可能需要使用负字节数量，但考虑到 Java 不支持无符号 long，我们最好还是把这个问题考虑进来。现在，如果输入为 -10000，那么结果为 -10000 B。这里我们引入 absBytes:
复制代码
long absBytes = bytes == Long.MIN_VALUE ? Long.MAX_VALUE : Math.abs(bytes);这里的表达之所以如此复杂，是基于 -Long.MIN_VALUE == Long.MIN_VALUE 这一事实。现在，我们利用 absBytes 替代 bytes 执行所有与 exp 相关的计算。
最终版本
以下是代码片段的最终版本，其中已经对最初版本做了精心调整与改进：
复制代码
// 来自: https://programming.guide/the-worlds-most-copied-so-snippet.htmlpublic static strictfp String humanReadableByteCount(long bytes, boolean si) { int unit = si ? 1000 : 1024; long absBytes = bytes == Long.MIN_VALUE ? Long.MAX_VALUE : Math.abs(bytes); if (absBytes < unit) return bytes + " B"; int exp = (int) (Math.log(absBytes) / Math.log(unit)); long th = (long) (Math.pow(unit, exp) * (unit - 0.05)); if (exp < 6 && absBytes >= th - ((th & 0xfff) == 0xd00 ? 52 : 0)) exp++; String pre = (si ? "kMGTPE" : "KMGTPE").charAt(exp - 1) + (si ? "" : "i"); if (exp > 4) { bytes /= unit; exp -= 1; } return String.format("%.1f %sB", bytes / Math.pow(unit, exp), pre);}请注意，这段代码最初的目标是避免由循环以及大量分支带来的复杂性。在解决了所有极端情况之后，新代码的可读性要比原始版本更差。我个人是肯定不会把这段代码复制到生产代码中的。
这段代码被复制到了哪里？
2018 年，一位名叫 Sebastian Baltes 的博士生在《Empirical Software Engineering》上发表了一篇论文，标题为《GitHub 项目中 Stack Overflow 代码片段的用法与归因》，文章探讨的核心议题只有一个：用户对代码片段的引用是否遵循 Stack Overflow 的 CC BY-SA 3.0 许可，即从 Stack Overflow 上复制代码时，用户应保证何等程度的归因水平？
在分析当中，作者从 Stack Overflow 数据转储中提取出代码片段，并将其与公共 GitHub 存储库中的代码进行匹配。下面来看论文的基本发现：
我们进行了一项大规模实证研究，分析了来自各公共 GitHub 项目中的非常规 Java 代码片段，对其中实际上源自 Stack Overflow 的代码片段进行了用法与归因调查。
这篇文章给出了一份表格，而其中 ID 为 3758880 的答案正是我八年前发布的那一条。截至目前，这条答案获得了几十万次查看外加一千多个好评。只要在 GitHub 上随便搜搜，就能找到成千上万条 humanReadableByteCount。
这也就意味着，这段有问题的代码被无数的项目和开发者引用，要验证这段代码是否也在自己的本地存储库内，请执行以下操作：
复制代码
$ git grep humanReadableByteCount心得摘要
最后，我希望告诉广大开发者 Stack Overflow 上的代码片段可能存在 bug，即使得到无数好评也改变不了这一事实；一定要对所有极端情况做出测试，特别是测试那些复制自 Stack Overflow 的代码；浮点运算很复杂，也很困难，在复制代码时，请确保了解代码背后的逻辑和使用规范。