雜記 › 資源分享 › 15 份樂譜 PDF 拖進檔案資訊頁:最大那份 876.8 KB 距換檔還差 150729 位元組,平均大小還要再取整一次

15 份樂譜 PDF 拖進檔案資訊頁:最大那份 876.8 KB 距換檔還差 150729 位元組,平均大小還要再取整一次

15 份公有領域樂譜 PDF 丟進檔案資訊頁,大小欄全落 KB 檔,最大那份距換檔還差 150729 位元組;顯示字串還原回位元組的絕對漂移 350 位元組,平均大小還要再取整一次,導出行序跟的是投遞序。

15 份樂譜 PDF 丟進檔案資訊頁,大小那一欄有意見

起因只是存檔:兩部公有領域樂譜一共 15 份 PDF,想把檔名和大小抄成一張表,就整批丟進了檔案資訊頁。統計條給出 檔案總數:15 / 總大小:5.06 MB / 平均大小:345.4 KB,可下面 15 行的大小欄一格 MB 都沒有,最小那份也沒落進 B 檔——同一屏兩套單位。

受測的是檔案資訊讀取:模板 11104 位元組 / 275 個換行、CRLF 0,script 段 6860 位元組 167 行自第 108 行起,10 個函式原樣進純 Node 探針、toString 回查逐字命中,閾值沒動、Math.round 沒摘。

三閾值兩精度,頂格還不換檔

大小欄只由一個 formatSize(第 162–167 行)決定:閾值 1024 / 1048576 / 1073741824,KB 檔 toFixed(1)、MB 與 GB 檔 toFixed(2),最低的 B 檔在第 163 行原樣拼接、一位小數都不做。

輸入位元組顯示字串口徑
10231023 BB 檔不取整
10241.0 KB換檔留 1 位
10485751024.0 KB頂格不換檔
10485761.00 MB換檔留 2 位
10737418231024.00 MB頂格不換檔
10737418241.00 GB第三檔
1023.91023.9 B小數尾巴照抄

我這 15 份全夾在 1024 與 1048576 之間,整欄走的是 toFixed(1):最小 42286 → 41.3 KB,距下界還有 41262 位元組;最大 897847 → 876.8 KB,距換檔還差 150729 位元組(約 147.2 KB);MB 檔 0 份、B 檔 0 份。文案那句「自動換算KB/MB/GB」在這批只兌現中間一檔,GB 檔從未被觸到,漏掉的恰是最低那檔 B 與兩檔精度。

顯示字串還原回位元組:絕對漂移 350

把顯示字串按檔位乘回去(KB 檔 ×1024)與真實位元組對賬:Σ真實 5305582、Σ還原 5305548.8,淨漂移 -33.2 位元組,逐份絕對漂移之和 350 位元組,最大單份 -48——149552 顯示 146.0 KB、還原 149504。

  • 88176 → 86.1 KB → 88166.4,差 -9.6
  • 814854 → 795.8 KB → 814899.2,差 +45.2
  • 897847 → 876.8 KB → 897843.2,差 -3.8

淨漂移只有 33.2 是靠正負抵消,350 才是這一欄抹掉的量。63004 與 62934 更絕:兩份都寫作 61.5 KB、還原同為 62976,螢幕上分不出來。

跨 4 份樣本的還原賬(全欄 KB 檔) 真實位元組 顯示字串 還原位元組 差額 42286 41.3 KB 42291.2 +5.2 149552 146.0 KB 149504 -48.0 814854 795.8 KB 814899.2 +45.2 897847 876.8 KB 897843.2 -3.8

圖 1:顯示字串到位元組的往返,最壞單份 -48 位元組。

平均大小取整兩次,只有特定樣本才露臉

統計條走第 227–229 行的三步:totalSize 直接累加原始位元組,avgSize = Math.round(totalSize / total),這個整數再進 formatSize——同一次顯示裡兩輪取整。舒伯特 12 份的 totalSize 5141254、真實平均 428437.8333333333,round 成 428438,位移 0.16666666668606922 位元組,顯示 418.4 KB;摘掉 Math.round 仍是 418.4 KB,本批完全看不見第二次取整。

露臉要造樣本:5 份共 5376 位元組、平均 1075.2,頁面寫 1.0 KB,不取整是 1.1 KB,真實只差 0.2、顯示差一整檔小數;4 份共 401 位元組、平均 100.25,B 檔寫 100 B,不取整是 100.25 B。差別在於 B 檔不做 toFixed,而 KB 檔的步長是 0.1 KB = 102.4 位元組,只有真實平均值壓在換串線上時那零點幾位元組才夠推過去。

統計行裡 MB 與 KB 同屏

三行各進各的 formatSize,單位當場分家:舒伯特是 總大小:4.90 MB 配 平均大小:418.4 KB;15 份合投是 5.06 MB 配 345.4 KB;只有舒曼 3 份兩行都在 KB(160.5 KB 配 53.5 KB)。合投的 5305582 正是 5141254 加 164328,與逐份相加閉合——我拖進去的只有 PDF,目錄裡那幾個附屬文字沒進來,所以讀數是淨和;整目錄 5161096 與 172148 一起投的話會寫成 4.92 MB 與 168.1 KB。

固定 totalSize 5141254,只變份數 n 份數 n 平均行 總大小行 單位是否同檔 2 2.45 MB 4.90 MB 同檔 4 1.23 MB 4.90 MB 同檔 5 1004.2 KB 4.90 MB 從這裡開始混檔 12 418.4 KB 4.90 MB 本批真實讀數

圖 2:同一個 5141254,n 從 4 到 5 就把平均行推進另一個單位,總大小行一動不動。

資源頁展示欄位那兩條是「PDF 4.90 MB」與「PDF 0.16 MB」,四捨五入到兩位的展示口徑,不是實測位元組。取舒伯特藝術歌曲那份公有領域樂譜的 12 份淨和實測 5141254,而 4.90 MB 還原 5138022.4,差 -3231.6 位元組、同檔不同字串,對整目錄 5161096 差 -23073.6 位元組;取舒曼童年情景那份公有領域樂譜的 3 份淨和 164328、本頁寫 160.5 KB,0.16 MB 還原 167772.16,差 +3444.16 位元組還跨了檔。

Q:大小欄那一格能反推回原始位元組嗎?

只能反推到顯示精度那層:15 份還原和 5305548.8、真實和 5305582,淨差 -33.2 位元組、單份最大 -48。

Q:為什麼總大小是 MB、平均大小卻是 KB?

兩行各進各的 formatSize,檔位跟著各自的數值走。同一份 totalSize 5141254,份數從 4 加到 5,平均行就從 1.23 MB 掉到 1004.2 KB,總大小行仍在 MB。

Q:平均大小的兩輪取整平時看不出來?

平時看不出來:428437.8333333333 到 428438 的位移夠不著 toFixed(1) 的換串線,摘掉 Math.round 仍是 418.4 KB;1075.2 與 100.25 這兩個構造樣本才把兩輪分開。

Q:排過序再導出,檔案裡也是排過的序?

不是。導出走投遞序,排過序的只是表格那份副本:實測表格首行 01_SchumannOp15No01-a4.pdf、導出首行 01_einsamkeit-a4.pdf。

📎 相關文章

兩部古籍 555733 字節合成一份:面板 2334 行、187299 字,四檔分隔與檔案名標記各加幾格 2026-11-13 兩部公版古籍整本餵進文本讀取頁:唐詩 81474 字節與九章 78497 字節的行數、碼元與碼點差、以及整篇按 GBK 誤讀的替換字元帳 2026-11-12 同一頁裡的三套雜湊實現:兩部公版 TXT 當字節語料,把 file-md5 的分塊賬與編碼變異逐字量一遍 2026-11-09 《聲律啟蒙》《笠翁對韻》整檔餵進文本對比頁:公共 154 行、新增 665 刪除 401,而統計只給兩個數 2026-11-08 《笠翁對韻》量出 21 個轉不出拼音的字:8026 鍵拼音表實測命中 7160、多音 232 次 2026-11-07