某天，我忙中偷閑去Stack Overflow上賺聲望值。
于是，我看到了下面這個問題：怎樣将位元組數輸出成人類可讀的格式？也就是說，怎樣将123,456,789位元組輸出成123.5MB？
隐含的條件是，結果字元串應當在1~999.9的範圍内，後面跟一個适當的表示機關的字尾。
這個問題已經有一個答案了，代碼是用循環寫的。基本思路很簡單：嘗試所有尺度，從最大的EB（10^18位元組）開始直到最小的B（1位元組），然後選擇小于位元組數的第一個尺度。用僞代碼來表示的話大緻如下：
suffixes = [ "EB", "PB", "TB", "GB", "MB", "kB", "B" ]
magnitudes = [ 1018, 1015, 1012, 109, 106, 103, 100 ]
i = 0
while (i < magnitudes.length && magnitudes[i] > byteCount)
i++
printf("%.1f %s", byteCount / magnitudes[i], suffixes[i]) 通常，如果一個問題已經有了正确答案，并且有人贊過，别的回答就很難趕超了。不過這個答案有一些問題，是以我依然有機會超過它。至少，循環還有很大的清理空間。
1、這隻是一個代數問題！
然後我就想到，kB、MB、GB……等字尾隻不過是1000的幂（或者在IEC标準下是1024的幂），也就是說不需要使用循環，完全可以使用對數來計算正确的字尾。
根據這個想法，我寫出了下面的答案：
public static String humanReadableByteCount(long bytes, boolean si) {
int unit = si ? 1000 : 1024;
if (bytes < unit) return bytes + " B";
int exp = (int) (Math.log(bytes) / Math.log(unit));
String pre = (si ? "kMGTPE" : "KMGTPE").charAt(exp-1) + (si ? "" : "i");
return String.format("%.1f %sB", bytes / Math.pow(unit, exp), pre);
} 當然，這段代碼并不是太好了解，而且log和pow的組合的效率也不高。但我沒有使用循環，而且沒有任何分支，看起來很幹淨。
這段代碼的數學原理很簡單。位元組數表示為byteCount = 1000^s，其中s表示尺度。（對于二進制記法則使用1024為底。）求解s可得s = log_1000(byteCount)。
API并沒有提供log_1000，但我們可以用自然對數表示為s = log(byteCount) / log(1000)。然後對s向下取整（強制轉換為int），這樣對于大于1MB但不足1GB的都可以用MB來表示。
此時如果s=1，尺度就是kB，如果s=2，尺度就是MB，以此類推。然後将byteCount除以1000^s，并找出正确的字尾。
接下來，我就等着社群的回報了。我并不知道這段代碼後來成了被複制粘貼最多的代碼。
2、對于貢獻的研究
到了2018年，一位名叫Sebastian Baltes的博士生在《Empirical Software Engineering》雜志上發表了一篇論文，題為《Usage and Attribution of Stack Overflow Code Snippets in GitHub Projects》。
該論文的主旨可以概括成一點：人們是否在遵守Stack Overflow的CC BY-SA 3.0授權？也就是說，當人們從Stack Overflow上複制粘貼時，會怎麼注明來源？
作為分析的一部分，他們從Stack Overflow的資料轉出中提取了代碼片段，并與公開的GitHub代碼庫中的代碼進行比對。論文摘要如是說：
We present results of a large-scale empirical study analyzing the usage and attribution of non-trivial Java code snippets from SO answers in public GitHub (GH) projects.
（本文對于在公開的GitHub項目中使用來自Stack Overflow上有價值的代碼片段的情況以及來源注明情況進行了大規模的經驗分析，并給出了結果。）（劇透：絕大多數人并不會注明來源。）
論文中有這樣一張表格：
id為3758880的答案正是我八年前貼出的答案。此時該答案已經被閱讀了幾十萬次，擁有上千個贊。
在GitHub上随便搜尋一下就能找到數千個humanReadableByteCount函數：
你可以用下面的指令看看自己有沒有無意中用到：
$ git grep humanReadableByteCount 3、問題
你肯定在想：這段代碼有什麼問題：
再來看一次：
public static String humanReadableByteCount(long bytes, boolean si) {
int unit = si ? 1000 : 1024;
if (bytes < unit) return bytes + " B";
int exp = (int) (Math.log(bytes) / Math.log(unit));
String pre = (si ? "kMGTPE" : "KMGTPE").charAt(exp-1) + (si ? "" : "i");
return String.format("%.1f %sB", bytes / Math.pow(unit, exp), pre);
} 在EB（10^18）之後是ZB（10^21）。是不是因為kMGTPE字元串的越界問題？
并不是。long的最大值為2^63-1，大約是9.2x10^18，是以long絕對不會超過EB。
是不是SI和二進制的混合問題？不是。前一個版本的确有這個問題，不過很快就修複了。
是不是因為exp為0會導緻charAt(exp-1)出錯？也不是。第一個if語句已經處理了該情況。exp值至少為1。
是不是一些奇怪的舍入問題？對了……
4、許多9
這段代碼在1MB之前都非常正确。但當輸入為999,999時，它（在SI模式下）會給出“1000.0 kB”。盡管999,999與1,000x1000^1的距離比與999.9x1000^1的距離更小，但根據問題的定義，有效數字部分的1,000是不正确的。正确結果應為"1.0 MB"。
據我所知，原帖下的所有22個答案（包括一個使用Apache Commons和Android庫的答案）都有這個問題（或至少是類似的問題）。
那麼怎樣修複呢？首先，我們注意到指數（exp）應該在位元組數接近1x1,000^2（1MB）時，将傳回結果從k改成M，而不是在位元組數接近999.9x1000^1（999.9k）時。這個點上的位元組數為999,950。類似地，在超過999,950,000時應該從M改成G，以此類推。
為了實作這一點，我們應該計算該門檻值，并當bytes大于門檻值時增加exp的結果。（對于二進制的情況，由于門檻值不再是整數，是以需要使用ceil進行向上取整）。
if (bytes >= Math.ceil(Math.pow(unit, exp) * (unit - 0.05)))exp++; 5、更多的9
但是，當輸入為999,949,999,999,999,999時，結果為1000.0 PB，而正确的結果為999.9 PB。從數學上來看這段代碼是正确的，那麼問題除在何處？
此時我們已經達到了double類型的精度上限。
關于浮點數運算
根據IEEE 754的浮點數表示方法，接近0的數字非常稠密，而很大的數字非常稀疏。實際上，超過一半的值位于-1和1之間，而且像Long.MAX_VALUE如此大的數字對于雙精度來說沒有任何意義。用代碼來表示就是
double a = Double.MAX_VALUE;
double b = a - Long.MAX_VALUE;
System.err.println(a == b); // prints true 有兩個計算是有問題的：
String.format參數中的觸發
對exp的結果加一時的門檻值
當然，改成BigDecimal就行了，但這有什麼意思呢？而且改成BigDecimal代碼也會變得更亂，因為标準API沒有BigDecimal的對數函數。
縮小中間值
對于第一個問題，我們可以将bytes值縮小到精度更好的範圍，并相應地調整exp。由于最終結果總要取整的，是以丢棄最低位有效數字也無所謂。
if (exp > 4) {
bytes /= unit;
exp--;
} 調整最低有效比特
對于第二個問題，我們需要關心最低有效比特（999,949,99...9和999,950,00...0等不同幂次的值），是以需要使用不同的方法解決。
首先注意到，門檻值有12種不同的情況（每個模式下有六種），隻有其中一種有問題。有問題的結果的十六進制表示的末尾為D00。如果出現這種情況，隻需要調整至正确的值即可。
long th = (long) Math.ceil(Math.pow(unit, exp) * (unit - 0.05));
if (exp < 6 && bytes >= th - ((th & 0xFFF) == 0xD00 ? 51 : 0))
exp++; 由于需要依賴于浮點數結果中的特定比特模式，是以需要使用strictfp來保證它在任何硬體上都能運作正确。
6、負輸入
盡管還不清楚什麼情況下會用到負的位元組數，但由于Java并沒有無符号的long，是以最好處理複數。現在，-10,000會産生-10000 B。
引入absBytes變量：
long absBytes = bytes == Long.MIN_VALUE ? Long.MAX_VALUE : Math.abs(bytes); 表達式如此複雜，是因為-Long.MIN_VLAUE == LONG.MIN_VALUE。以後有關exp的計算你都要使用absBytes來代替bytes。
7、最終版本
下面是最終版本的代碼：
// From: https://programming.guide/worlds-most-copied-so-snippet.html
public 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.ceil(Math.pow(unit, exp) * (unit - 0.05));
if (exp < 6 && absBytes >= th - ((th & 0xFFF) == 0xD00 ? 51 : 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);
} 這個答案最初隻是為了避免循環和過多的分支的。諷刺的是，考慮到各種邊界情況後，這段代碼比原答案還難懂了。我肯定不會在産品中使用這段代碼。
總結
Stack Overflow上的代碼就算有幾千個贊也可能有問題。
要測試所有邊界情況，特别是對于從Stack Overflow上複制粘貼的代碼。
浮點數運算很難。
複制代碼時一定要注明來源。别人可以據此提醒你重要的事情。
原文連結：
https://programming.guide/worlds-most-copied-so-snippet.html作者：Andreas Lundblad
譯者：彎月，責編：歐陽姝黎
出品：CSDN（ID：CSDNnews）