DEV Community: LIN

فایلی که بازیابی کردید ممکن است یک شبح باشد: بررسی سلامت فقط از روی بایت‌ها

LIN — Thu, 08 Oct 2026 01:16:31 +0000

یک ابزار بازیابی را روی یک درایو اجرا می‌کنید. با عددی تمام می‌شود که بوی خبرِ خوب می‌دهد — ۳٬۱۴۸ فایل پیدا شد. بعد شروع می‌کنید به باز کردن‌شان. شاید نصف‌شان کار نکند. بعضی باز می‌شوند و یک مستطیل خاکستری نشان می‌دهند. بعضی را نمایش‌دهنده می‌پذیرد و عکسِ اشتباهی را نشان می‌دهد. بعضی ۴ مگابایت روی دیسک‌اند و اصلاً هیچی درون‌شان نیست.

نرم‌افزار بازیابی به شما دروغ نمی‌گوید. مدخلِ فهرست را پیدا کرده: نام، اندازه، و جایی که فایل قبلاً اشغال می‌کرد. چیزی که نمی‌تواند بداند این است که آیا خوشه‌های پشتِ آن مدخل هنوز همان خوشه‌هایی هستند که به آن تعلق دارند یا نه.

پاک کردنِ یک فایل آن را محو نمی‌کند. در NTFS مدخل علامت می‌خورد و فضا آزاد اعلام می‌شود، و بایت‌ها همان‌جا می‌مانند تا چیزی دیگر روی‌شان نوشته شود. یعنی سه چیزِ مستقل می‌تواند خراب شود، و ابزارهای بازیابی هر سه را با عنوان «پیدا شد» گزارش می‌کنند.

روی داده نوشته شده. نام برگشته؛ محتوا حالا مالِ شخصِ دیگری است.

رویِ بخشی از داده نوشته شده. N خوشهٔ اول برگشته، بقیه رفته. این همان موردِ بدجنس است — فایل اندازه‌ای باورپذیر و سرآیندی درست دارد، و در بعضی نمایش‌دهنده‌ها باز می‌شود در حالی که آشغال رندر می‌کند.

داده اصلاً در فایلی که گرفته‌اید وجود نداشته. ابزار می‌دانسته فایل قرار است ۴ مگابایت باشد، پس ۴ مگابایت برایتان نوشته. دو بایتِ اول و دو بایتِ آخر از قالب می‌آیند؛ هرچه میان‌شان است پُرکننده است.

نمی‌توانید از فایل‌سیستم بپرسید کدام حالت هستید. اما می‌توانید از بایت‌ها بپرسید.

گام ۱: سر و ته

بیشتر قالب‌ها یک امضای ثابت در ابتدا و یک تمام‌کننده در انتها می‌گذارند. اگر هرکدام نباشد، فایل بریده شده.

قالب	باید با این شروع شود	باید با این تمام شود
JPEG	`FF D8 FF`	`FF D9` (EOI)
PNG	`89 50 4E 47 0D 0A 1A 0A`	`IEND` + CRC (`49 45 4E 44 AE 42 60 82`)
PDF	`%PDF-`	`%%EOF` در دو کیلوبایتِ پایانی
DOCX / XLSX / ZIP	`PK`	پایانِ فهرست مرکزی `50 4B 05 06`
MP4 / MOV	یک جعبهٔ `ftyp`	یک نمایهٔ `moov`، در هر کدام از دو سر

به نابرابری توجه کنید، چون اشتباه در این‌جا فایل‌های معتبر را خراب علامت می‌زند. EOIِ یک JPEG خودِ دو بایت آخر است، پس به یک پنجرهٔ ۲ بایتی نگاه می‌کنید. اما EOCD یک ZIP جایی در ۶۴ کیلوبایتِ آخر به علاوهٔ ۲۲ بایت است، چون یک توضیحِ آرشیو می‌تواند بعد از آن بیاید. و %%EOF یک PDF می‌تواند هر جایِ ۲ کیلوبایتِ پایانی باشد — و اگر فایل به‌روزرسانیِ افزایشی شده باشد، می‌تواند بیش از یکی باشد. اگر «چک کردنِ N بایت آخر» را روی همهٔ قالب‌ها ثابت کنید، تمام بعدازظهر هشدارِ اشتباه خواهید گرفت.

و بعد MP4 است، که در آن تمام‌کننده اصلاً در انتها نیست. moov یک جعبهٔ سطح‌بالاست که می‌تواند قبل یا بعدِ mdat بنشیند، پس پنجرهٔ انتها آن را پیدا نمی‌کند. به جایش درختِ جعبه‌ها را قدم می‌زنید — هر جعبه یک اندازهٔ ۴ بایتی است و بعد یک نوعِ ۴ بایتی، پس می‌توانید از یکی به بعدی بپرید:

async function hasMoov(blob) {
  let off = 0;
  for (let i = 0; i < 64; i++) {
    const h = await range(blob, off, 16);
    if (h.length < 8) return false;
    if (String.fromCharCode(h[4], h[5], h[6], h[7]) === 'moov') return true;
    let sz = h[0] * 2 ** 24 + h[1] * 2 ** 16 + h[2] * 256 + h[3];
    if (sz === 1) { sz = 0; for (let k = 8; k < 16; k++) sz = sz * 256 + h[k]; }
    if (sz === 0 || sz < 8) return false;   // 0 means "extends to end of file"
    off += sz;
    if (off >= blob.size) return false;
  }
  return false;
}

سقفِ آن حلقه تزیینی نیست. یک فایلِ بریده اندازهٔ جعبه‌ای به شما می‌دهد که به بعد از انتهایِ داده اشاره می‌کند، و یک قدم‌زدنِ بی‌مرز با خوشحالی تا ابد دنبالش می‌رود.

گام ۲: حفرهٔ میانه

این همان موردی است که هر بررسیِ «آیا معتبر است» را شکست می‌دهد: فایلی با سرآیندِ درست، تمام‌کنندهٔ درست، و هیچ در میانه.

ابزارهای بازیابی به‌طورِ روتین فایل را تا اندازهٔ اعلام‌شده‌اش بازسازی می‌کنند. اگر خوشه‌هایی که میانه را نگه می‌داشته‌اند رفته باشند، ابزار پُر می‌کند. یک JPEG چهار مگابایتی می‌گیرید که دو بایتِ اول و دو بایتِ آخرش کامل است و محتوایش پُرکننده است. بررسی‌ای که فقط به سر و ته نگاه کند، آن را سالم گزارش می‌دهد.

پس از میانه نمونه می‌گیرید. و واضح‌ترین راه انجام این کار — شمردنِ بایت‌های صفر — حفره‌ای در خود دارد که یک کارِ بازیابی از آن رد می‌شود.

هر ابزاری با صفر پُر نمی‌کند. بعضی با 0xFF پُر می‌کنند. بعضی یک الگوی کوتاه را تکرار می‌کنند. اگر آشکارسازِ شما if (zeroRatio > 0.98) باشد، فایلی که با 0xFF پُر شده مستقیم از آن رد می‌شود، و این فایل‌ها کمیاب نیستند.

اصلاح این است که دنبالِ یک مقدارِ خاص نگردید و در عوض دنبالِ نبودِ تنوع بگردید. یک تکهٔ ۸ کیلوبایتی از دادهٔ فشردهٔ واقعی عملاً از همهٔ ۲۵۶ مقدارِ بایت استفاده می‌کند. یک تکهٔ پُرکننده از یکی استفاده می‌کند، شاید چهار تا. این تمایز همهٔ سبک‌های پُر کردن را یک‌جا می‌گیرد:

function analyze(u8) {
  const seen = new Uint8Array(256);
  let zero = 0;
  for (let i = 0; i < u8.length; i++) { const b = u8[i]; if (b === 0) zero++; seen[b] = 1; }
  let distinct = 0;
  for (let i = 0; i < 256; i++) if (seen[i]) distinct++;
  return { zeroRatio: +(zero / u8.length).toFixed(3), distinct };
}

const isHole = (a) => a.zeroRatio > 0.98 || (a.distinct > 0 && a.distinct <= 4);

آزمونِ صفر را هم نگه دارید — جای خودش را دارد، چون تکه‌ای که ۹۹٪ صفر است با چند بایتِ جان‌به‌در‌برده هنوز یک حفره است، و ۹۹٪ صفر به شکل، مثلاً، ۳۰ مقدارِ متمایز ظاهر می‌شود.

گام ۳: نمونه‌گیری متناسب با اندازه

سه نقطه با فاصلهٔ مساوی یک حفرهٔ پیوسته را می‌گیرد، که همان چیزی است که بازنویسی معمولاً تولید می‌کند. اما سه نقطه روی یک ویدیوی ۲ گیگابایتی یک شکافِ ۶ مگابایتی را از دست می‌دهد، و ۶ مگابایت ویدیو کم نیست.

پس تعداد را با اندازه بزرگ کنید و برایش سقف بگذارید، چون کلِ فایدهٔ نمونه‌گیری این است که فایل را نخوانید:

function sampleOffsets(size) {
  if (size < 128 * 1024) return [];
  const n = Math.min(32, Math.max(3, Math.ceil(size / (4 * 1024 * 1024))));
  const step = size / (n + 1);
  const pts = [];
  for (let i = 1; i <= n; i++) pts.push(Math.floor(i * step));
  return pts;
}

فایل‌های کوچک عمداً چیزی برنمی‌گردانند. زیرِ حدود ۱۲۸ کیلوبایت فایل همه‌اش لبه است و میانه ندارد — نمونه‌گیری از آن نویز تولید می‌کند نه سیگنال، و یک JPEG در اندازهٔ تصویرِ بندانگشتی به‌خاطرِ داشتنِ درونِ کسالت‌باری علامت می‌خورد.

جایی که این عمداً می‌ایستد

قالب‌های فشرده‌نشده معاف‌اند. یک BMP مشکیِ واقعی واقعاً و به‌درستی تقریباً همه‌اش صفر است. یک دقیقه سکوتِ دیجیتال در یک WAV هم همین‌طور. اگر آشکارسازِ حفره را روی این‌ها اجرا کنید، فایل‌های کاملاً خوب را محکوم می‌کنید؛ پس اول قالب را چک کنید و وقتی فشرده نیست، نمونه‌گیری را رد کنید. این تنها جایی است که دانستنِ نوع قبل از قضاوت دربارهٔ محتوا اهمیت دارد.

ساختار محتوا نیست. یک JPEG با SOI و EOI و بدون حفره می‌تواند با این حال عکسِ اشتباه را دربر داشته باشد، چون خوشه‌هایی که از آن بازسازی شده متعلق به فایلِ دیگری بوده که اتفاقاً نزدیک آن قرار داشته. هیچ بررسیِ سطح‌بایتی نمی‌تواند این را تشخیص دهد. فقط یک انسان که آن را باز کند می‌تواند.

خراب به‌معنای بی‌ارزش نیست. فایلی که ما ناقص می‌نامیم هنوزهر کسری که جان به‌در برده را دارد. بازیابیِ عکس به‌طورِ خاص: یک JPEG که ته‌اش را ندارد اغلب با این حال بیشترِ تصویر را رندر می‌کند، و اگر تنها نسخهٔ یک عکس باشد، «بیشترِ تصویر» نتیجهٔ بسیار خوبی است. نگذارید یک ابزارِ بررسی شما را قانع کند چیزی را پاک کنید.

و یک نکتهٔ فایل‌سیستمی، چون احتمال‌هایتان را قبل از شروع تغییر می‌دهد: ext4 اشاره‌گرهای بلوک را هنگامِ پاک کردن خالی می‌کند، در حالی که NTFS بیشتر وقت‌ها آن‌ها را باقی می‌گذارد. نامِ فایل‌ها روی ext4 معمولاً یکسره از دست می‌رود، و این دلیلی است که بازیابی در لینوکس حتی وقتی خودِ داده جان به‌در برده سخت‌تر از بازیابی در ویندوز است. اگر روی یک درایوِ ext4 کار می‌کنید، از یک USB زنده انجامش دهید — هرگز از سیستمِ نصب‌شده، که دارد روی همان دیسکی می‌نویسد که می‌خواهید نجاتش دهید.

کلِ چیز، آمادهٔ پیست کردن

سرهم‌شده. یک File (یا Blob) می‌گیرد، فقط پنجره‌هایی را که لازم دارد از طریق Blob.slice() می‌خواند — که تنبل است، پس تا وقتی بایت‌ها را نخواهید چیزی خوانده نمی‌شود — و یک حکم همراه با شواهدِ پشتش برمی‌گرداند.

آن را در کنسولِ DevTools پیست کنید، بعد یا روی یک دسته‌فایل که دارید صدایش بزنید، یا یک هدفِ دراگ‌اند‌دراپ بسازید و یک پوشه را در آن بکشید:

document.addEventListener('dragover', (e) => e.preventDefault());
document.addEventListener('drop', async (e) => {
  e.preventDefault();
  console.table(await ghostCheck.bulk(e.dataTransfer.files));
});

const ghostCheck = (() => {
  const KB = 1024, MB = 1024 * 1024;
  const CHUNK = 8 * KB;
  const MIN_SAMPLABLE = 128 * KB;

  // Blob.slice() is lazy: nothing is read until you ask for the bytes.
  async function range(blob, start, len) {
    const s = Math.max(0, Math.round(start));
    const e = Math.min(blob.size, s + len);
    if (e <= s) return new Uint8Array(0);
    return new Uint8Array(await blob.slice(s, e).arrayBuffer());
  }

  function startsWith(u8, sig) {
    if (u8.length < sig.length) return false;
    for (let i = 0; i < sig.length; i++) if (u8[i] !== sig[i]) return false;
    return true;
  }

  function indexOf(u8, sig) {
    outer: for (let i = 0; i + sig.length <= u8.length; i++) {
      for (let j = 0; j < sig.length; j++) if (u8[i + j] !== sig[j]) continue outer;
      return i;
    }
    return -1;
  }

  const ascii = (s) => [...s].map((c) => c.charCodeAt(0));

  function analyze(u8) {
    const seen = new Uint8Array(256);
    let zero = 0;
    for (let i = 0; i < u8.length; i++) { const b = u8[i]; if (b === 0) zero++; seen[b] = 1; }
    let distinct = 0;
    for (let i = 0; i < 256; i++) if (seen[i]) distinct++;
    return { zeroRatio: +(zero / u8.length).toFixed(3), distinct };
  }

  // A hole is not always zeros. Recovery tools pad with 0x00, sometimes 0xFF,
  // sometimes a short repeating pattern. Both look the same from here:
  // a chunk of real compressed data uses ~256 distinct byte values; padding uses ~1.
  const isHole = (a) => a.zeroRatio > 0.98 || (a.distinct > 0 && a.distinct <= 4);

  function sampleOffsets(size) {
    if (size < MIN_SAMPLABLE) return [];
    const n = Math.min(32, Math.max(3, Math.ceil(size / (4 * MB))));
    const step = size / (n + 1);
    const pts = [];
    for (let i = 1; i <= n; i++) pts.push(Math.floor(i * step));
    return pts;
  }

  const FORMATS = [
    { id: 'jpeg', label: 'JPEG', head: [0xff, 0xd8, 0xff], tail: [0xff, 0xd9], tailWindow: 2, compressed: true },
    { id: 'png', label: 'PNG', head: [0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a], tail: [0x49, 0x45, 0x4e, 0x44, 0xae, 0x42, 0x60, 0x82], tailWindow: 16, compressed: true },
    { id: 'zip', label: 'ZIP / Office', head: [0x50, 0x4b], tail: [0x50, 0x4b, 0x05, 0x06], tailWindow: 65557, compressed: true },
    { id: 'pdf', label: 'PDF', head: ascii('%PDF-'), tailText: '%%EOF', tailWindow: 2048, compressed: true },
    { id: 'bmp', label: 'BMP', head: ascii('BM'), compressed: false },
    { id: 'wav', label: 'WAV', head: ascii('RIFF'), compressed: false },
  ];
  const FTYP = ascii('ftyp');

  // Walk top-level ISO-BMFF boxes looking for `moov`. Capped: a truncated file
  // can point the offset past the end, and stopping beats looping.
  async function hasMoov(blob) {
    let off = 0;
    for (let i = 0; i < 64; i++) {
      const h = await range(blob, off, 16);
      if (h.length < 8) return false;
      if (String.fromCharCode(h[4], h[5], h[6], h[7]) === 'moov') return true;
      let sz = h[0] * 2 ** 24 + h[1] * 2 ** 16 + h[2] * 256 + h[3];
      if (sz === 1) { // 64-bit extended size
        sz = 0;
        for (let k = 8; k < 16; k++) sz = sz * 256 + h[k];
      }
      if (sz === 0 || sz < 8) return false;   // 0 means "to end of file"
      off += sz;
      if (off >= blob.size) return false;
    }
    return false;
  }

  async function check(blob) {
    const size = blob.size;
    let bytesRead = 0;

    const headBytes = await range(blob, 0, 16); bytesRead += headBytes.length;
    const fmt = FORMATS.find((f) => startsWith(headBytes, f.head)) || null;
    let type = fmt ? fmt.label : 'unknown';
    const compressed = fmt ? fmt.compressed : true;
    if (!fmt && startsWith(headBytes.subarray(4, 8), FTYP)) type = 'MP4 / MOV';

    let tail = null;   // null = this format has no terminator worth checking
    if (type === 'MP4 / MOV') {
      tail = await hasMoov(blob);
    } else if (fmt && (fmt.tail || fmt.tailText)) {
      const sig = fmt.tail || ascii(fmt.tailText);
      const win = await range(blob, size - fmt.tailWindow, fmt.tailWindow);
      bytesRead += win.length;
      tail = indexOf(win, sig) >= 0;
    }

    const holes = [];
    let minDistinct = null;
    if (compressed) {
      for (const at of sampleOffsets(size)) {
        const c = await range(blob, at, CHUNK); bytesRead += c.length;
        if (c.length < 512) continue;
        const a = analyze(c);
        if (minDistinct === null || a.distinct < minDistinct) minDistinct = a.distinct;
        if (isHole(a)) holes.push({ at, ...a });
      }
    }

    const cut = tail === false;
    const holey = holes.length > 0;
    let verdict;
    if (type === 'unknown') verdict = 'UNRECOGNISED';
    else if (!cut && !holey) verdict = tail === null ? 'PLAUSIBLE (no terminator)' : 'INTACT';
    else if (!cut && holey) verdict = 'GHOST';
    else if (cut && holey) verdict = 'GHOST + PARTIAL';
    else verdict = 'PARTIAL';

    return {
      type, size, tail: tail === null ? '—' : tail, holes: holes.length,
      minDistinct: minDistinct === null ? '—' : minDistinct,
      kbRead: +(bytesRead / 1024).toFixed(2), verdict,
    };
  }

  check.bulk = async (files) => Promise.all(
    [...files].map(async (f) => ({ file: f.name, ...(await check(f)) }))
  );

  return check;
})();

در برابر فایل‌های مصنوعی — یک JPEG کامل، یکی که قبل از EOI بریده شده، یک PNG کامل، یک DOCX بدون EOCD، یک JPEG با یک حفره، یک JPEG پُرشده، همان پُرشده با 0xFF به جای صفر، یک BMP مشکیِ مشروع، یک MP4 کامل و یکی بریده، و یک تصویرِ بندانگشتی ۴۰ کیلوبایتی:

┌─────────┬──────────────────────┬────────────────┬───────┬───────┬─────────────┬────────┬─────────────────────────────┐
│ (index) │ file                 │ type           │ tail  │ holes │ minDistinct │ kbRead │ verdict                     │
├─────────┼──────────────────────┼────────────────┼───────┼───────┼─────────────┼────────┼─────────────────────────────┤
│ 0       │ 'photo-complete.jpg' │ 'JPEG'         │ true  │ 0     │ 256         │ 24.02  │ 'INTACT'                    │
│ 1       │ 'photo-cut.jpg'      │ 'JPEG'         │ false │ 0     │ 256         │ 24.02  │ 'PARTIAL'                   │
│ 2       │ 'scan.png'           │ 'PNG'          │ true  │ 0     │ 256         │ 24.03  │ 'INTACT'                    │
│ 3       │ 'report.docx'        │ 'ZIP / Office' │ false │ 0     │ 256         │ 88.04  │ 'PARTIAL'                   │
│ 4       │ 'photo-hole.jpg'     │ 'JPEG'         │ true  │ 2     │ 1           │ 24.02  │ 'GHOST'                     │
│ 5       │ 'photo-ghost.jpg'    │ 'JPEG'         │ true  │ 3     │ 1           │ 24.02  │ 'GHOST'                     │
│ 6       │ 'photo-ghost-ff.jpg' │ 'JPEG'         │ true  │ 3     │ 1           │ 24.02  │ 'GHOST'                     │
│ 7       │ 'black.bmp'          │ 'BMP'          │ '—'   │ 0     │ '—'         │ 0.02   │ 'PLAUSIBLE (no terminator)' │
│ 8       │ 'clip.mp4'           │ 'MP4 / MOV'    │ true  │ 0     │ 256         │ 24.02  │ 'INTACT'                    │
│ 9       │ 'clip-truncated.mp4' │ 'MP4 / MOV'    │ false │ 0     │ 256         │ 24.02  │ 'PARTIAL'                   │
│ 10      │ 'thumb-small.jpg'    │ 'JPEG'         │ true  │ 0     │ '—'         │ 0.02   │ 'INTACT'                    │
└─────────┴──────────────────────┴────────────────┴───────┴───────┴─────────────┴────────┴─────────────────────────────┘

سه ردیف در آن‌اند که ارزشِ این زحمت را دارند.

ردیف ۶ همان فایلِ پُرشده با 0xFF است. سر سالم، ته سالم، و حتی یک بایتِ صفر در آن نیست. آشکارسازی که صفرها را می‌شمارد آن را کاملاً تمیز نمره می‌دهد.

ردیف ۷ یک BMP مشکیِ واقعی است، معاف از آشکارسازیِ حفره چون فشرده نشده. تقریباً یکسره صفر است و فایلِ کاملاً خوبی است.

ردیف ۳ برای قضاوت دربارهٔ یک فایلِ ۵۰۰ کیلوبایتی ۸۸ کیلوبایت هزینه برداشت، چون پایانِ فهرست مرکزیِ ZIP می‌تواند در هر جای ۶۴ کیلوبایتِ آخر پنهان شود. این بهایِ پنجره‌هایِ جداگانه برای هر قالب است — و با این حال یک‌پنجمِ فایل است، نه کلِ آن.

نکته‌های عملی

این را قبل از باز کردنِ فایل‌های بازیابی‌شده اجرا کنید، نه بعد. باز کردنِ یک فایلِ خراب معمولاً بی‌ضرر است، اما باز کردنش با برنامه‌ای که می‌نویسد — یک ویرایشگرِ عکس که تصویرِ بندانگشتی می‌سازد، یک پایگاه داده که فایلِ قفل می‌سازد — روی همان درایوی می‌نویسد که دارید از آن بازیابی می‌کنید.

اندازه‌ای که ابزارِ بازیابی گزارش داده را با اندازه‌ای که واقعاً گرفته‌اید مقایسه کنید. اگر ابزار گفته ۴ مگابایت و فایل روی دیسک ۹۰۰ کیلوبایت است، به هیچ‌کدام از بالا نیاز ندارید.

قبل از هر چیزِ دیگری بر اساسِ حکم مرتب کنید، و سالم‌ها را اول کپی کنید. روی درایوی که واقعاً در حالِ خراب شدن است، ترتیبی که کار می‌کنید از ابزاری که انتخاب کرده‌اید باارزش‌تر است.

این چطور نوشته شد

افشا، اول از همه: پیش‌نویسِ این پست را یک عاملِ هوش مصنوعی از مسئله‌ای که خودم انتخاب کردم نوشت، با یک دستورِ همیشگی — هیچ ادعایی نوشته نمی‌شود مگر اینکه اجرا شده باشد. یازده موردِ آزمایشی در جدولِ بالا به‌شکل آرایهٔ بایت ساخته شدند، از تابع رد شدند، و خروجی‌شان اینجا پیست شده. هیچ‌کدام تزیینی نیست.

می‌گویم این چه چیزی خرید، چون این تنها بخشِ این فرایند است که ارزشِ خواندن دارد.

نقشهٔ اصلی این بود که فایلِ میان‌تهی را به روشِ واضح تشخیص دهم: بایت‌های صفرِ میانه را بشمار و آن را خالی بنام. بعد یک JPEG جعلی ساختم که با 0xFF به جای 0x00 پُر شده بود — سر سالم، ته سالم، دو مگابایت هیچ، و حتی یک بایت صفر در هیچ کجایش. بررسیِ ساده‌لوحانه آن را فایلی سالم گزارش داد. و هر تکه‌کدِ «فایل‌های بازیابی‌شده‌ات را بررسی کن» که پیدا کردم هم همین‌طور، چون همه‌شان یک سؤال می‌پرسند و آن سؤال اشتباه است.

این بود که قانونِ واقعیِ این پست را تولید کرد: بپرس آیا یک تکه از فایل تنوع دارد، نه اینکه صفر دارد. دادهٔ فشردهٔ واقعی در یک نمونهٔ ۸ کیلوبایتی به همهٔ ۲۵۶ مقدارِ بایت دست می‌زند. پُرکننده به یکی دست می‌زند. سؤالِ بازنویسی‌شده پُر کردن با صفر، پُر کردن با 0xFF و الگوهای کوتاهِ تکراری را با همان سه خط کد می‌گیرد.

که نسخه‌ای مشخص و کوچک از یک چیزِ کلی است: آزمون‌ها از نوشتن باارزش‌تر بودند. یک مدل در همان چند ثانیه دربارهٔ هر کدام از دو رویکرد یک پاراگرافِ مطمئن می‌نویسد. فقط اجرا است که می‌گوید کدام اشتباه است.

الملف الذي استعدته قد يكون شبحاً: التحقق من السلامة من البايتات وحدها

LIN — Thu, 08 Oct 2026 01:16:24 +0000

تُشغّل أداة استعادة على قرص، فتنتهي برقم يبدو خبراً جيداً — تم العثور على 3,148 ملفاً. ثم تبدأ بفتحها. نصفها تقريباً لا يعمل. بعضها يُفتح ويعرض مستطيلاً رمادياً. وبعضها يقبله العارض ويعرض الصورة الخطأ. وبعضها حجمه 4 ميغابايت على القرص ولا يحتوي شيئاً على الإطلاق.

برنامج الاستعادة لا يكذب عليك. لقد وجد مدخل الدليل: الاسم، والحجم، والموقع الذي كان الملف يشغله. وما لا يستطيع معرفته هو ما إذا كانت العناقيد خلف ذلك المدخل لا تزال العناقيد التي تخصّه.

حذف ملف لا يمحوه. في NTFS يُعلَّم المدخل وتُعلَّم المساحة متاحة، وتظل البايتات مكانها حتى يكتب شيء آخر فوقها. وهذا يعني أن هناك ثلاثة أشياء مستقلة يمكن أن تسوء، وأدوات الاستعادة تُبلّغ عنها كلها بوصفها «تم العثور عليها».

الكُتبت البيانات فوقها. الاسم عاد؛ أمّا المحتويات فصارت لشخص آخر.

الكُتبت البيانات فوقها جزئياً. عادت العناقيد الأولى، والباقي ذهب. هذه هي الحالة الخبيثة — للملف حجم معقول وترويسة صحيحة، ويُفتح في بعض العارضات وهو يعرض خردة.

البيانات لم تكن موجودة أصلاً في الملف الذي حصلت عليه. الأداة عرفت أن الملف يُفترض أن يكون 4 ميغابايت، فكتبت لك 4 ميغابايت. البايتان الأولان والأخيران من الصيغة، وكل ما بينهما حشو.

لا يمكنك أن تسأل نظام الملفات عن الحالة التي أنت فيها. لكن يمكنك أن تسأل البايتات.

الخطوة 1: البداية والنهاية

معظم الصيغ تضع بصمة ثابتة في البداية وعلامة نهاية في الآخر. إن غاب أيّهما فالملف مقطوع.

الصيغة	يجب أن تبدأ بـ	يجب أن تنتهي بـ
JPEG	`FF D8 FF`	`FF D9` (EOI)
PNG	`89 50 4E 47 0D 0A 1A 0A`	`IEND` + CRC (`49 45 4E 44 AE 42 60 82`)
PDF	`%PDF-`	`%%EOF` في آخر كيلوبايتين تقريباً
DOCX / XLSX / ZIP	`PK`	نهاية الدليل المركزي `50 4B 05 06`
MP4 / MOV	صندوق `ftyp`	فهرس `moov`، في أيّ من الطرفين

لاحظ التفاوت، لأن الخطأ هنا يصنّف ملفات صالحة على أنها تالفة. علامة EOI في JPEG هي آخر بايتين، فتنظر في نافذة من 2 بايت. أمّا EOCD في ZIP فمكانه في مكان ما ضمن آخر 64 كيلوبايت + 22 بايت، لأن تعليق الأرشيف يمكن أن يليه. و%%EOF في PDF يمكن أن يكون في أي مكان في آخر 2 كيلوبايت — وقد يكون هناك أكثر من واحد إن كان الملف قد حُدِّث تراكمياً. إن ثبّتّ «تحقق من آخر N بايت» على كل الصيغ، فستحصل على إنذارات كاذبة طوال بعد الظهر.

ثم هناك MP4، حيث علامة النهاية ليست في النهاية أصلاً. moov صندوق من المستوى الأعلى يمكن أن يقع قبل mdat أو بعده، فنافذة النهاية لن تجده. تمشي في شجرة الصناديق بدلاً من ذلك — كل صندوق حجمه 4 بايت يليه نوعه من 4 بايت، فتقفز من واحد إلى التالي:

async function hasMoov(blob) {
  let off = 0;
  for (let i = 0; i < 64; i++) {
    const h = await range(blob, off, 16);
    if (h.length < 8) return false;
    if (String.fromCharCode(h[4], h[5], h[6], h[7]) === 'moov') return true;
    let sz = h[0] * 2 ** 24 + h[1] * 2 ** 16 + h[2] * 256 + h[3];
    if (sz === 1) { sz = 0; for (let k = 8; k < 16; k++) sz = sz * 256 + h[k]; }
    if (sz === 0 || sz < 8) return false;   // 0 means "extends to end of file"
    off += sz;
    if (off >= blob.size) return false;
  }
  return false;
}

الحدّ الأعلى لتلك الحلقة ليس زينة. الملف المبتور يعطيك حجم صندوق يشير إلى ما بعد نهاية البيانات، ومسيرة بلا حدّ ستلاحقه بسعادة إلى الأبد.

الخطوة 2: الفجوة في المنتصف

إليك الحالة التي تُسقط كل فحص من نوع «هل هو صالح»: ملف بترويسة صحيحة وعلامة نهاية صحيحة ولا شيء بينهما.

أدوات الاستعادة تُعيد بناء ملف إلى حجمه المُعلن بشكل روتيني. إن كانت العناقيد التي حملت المنتصف قد ذهبت، تملؤها الأداة فراغاً. تحصل على JPEG بحجم 4 ميغابايت أول بايتين وآخر بايتين فيه مثاليّان ومحتواه حشو. فحص ينظر إلى البداية والنهاية فقط سيُبلّغ عنه بأنه سليم.

لذلك تأخذ عيّنة من المنتصف. والطريقة الواضحة لفعل ذلك — عدّ الأصفار — فيها ثغرة تكفي لمرور مهمة استعادة بأكملها.

ليست كل أداة تملأ الفراغ بصفر. بعضها يملأ بـ 0xFF. وبعضها يُكرّر نمطاً قصيراً. إن كان كاشفك if (zeroRatio > 0.98) فملف محشوّ بـ 0xFF يمرّ من خلاله مباشرة، وهذه الملفات ليست نادرة.

الإصلاح أن تتوقف عن البحث عن قيمة محددة وتبحث عن غياب التنوّع بدلاً من ذلك. قطعة من بيانات مضغوطة حقيقية بحجم 8 كيلوبايت تستخدم كل قيم البايت الـ 256 عملياً. قطعة حشو تستخدم قيمة واحدة، أو أربعاً على الأكثر. وهذا التمييز يمسك كل أنماط الحشو دفعة واحدة:

function analyze(u8) {
  const seen = new Uint8Array(256);
  let zero = 0;
  for (let i = 0; i < u8.length; i++) { const b = u8[i]; if (b === 0) zero++; seen[b] = 1; }
  let distinct = 0;
  for (let i = 0; i < 256; i++) if (seen[i]) distinct++;
  return { zeroRatio: +(zero / u8.length).toFixed(3), distinct };
}

const isHole = (a) => a.zeroRatio > 0.98 || (a.distinct > 0 && a.distinct <= 4);

أبقِ فحص الأصفار أيضاً — فهو يستحق مكانه، لأن قطعة 99% منها أصفار مع بضع بايتات ناجية لا تزال فجوة، و99% أصفار ستظهر بوصفها، مثلاً، 30 قيمة متمايزة.

الخطوة 3: عيّنات بالنسبة للحجم

ثلاث نقاط متباعدة بالتساوي تمسك فجوة متّصلة، وهو ما تُنتجه الكتابة فوقها عادةً. لكن ثلاث نقاط على فيديو بحجم 2 غيغابايت ستفوتها فجوة 6 ميغابايت، و6 ميغابايت فيديو كثير.

لذلك كبّر العدد مع الحجم وضع له حدّاً، لأن كل فكرة أخذ العيّنات هي ألا تقرأ الملف:

function sampleOffsets(size) {
  if (size < 128 * 1024) return [];
  const n = Math.min(32, Math.max(3, Math.ceil(size / (4 * 1024 * 1024))));
  const step = size / (n + 1);
  const pts = [];
  for (let i = 1; i <= n; i++) pts.push(Math.floor(i * step));
  return pts;
}

الملفات الصغيرة تُعيد لا شيء عن قصد. تحت 128 كيلوبايت تقريباً يكون الملف كله حوافّ بلا منتصف — أخذ عيّنة منه يُنتج ضجيجاً لا إشارة، وJPEG بحجم صورة مصغّرة سيُصنَّف مريباً لأن داخله مملّ.

حيث يتوقف هذا عمْداً

الصيغ غير المضغوطة مستثناة. صورة BMP سوداء حقيقية هي بالفعل وبشكل صحيح كلها أصفار تقريباً. وكذلك دقيقة من الصمت الرقمي في WAV. إن أدخلت كاشف فجوات على تلك فستدين ملفات جيدة تماماً، فتحقّق من الصيغة أولاً وتجاوز أخذ العيّنات حين لا تكون مضغوطة. هذا هو الموضع الوحيد الذي تكون فيه معرفة النوع قبل الحكم على المحتويات مهمة.

البنية ليست المحتوى. JPEG فيه SOI وEOI وبلا فجوات يمكن أن يحتوي مع ذلك الصورة الخطأ، لأن العناقيد التي أُعيد بناؤه منها كانت تعود لملف آخر صادف أنه كان قريباً. ولا فحص على مستوى البايت يمكنه اكتشاف ذلك. وحده إنسان يفتحه يستطيع.

التالف لا يعني عديم القيمة. الملف الذي نسمّيه ناقصاً لا يزال يحمل الكسر الذي نجا. استعادة الصور تحديداً: JPEG تنقصه نهايته غالباً ما يعرض معظم الصورة مع ذلك، وإن كانت النسخة الوحيدة من صورة فوتوغرافية، ف«معظم الصورة» نتيجة جيدة جداً. لا تدع أداة فحص تُقنعك بحذف أي شيء.

وملاحظة واحدة عن نظام الملفات، لأنها تغيّر احتمالاتك قبل أن تبدأ: ext4 يُفرغ مؤشرات الكتل عند الحذف، بينما NTFS يتركها في الغالب. وأسماء الملفات على ext4 تُفقد عادةً بالكامل، وهذا سبب أن الاستعادة على لينكس أصعب من الاستعادة على ويندوز حتى حين تنجو البيانات نفسها. وإن كنت تعمل على وحدة ext4، فافعل ذلك من USB حيّ — لا من النظام المُثبَّت أبداً، فهو يكتب على القرص نفسه الذي تحاول إنقاذه.

الكود كاملاً، جاهزاً للصق

مجمّعاً. يأخذ File (أو Blob)، ويقرأ النوافذ التي يحتاجها فقط عبر Blob.slice() — وهو كسول، فلا يُقرأ شيء حتى تطلب البايتات — ويُعيد حُكماً مع الأدلّة التي تقف خلفه.

الصقه في طرفية DevTools، ثم إمّا أن تستدعيه على مقبض ملف لديك، أو تجهّز هدف إفلات وتسحب مجلداً إليه:

document.addEventListener('dragover', (e) => e.preventDefault());
document.addEventListener('drop', async (e) => {
  e.preventDefault();
  console.table(await ghostCheck.bulk(e.dataTransfer.files));
});

const ghostCheck = (() => {
  const KB = 1024, MB = 1024 * 1024;
  const CHUNK = 8 * KB;
  const MIN_SAMPLABLE = 128 * KB;

  // Blob.slice() is lazy: nothing is read until you ask for the bytes.
  async function range(blob, start, len) {
    const s = Math.max(0, Math.round(start));
    const e = Math.min(blob.size, s + len);
    if (e <= s) return new Uint8Array(0);
    return new Uint8Array(await blob.slice(s, e).arrayBuffer());
  }

  function startsWith(u8, sig) {
    if (u8.length < sig.length) return false;
    for (let i = 0; i < sig.length; i++) if (u8[i] !== sig[i]) return false;
    return true;
  }

  function indexOf(u8, sig) {
    outer: for (let i = 0; i + sig.length <= u8.length; i++) {
      for (let j = 0; j < sig.length; j++) if (u8[i + j] !== sig[j]) continue outer;
      return i;
    }
    return -1;
  }

  const ascii = (s) => [...s].map((c) => c.charCodeAt(0));

  function analyze(u8) {
    const seen = new Uint8Array(256);
    let zero = 0;
    for (let i = 0; i < u8.length; i++) { const b = u8[i]; if (b === 0) zero++; seen[b] = 1; }
    let distinct = 0;
    for (let i = 0; i < 256; i++) if (seen[i]) distinct++;
    return { zeroRatio: +(zero / u8.length).toFixed(3), distinct };
  }

  // A hole is not always zeros. Recovery tools pad with 0x00, sometimes 0xFF,
  // sometimes a short repeating pattern. Both look the same from here:
  // a chunk of real compressed data uses ~256 distinct byte values; padding uses ~1.
  const isHole = (a) => a.zeroRatio > 0.98 || (a.distinct > 0 && a.distinct <= 4);

  function sampleOffsets(size) {
    if (size < MIN_SAMPLABLE) return [];
    const n = Math.min(32, Math.max(3, Math.ceil(size / (4 * MB))));
    const step = size / (n + 1);
    const pts = [];
    for (let i = 1; i <= n; i++) pts.push(Math.floor(i * step));
    return pts;
  }

  const FORMATS = [
    { id: 'jpeg', label: 'JPEG', head: [0xff, 0xd8, 0xff], tail: [0xff, 0xd9], tailWindow: 2, compressed: true },
    { id: 'png', label: 'PNG', head: [0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a], tail: [0x49, 0x45, 0x4e, 0x44, 0xae, 0x42, 0x60, 0x82], tailWindow: 16, compressed: true },
    { id: 'zip', label: 'ZIP / Office', head: [0x50, 0x4b], tail: [0x50, 0x4b, 0x05, 0x06], tailWindow: 65557, compressed: true },
    { id: 'pdf', label: 'PDF', head: ascii('%PDF-'), tailText: '%%EOF', tailWindow: 2048, compressed: true },
    { id: 'bmp', label: 'BMP', head: ascii('BM'), compressed: false },
    { id: 'wav', label: 'WAV', head: ascii('RIFF'), compressed: false },
  ];
  const FTYP = ascii('ftyp');

  // Walk top-level ISO-BMFF boxes looking for `moov`. Capped: a truncated file
  // can point the offset past the end, and stopping beats looping.
  async function hasMoov(blob) {
    let off = 0;
    for (let i = 0; i < 64; i++) {
      const h = await range(blob, off, 16);
      if (h.length < 8) return false;
      if (String.fromCharCode(h[4], h[5], h[6], h[7]) === 'moov') return true;
      let sz = h[0] * 2 ** 24 + h[1] * 2 ** 16 + h[2] * 256 + h[3];
      if (sz === 1) { // 64-bit extended size
        sz = 0;
        for (let k = 8; k < 16; k++) sz = sz * 256 + h[k];
      }
      if (sz === 0 || sz < 8) return false;   // 0 means "to end of file"
      off += sz;
      if (off >= blob.size) return false;
    }
    return false;
  }

  async function check(blob) {
    const size = blob.size;
    let bytesRead = 0;

    const headBytes = await range(blob, 0, 16); bytesRead += headBytes.length;
    const fmt = FORMATS.find((f) => startsWith(headBytes, f.head)) || null;
    let type = fmt ? fmt.label : 'unknown';
    const compressed = fmt ? fmt.compressed : true;
    if (!fmt && startsWith(headBytes.subarray(4, 8), FTYP)) type = 'MP4 / MOV';

    let tail = null;   // null = this format has no terminator worth checking
    if (type === 'MP4 / MOV') {
      tail = await hasMoov(blob);
    } else if (fmt && (fmt.tail || fmt.tailText)) {
      const sig = fmt.tail || ascii(fmt.tailText);
      const win = await range(blob, size - fmt.tailWindow, fmt.tailWindow);
      bytesRead += win.length;
      tail = indexOf(win, sig) >= 0;
    }

    const holes = [];
    let minDistinct = null;
    if (compressed) {
      for (const at of sampleOffsets(size)) {
        const c = await range(blob, at, CHUNK); bytesRead += c.length;
        if (c.length < 512) continue;
        const a = analyze(c);
        if (minDistinct === null || a.distinct < minDistinct) minDistinct = a.distinct;
        if (isHole(a)) holes.push({ at, ...a });
      }
    }

    const cut = tail === false;
    const holey = holes.length > 0;
    let verdict;
    if (type === 'unknown') verdict = 'UNRECOGNISED';
    else if (!cut && !holey) verdict = tail === null ? 'PLAUSIBLE (no terminator)' : 'INTACT';
    else if (!cut && holey) verdict = 'GHOST';
    else if (cut && holey) verdict = 'GHOST + PARTIAL';
    else verdict = 'PARTIAL';

    return {
      type, size, tail: tail === null ? '—' : tail, holes: holes.length,
      minDistinct: minDistinct === null ? '—' : minDistinct,
      kbRead: +(bytesRead / 1024).toFixed(2), verdict,
    };
  }

  check.bulk = async (files) => Promise.all(
    [...files].map(async (f) => ({ file: f.name, ...(await check(f)) }))
  );

  return check;
})();

مقابل ملفات مُصنَّعة — JPEG كامل، وآخر مقطوع قبل EOI، وPNG كامل، وDOCX بلا EOCD، وJPEG فيه فجوة واحدة، وJPEG محشوّ، ونفسه محشوّاً بـ 0xFF بدل الصفر، وBMP أسود مشروع، وMP4 كامل وآخر مبتور، وصورة مصغّرة بحجم 40 كيلوبايت:

┌─────────┬──────────────────────┬────────────────┬───────┬───────┬─────────────┬────────┬─────────────────────────────┐
│ (index) │ file                 │ type           │ tail  │ holes │ minDistinct │ kbRead │ verdict                     │
├─────────┼──────────────────────┼────────────────┼───────┼───────┼─────────────┼────────┼─────────────────────────────┤
│ 0       │ 'photo-complete.jpg' │ 'JPEG'         │ true  │ 0     │ 256         │ 24.02  │ 'INTACT'                    │
│ 1       │ 'photo-cut.jpg'      │ 'JPEG'         │ false │ 0     │ 256         │ 24.02  │ 'PARTIAL'                   │
│ 2       │ 'scan.png'           │ 'PNG'          │ true  │ 0     │ 256         │ 24.03  │ 'INTACT'                    │
│ 3       │ 'report.docx'        │ 'ZIP / Office' │ false │ 0     │ 256         │ 88.04  │ 'PARTIAL'                   │
│ 4       │ 'photo-hole.jpg'     │ 'JPEG'         │ true  │ 2     │ 1           │ 24.02  │ 'GHOST'                     │
│ 5       │ 'photo-ghost.jpg'    │ 'JPEG'         │ true  │ 3     │ 1           │ 24.02  │ 'GHOST'                     │
│ 6       │ 'photo-ghost-ff.jpg' │ 'JPEG'         │ true  │ 3     │ 1           │ 24.02  │ 'GHOST'                     │
│ 7       │ 'black.bmp'          │ 'BMP'          │ '—'   │ 0     │ '—'         │ 0.02   │ 'PLAUSIBLE (no terminator)' │
│ 8       │ 'clip.mp4'           │ 'MP4 / MOV'    │ true  │ 0     │ 256         │ 24.02  │ 'INTACT'                    │
│ 9       │ 'clip-truncated.mp4' │ 'MP4 / MOV'    │ false │ 0     │ 256         │ 24.02  │ 'PARTIAL'                   │
│ 10      │ 'thumb-small.jpg'    │ 'JPEG'         │ true  │ 0     │ '—'         │ 0.02   │ 'INTACT'                    │
└─────────┴──────────────────────┴────────────────┴───────┴───────┴─────────────┴────────┴─────────────────────────────┘

ثلاثة صفوف هناك هي التي تستحق الجهد.

الصف 6 هو الملف المحشوّ بـ 0xFF. بداية سليمة، نهاية سليمة، ولا بايت صفر واحد فيه. كاشف يعُدّ الأصفار يمنحه درجة نظيفة تماماً.

الصف 7 هو BMP أسود حقيقي، مستثنى من كشف الفجوات لأنه غير مضغوط. هو أصفار بالكامل تقريباً وهو ملف جيد تماماً.

الصف 3 كلّف 88 كيلوبايت للحكم على ملف بحجم 500 كيلوبايت، لأن نهاية الدليل المركزي في ZIP يمكن أن تختبئ في أي مكان في آخر 64 كيلوبايت. تلك هي تكلفة النوافذ لكل صيغة — ومع ذلك فهي خُمس الملف، لا الملف كله.

ملاحظات عملية

شغّل هذا قبل أن تفتح الملفات المستعادة، لا بعد. فتح ملف تالف عادةً غير مؤذٍ، لكن فتحه بتطبيق يكتب — محرر صور يولّد صوراً مصغّرة، قاعدة بيانات تنشئ ملف قفل — يكتب على القرص نفسه الذي تستعيد منه.

قارن الحجم الذي بلّغت عنه أداة الاستعادة بالحجم الذي حصلت عليه فعلاً. إن قالت الأداة 4 ميغابايت والملف على القرص 900 كيلوبايت، فلست بحاجة إلى أي مما سبق.

رتّب حسب الحُكم قبل أن ترتّب حسب أي شيء آخر، وانسخ السليمة أولاً. على قرص يتعطّل فعلياً، الترتيب الذي تعمل به أثمن من الأداة التي اخترتها.

كيف كُتب هذا

أنشر هذا وفق سياسة DEV للذكاء الاصطناعي، وهذه هي الرواية الصادقة: المسوّدة كتبها وكيل ذكاء اصطناعي من مشكلة اخترتُها، بتعليمة واحدة دائمة — لا يُكتب أي ادّعاء قبل أن يُنفَّذ. الحالات الاختبارية الأحد عشر في الجدول أعلاه بُنيت مصفوفات بايت، وأُمرّرت عبر الدالة، ومُخرجاتها لُصقت هنا. لا شيء منها توضيحي.

سأقول ما الذي اشتراه ذلك، لأنه الجزء الوحيد من هذه العملية الذي يستحق القراءة.

كانت الخطة الأصلية أن أكتشف الملف الأجوف بالطريقة الواضحة: أعدّ الأصفار في المنتصف وأسمّيه فارغاً. ثم بنيت JPEG مزيّفاً محشوّاً بـ 0xFF بدل 0x00 — بداية سليمة، نهاية سليمة، ميغابايتان من لا شيء، ولا بايت صفر واحد في أي مكان. بلّغ الفحص الساذج عنه بأنه ملف سليم. وكذلك فعل كل مقطع «تحقّق من ملفاتك المستعادة» وجدته، لأنها كلها تسأل سؤالاً واحداً والسؤال خطأ.

ذاك أنتج القاعدة الفعلية في هذا المقال: اسأل عمّا إذا كانت قطعة من الملف فيها تنوّع، لا عمّا إذا كان فيها أصفار. بيانات مضغوطة حقيقية تلامس كل قيم البايت الـ 256 في عيّنة بحجم 8 كيلوبايت. والحشو يلامس قيمة واحدة. السؤال المُعاد صياغته يمسك الحشو بالأصفار والحشو بـ 0xFF والأنماط القصيرة المتكرّرة بثلاثة أسطر الكود نفسها.

وهذه نسخة محدّدة صغيرة من شيء عام: الاختبارات كانت أثمن من الكتابة. النموذج يكتب فقرة واثقة عن أيّ من المنهجين في العدد نفسه من الثواني. وحده التشغيل يقول لك أيهما الخطأ.

The file you recovered might be a ghost: checking integrity from the bytes alone

LIN — Mon, 05 Oct 2026 14:48:15 +0000

You run a recovery tool over a drive. It finishes with a number that feels like good news — 3,148 files found. Then you start opening them. Maybe half don't work. Some open and show a grey rectangle. Some are accepted by the viewer and display the wrong picture. Some are 4 MB on disk and contain nothing at all.

Recovery software isn't lying to you. It found the directory entry: the name, the size, the location the file used to occupy. What it can't know is whether the clusters behind that entry are still the clusters that belong to it.

Deleting a file doesn't erase it. On NTFS the entry is flagged and the space is marked free, and the bytes sit there until something else is written over them. Which means there are three independent things that can go wrong, and recovery tools report all three as "found".

The data was overwritten. The name came back; the contents are now somebody else's.

The data was partly overwritten. The first N clusters came back, the rest is gone. This is the nasty one — the file has a plausible size, a correct header, and opens in some viewers while rendering garbage.

The data never existed in the file you got. The tool knew the file was supposed to be 4 MB, so it wrote you 4 MB. The first two bytes and the last two bytes come from the format; everything between them is filler.

You can't ask the filesystem which case you're in. But you can ask the bytes.

Step 1: head and tail

Most formats put a fixed signature at the start and a terminator at the end. If either is missing, the file is cut.

Format	Must start with	Must end with
JPEG	`FF D8 FF`	`FF D9` (EOI)
PNG	`89 50 4E 47 0D 0A 1A 0A`	`IEND` + CRC (`49 45 4E 44 AE 42 60 82`)
PDF	`%PDF-`	`%%EOF` in the trailing couple of KB
DOCX / XLSX / ZIP	`PK`	end-of-central-directory `50 4B 05 06`
MP4 / MOV	an `ftyp` box	a `moov` index, at either end

Note the asymmetry, because getting this wrong marks valid files broken. A JPEG's EOI is the last two bytes, so you look at a 2-byte window. A ZIP's EOCD is somewhere in the last 64 KB + 22 bytes, because an archive comment can follow it. A PDF's %%EOF can be anywhere in the trailing 2 KB — and there can be more than one if the file was incrementally updated. Hardcode "check the last N bytes" across all formats and you'll produce false alarms all afternoon.

And then there's MP4, where the terminator isn't at the end at all. moov is a top-level box that can sit before or after mdat, so a tail window won't find it. You walk the box tree instead — each box is a 4-byte size followed by a 4-byte type, so you can hop from one to the next:

async function hasMoov(blob) {
  let off = 0;
  for (let i = 0; i < 64; i++) {
    const h = await range(blob, off, 16);
    if (h.length < 8) return false;
    if (String.fromCharCode(h[4], h[5], h[6], h[7]) === 'moov') return true;
    let sz = h[0] * 2 ** 24 + h[1] * 2 ** 16 + h[2] * 256 + h[3];
    if (sz === 1) { sz = 0; for (let k = 8; k < 16; k++) sz = sz * 256 + h[k]; }
    if (sz === 0 || sz < 8) return false;   // 0 means "extends to end of file"
    off += sz;
    if (off >= blob.size) return false;
  }
  return false;
}

The cap on that loop is not decoration. A truncated file hands you a box size that points past the end of the data, and an unbounded walk will happily chase it forever.

Step 2: the hole in the middle

Here's the case that defeats every "is it valid" check: a file with a correct header, a correct terminator, and nothing in between.

Recovery tools routinely reconstruct a file to its declared size. If the clusters that held the middle are gone, the tool pads. You get a 4 MB JPEG whose first two bytes and last two bytes are perfect and whose contents are filler. A check that only looks at the head and the tail reports it as fine.

So you sample the middle. And the obvious way to do that — count zero bytes — has a hole in it big enough to drive a recovery job through.

Not every tool pads with zero. Some pad with 0xFF. Some repeat a short pattern. If your detector is if (zeroRatio > 0.98), a file padded with 0xFF sails straight through it, and those files are not rare.

The fix is to stop looking for a specific value and look for the absence of variety instead. A 8 KB chunk of real compressed data uses essentially all 256 byte values. A chunk of padding uses one, maybe four. That distinction catches every padding style at once:

function analyze(u8) {
  const seen = new Uint8Array(256);
  let zero = 0;
  for (let i = 0; i < u8.length; i++) { const b = u8[i]; if (b === 0) zero++; seen[b] = 1; }
  let distinct = 0;
  for (let i = 0; i < 256; i++) if (seen[i]) distinct++;
  return { zeroRatio: +(zero / u8.length).toFixed(3), distinct };
}

const isHole = (a) => a.zeroRatio > 0.98 || (a.distinct > 0 && a.distinct <= 4);

Keep the zero test as well — it earns its place, because a chunk that is 99% zeros with a few surviving bytes is still a hole, and 99% zeros will show up as, say, 30 distinct values.

Step 3: sample proportionally

Three evenly spaced points catch a contiguous hole, which is what overwriting usually produces. But three points on a 2 GB video will miss a 6 MB gap, and 6 MB is a lot of missing video.

So scale the count with the size and cap it, because the whole point of sampling is not reading the file:

function sampleOffsets(size) {
  if (size < 128 * 1024) return [];
  const n = Math.min(32, Math.max(3, Math.ceil(size / (4 * 1024 * 1024))));
  const step = size / (n + 1);
  const pts = [];
  for (let i = 1; i <= n; i++) pts.push(Math.floor(i * step));
  return pts;
}

Small files return nothing on purpose. Below about 128 KB the file is all edge and no middle — sampling it produces noise, not signal, and a thumbnails-sized JPEG would get flagged for having a boring interior.

Where this deliberately stops

Uncompressed formats are exempt. A real black BMP is genuinely, correctly almost all zeros. So is a minute of digital silence in a WAV. If you run a hole detector over those you will condemn perfectly good files, so check the format first and skip the sampling when it isn't compressed. This is the one place where knowing the type before judging the contents matters.

Structure is not content. A JPEG with an SOI, an EOI and no holes can still contain the wrong photograph, because the clusters it was rebuilt from belonged to a different file that happened to sit nearby. No byte-level check can detect that. Only a human opening it can.

Damaged doesn't mean worthless. A file we call partial still carries whatever fraction did survive. Photo recovery in particular: a JPEG missing its tail often still renders most of the image, and if it's the only copy of a photograph, "most of the image" is a very good outcome. Don't let a checker talk you into deleting anything.

And one filesystem note, because it changes your odds before you start: ext4 clears block pointers on delete, where NTFS mostly leaves them. Filenames on ext4 are usually lost outright, which is why Linux recovery is harder than Windows recovery even when the data itself survived. If you're working an ext4 volume, do it from a live USB — never from the installed system, which is writing to the same disk you're trying to rescue.

The whole thing, ready to paste

Assembled. It takes a File (or a Blob), reads only the windows it needs via Blob.slice() — which is lazy, so nothing is read until you ask for the bytes — and returns a verdict with the evidence behind it.

Paste it into a DevTools console, then either call it on a file handle you already have, or set up a drop target and drag a folder in:

document.addEventListener('dragover', (e) => e.preventDefault());
document.addEventListener('drop', async (e) => {
  e.preventDefault();
  console.table(await ghostCheck.bulk(e.dataTransfer.files));
});

const ghostCheck = (() => {
  const KB = 1024, MB = 1024 * 1024;
  const CHUNK = 8 * KB;
  const MIN_SAMPLABLE = 128 * KB;

  // Blob.slice() is lazy: nothing is read until you ask for the bytes.
  async function range(blob, start, len) {
    const s = Math.max(0, Math.round(start));
    const e = Math.min(blob.size, s + len);
    if (e <= s) return new Uint8Array(0);
    return new Uint8Array(await blob.slice(s, e).arrayBuffer());
  }

  function startsWith(u8, sig) {
    if (u8.length < sig.length) return false;
    for (let i = 0; i < sig.length; i++) if (u8[i] !== sig[i]) return false;
    return true;
  }

  function indexOf(u8, sig) {
    outer: for (let i = 0; i + sig.length <= u8.length; i++) {
      for (let j = 0; j < sig.length; j++) if (u8[i + j] !== sig[j]) continue outer;
      return i;
    }
    return -1;
  }

  const ascii = (s) => [...s].map((c) => c.charCodeAt(0));

  function analyze(u8) {
    const seen = new Uint8Array(256);
    let zero = 0;
    for (let i = 0; i < u8.length; i++) { const b = u8[i]; if (b === 0) zero++; seen[b] = 1; }
    let distinct = 0;
    for (let i = 0; i < 256; i++) if (seen[i]) distinct++;
    return { zeroRatio: +(zero / u8.length).toFixed(3), distinct };
  }

  // A hole is not always zeros. Recovery tools pad with 0x00, sometimes 0xFF,
  // sometimes a short repeating pattern. Both look the same from here:
  // a chunk of real compressed data uses ~256 distinct byte values; padding uses ~1.
  const isHole = (a) => a.zeroRatio > 0.98 || (a.distinct > 0 && a.distinct <= 4);

  function sampleOffsets(size) {
    if (size < MIN_SAMPLABLE) return [];
    const n = Math.min(32, Math.max(3, Math.ceil(size / (4 * MB))));
    const step = size / (n + 1);
    const pts = [];
    for (let i = 1; i <= n; i++) pts.push(Math.floor(i * step));
    return pts;
  }

  const FORMATS = [
    { id: 'jpeg', label: 'JPEG', head: [0xff, 0xd8, 0xff], tail: [0xff, 0xd9], tailWindow: 2, compressed: true },
    { id: 'png', label: 'PNG', head: [0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a], tail: [0x49, 0x45, 0x4e, 0x44, 0xae, 0x42, 0x60, 0x82], tailWindow: 16, compressed: true },
    { id: 'zip', label: 'ZIP / Office', head: [0x50, 0x4b], tail: [0x50, 0x4b, 0x05, 0x06], tailWindow: 65557, compressed: true },
    { id: 'pdf', label: 'PDF', head: ascii('%PDF-'), tailText: '%%EOF', tailWindow: 2048, compressed: true },
    { id: 'bmp', label: 'BMP', head: ascii('BM'), compressed: false },
    { id: 'wav', label: 'WAV', head: ascii('RIFF'), compressed: false },
  ];
  const FTYP = ascii('ftyp');

  // Walk top-level ISO-BMFF boxes looking for `moov`. Capped: a truncated file
  // can point the offset past the end, and stopping beats looping.
  async function hasMoov(blob) {
    let off = 0;
    for (let i = 0; i < 64; i++) {
      const h = await range(blob, off, 16);
      if (h.length < 8) return false;
      if (String.fromCharCode(h[4], h[5], h[6], h[7]) === 'moov') return true;
      let sz = h[0] * 2 ** 24 + h[1] * 2 ** 16 + h[2] * 256 + h[3];
      if (sz === 1) { // 64-bit extended size
        sz = 0;
        for (let k = 8; k < 16; k++) sz = sz * 256 + h[k];
      }
      if (sz === 0 || sz < 8) return false;   // 0 means "to end of file"
      off += sz;
      if (off >= blob.size) return false;
    }
    return false;
  }

  async function check(blob) {
    const size = blob.size;
    let bytesRead = 0;

    const headBytes = await range(blob, 0, 16); bytesRead += headBytes.length;
    const fmt = FORMATS.find((f) => startsWith(headBytes, f.head)) || null;
    let type = fmt ? fmt.label : 'unknown';
    const compressed = fmt ? fmt.compressed : true;
    if (!fmt && startsWith(headBytes.subarray(4, 8), FTYP)) type = 'MP4 / MOV';

    let tail = null;   // null = this format has no terminator worth checking
    if (type === 'MP4 / MOV') {
      tail = await hasMoov(blob);
    } else if (fmt && (fmt.tail || fmt.tailText)) {
      const sig = fmt.tail || ascii(fmt.tailText);
      const win = await range(blob, size - fmt.tailWindow, fmt.tailWindow);
      bytesRead += win.length;
      tail = indexOf(win, sig) >= 0;
    }

    const holes = [];
    let minDistinct = null;
    if (compressed) {
      for (const at of sampleOffsets(size)) {
        const c = await range(blob, at, CHUNK); bytesRead += c.length;
        if (c.length < 512) continue;
        const a = analyze(c);
        if (minDistinct === null || a.distinct < minDistinct) minDistinct = a.distinct;
        if (isHole(a)) holes.push({ at, ...a });
      }
    }

    const cut = tail === false;
    const holey = holes.length > 0;
    let verdict;
    if (type === 'unknown') verdict = 'UNRECOGNISED';
    else if (!cut && !holey) verdict = tail === null ? 'PLAUSIBLE (no terminator)' : 'INTACT';
    else if (!cut && holey) verdict = 'GHOST';
    else if (cut && holey) verdict = 'GHOST + PARTIAL';
    else verdict = 'PARTIAL';

    return {
      type, size, tail: tail === null ? '—' : tail, holes: holes.length,
      minDistinct: minDistinct === null ? '—' : minDistinct,
      kbRead: +(bytesRead / 1024).toFixed(2), verdict,
    };
  }

  check.bulk = async (files) => Promise.all(
    [...files].map(async (f) => ({ file: f.name, ...(await check(f)) }))
  );

  return check;
})();

Against synthetic files — a complete JPEG, one cut before its EOI, a complete PNG, a DOCX with no EOCD, a JPEG with a single hole, a padded JPEG, the same padded with 0xFF instead of zero, a legitimate black BMP, a complete and a truncated MP4, and a 40 KB thumbnail:

┌─────────┬──────────────────────┬────────────────┬───────┬───────┬─────────────┬────────┬─────────────────────────────┐
│ (index) │ file                 │ type           │ tail  │ holes │ minDistinct │ kbRead │ verdict                     │
├─────────┼──────────────────────┼────────────────┼───────┼───────┼─────────────┼────────┼─────────────────────────────┤
│ 0       │ 'photo-complete.jpg' │ 'JPEG'         │ true  │ 0     │ 256         │ 24.02  │ 'INTACT'                    │
│ 1       │ 'photo-cut.jpg'      │ 'JPEG'         │ false │ 0     │ 256         │ 24.02  │ 'PARTIAL'                   │
│ 2       │ 'scan.png'           │ 'PNG'          │ true  │ 0     │ 256         │ 24.03  │ 'INTACT'                    │
│ 3       │ 'report.docx'        │ 'ZIP / Office' │ false │ 0     │ 256         │ 88.04  │ 'PARTIAL'                   │
│ 4       │ 'photo-hole.jpg'     │ 'JPEG'         │ true  │ 2     │ 1           │ 24.02  │ 'GHOST'                     │
│ 5       │ 'photo-ghost.jpg'    │ 'JPEG'         │ true  │ 3     │ 1           │ 24.02  │ 'GHOST'                     │
│ 6       │ 'photo-ghost-ff.jpg' │ 'JPEG'         │ true  │ 3     │ 1           │ 24.02  │ 'GHOST'                     │
│ 7       │ 'black.bmp'          │ 'BMP'          │ '—'   │ 0     │ '—'         │ 0.02   │ 'PLAUSIBLE (no terminator)' │
│ 8       │ 'clip.mp4'           │ 'MP4 / MOV'    │ true  │ 0     │ 256         │ 24.02  │ 'INTACT'                    │
│ 9       │ 'clip-truncated.mp4' │ 'MP4 / MOV'    │ false │ 0     │ 256         │ 24.02  │ 'PARTIAL'                   │
│ 10      │ 'thumb-small.jpg'    │ 'JPEG'         │ true  │ 0     │ '—'         │ 0.02   │ 'INTACT'                    │
└─────────┴──────────────────────┴────────────────┴───────┴───────┴─────────────┴────────┴─────────────────────────────┘

Three rows in there are the ones worth the effort.

Row 6 is the 0xFF-padded file. Head intact, tail intact, not a single zero byte in it. A zero-counting detector scores it perfectly clean.

Row 7 is a real black BMP, exempt from hole detection because it's uncompressed. It's almost entirely zeros and it is a perfectly good file.

Row 3 cost 88 KB to judge a 500 KB file, because the ZIP end-of-central-directory can hide anywhere in the last 64 KB. That's the price of per-format windows — and it's still a fifth of the file, rather than the whole thing.

Practical notes

Run this before you open recovered files, not after. Opening a damaged file is usually harmless, but opening it with an application that writes — a photo editor generating thumbnails, a database creating a lock file — writes to the same drive you're recovering from.

Compare the size the recovery tool reported against the size you actually got. If the tool said 4 MB and the file on disk is 900 KB, you don't need any of the above.

Sort by verdict before you sort by anything else, and copy the intact ones off first. On a drive that's actively failing, the order you work in is worth more than the tool you picked.

How this was written

Disclosure first, since DEV asks for it: the draft of this post was written by an AI agent from a problem I chose, with one standing instruction — no claim gets written down until it has been executed. The eleven test cases in the table above were built as byte arrays, fed through the function, and their output pasted here. None of it is illustrative.

I'll say what that bought, because it's the only part of this process worth reading about.

The original plan was to detect a hollow file the obvious way: count zero bytes in the middle and call it empty. Then I built a fake JPEG padded with 0xFF instead of 0x00 — head intact, tail intact, two megabytes of nothing, and not a single zero byte anywhere. The naive check reported it as a healthy file. So did every "verify your recovered files" snippet I could find, because they all ask one question and the question is wrong.

That produced the actual rule in this post: ask whether a chunk of the file has variety, not whether it has zeros. Real compressed data will touch all 256 byte values in an 8 KB sample. Padding touches one. The reframed question catches zero-fill, 0xFF-fill and short repeating patterns with the same three lines of code.

Which is a specific, small version of a general thing: the tests were worth more than the writing. A model writes a confident paragraph about either approach in the same number of seconds. Only the run tells you which one is wrong.

أسماء ملفاتك ليست تالفة — إنها تُقرأ بالأبجدية الخطأ

LIN — Sun, 04 Oct 2026 06:54:32 +0000

تفتح ملف ZIP أرسله إليك زميل، فتجد بالداخل ما يلي:

Ø§Ù„ØµÙˆØ±Ø©.jpg
ØªÙ‚Ø±ÙŠØ± Ù†Ù‡Ø§Ø¦ÙŠ.pdf
IÅŸÄ±k.txt

الملفات نفسها تُفتح بلا مشكلة: الصورة سليمة، وملف PDF يُعرض كما ينبغي. الأسماء وحدها هي غير المقروءة. وحين يكون عددها أربعمئة، فإن أربعمئة اسم غير مقروء مشكلة حقيقية: لا يمكنك ترتيبها، ولا البحث فيها، ولا إعادتها إلى من طلبها.

إن كانت أغلب خبرتك مع أسماء ملفات إنجليزية فسيبدو لك هذا تلفاً. لكنه ليس كذلك. لم يصب البايتات شيء. كل واحد من هذه الأسماء قُرئ بترميز خاطئ، وهذا وضع أفضل بكثير، لأن الإصلاح عملية حسابية لا تخمين.

ما الذي حدث فعلاً

الصورة ستة أحرف عربية. في UTF-8 يشغل كل حرف بايتين، أي أن الاسم اثنا عشر بايتاً:

D8 A7  D9 84  D8 B5  D9 88  D8 B1  D8 A9
 ا      ل      ص      و      ر      ة

والآن اقرأ هذه البايتات الاثني عشر نفسها، بايتاً بايتاً، معامِلاً كل بايت على أنه حرف كامل في جدول رموز أحادي البايت — لنقل Windows-1252:

D8  A7  D9  84  D8  B5  D9  88  D8  B1  D8  A9
Ø   §   Ù   „   Ø   µ   Ù   ˆ   Ø   ±   Ø   ©

اجمعها معاً فتحصل على Ø§Ù„ØµÙˆØ±Ø©. البايتات عبرت السلك سليمة تماماً؛ كل ما حدث أنها فُكّت بالجدول الخطأ.

هذا هو الحادث بأكمله. وله اسم: الموجيباكي (mojibake) — وهو، بفارق كبير، السبب الأكثر شيوعاً لأن يكون اسم الملف «التالف» في الحقيقة سليماً.

شكل الفوضى يخبرك بالجدول الذي استُخدم

قُرئ كـ	كيف يبدو	من أين يأتي
Windows-1256 (العربية)	`ط§ظ„طµظˆط±ط©` — حروف عربية لكن بلا معنى	جهاز ويندوز عربي يقرأ بايتات UTF-8
Windows-1252 / Latin-1	`Ø§Ù„ØµÙˆØ±Ø©` — حروف لاتينية مشكّلة ورموز شاردة	أرشيفات ZIP، وFTP، والنسخ بين الأنظمة
Windows-1254 (التركية)	`IÅŸÄ±k` بدلاً من `Işık`	ويندوز تركي، وأرشيفات قديمة
Mac Arabic	`ظ\'عÑ` — عربية مختلطة بعلامات ترقيم ASCII	أرشيفات أُنشئت على أجهزة ماك القديمة
DOS Arabic (cp864)	`ﻅ§ﻋ▒` — رموز رسم صناديق وحروف حشو	أرشيفات قديمة جداً من عصر DOS
طُبّق مرتين	`Ã˜Â§Ã™â€ž` — فوضى داخلها فوضى	اسم كان خاطئاً أصلاً ثم حُوّل مرة أخرى

الصف الأخير أهم مما يبدو. الأسماء مزدوجة الترميز شائعة: يرى أحدهم الفوضى، فيمرّرها عبر محوّل «للإصلاح»، فينتج فوضى أعمق. والعملية قابلة للعكس بالعكس، فالإصلاح هو أن تطبقها مرتين.

تنفيذ ذلك في المتصفح

فكّ الترميز مجاني. فـTextDecoder يطبّق معيار WHATWG للترميز:

const bytes = new Uint8Array([0xd8, 0xa7, 0xd9, 0x84]);
new TextDecoder('windows-1252').decode(bytes);  // 'Ø§Ù„'
new TextDecoder('windows-1256').decode(bytes);  // 'ط§ظ„'

لكن هناك حدّ يستحق أن تعرفه قبل أن تبني عليه أي شيء. جرّبت كل التسميات المتعلقة بالعربية في Node 22:

windows-1256   OK
windows-1252   OK
windows-1254   OK
x-mac-arabic   The "x-mac-arabic" encoding is not supported
ibm864         The "ibm864" encoding is not supported

ثلاثة من خمسة. قائمة WHATWG تضم x-mac-cyrillic لكن بلا x-mac-arabic، وبلا أي صفحة رموز من عصر DOS إطلاقاً. أي أن الترميزين اللذين يقفان وراء أقدم الأرشيفات — وهي الأكثر عرضة للتلف من الأساس — هما بالضبط ما لن يلمسه TextDecoder. في هذه الحالات تحتاج جدولاً خاصاً بك من 256 مدخلاً، تستخرجه من بايثون (bytes.decode('mac_arabic')) أو من ملفات الخرائط لدى اتحاد يونيكود، وتشحنه كملف JSON.

ثم تأتي النقطة التي تُعثر الجميع: الاتجاه العكسي يعني تحويل حرف إلى بايت، والمتصفح لن يفعله نيابة عنك.

new TextEncoder().encode('Ø');   // [0xc3, 0x98]  ← UTF-8, always

TextEncoder مقيّد ترميزاً ثابتاً بـUTF-8. لا يوجد new TextEncoder('windows-1252') ولن يوجد. لذا تبني الجدول العكسي بنفسك، وهذا يستغرق عشرة أسطر:

function buildEncoder(label) {
  const dec = new TextDecoder(label);
  const table = new Map();
  for (let b = 0; b < 256; b++) {
    const ch = dec.decode(new Uint8Array([b]));
    if (ch.length !== 1) continue;
    if (ch === '\uFFFD') continue;   // undefined slot — several bytes land here
    if (!table.has(ch)) table.set(ch, b);
  }
  return table;
}

حاجز '\uFFFD' ليس تفصيلاً تجميلياً. جداول الرموز القديمة فيها ثغرات: فترميز Windows-1252 يترك 0x81 و0x8D و0x8F و0x90 و0x9D غير معرّفة، والمفكّك يرمز كلها إلى U+FFFD. إن أغفلت هذا الفحص، انضغطت خمسة بايتات مختلفة على حرف واحد في جدولك العكسي، فتُتلف البيانات في طريق العودة دون أن يظهر لك أي خطأ.

أما الآن فالإصلاح نفسه. تمرير واحد، مع تفصيلة تفوت معظم التنفيذات:

function pass(s, label) {
  const t = buildEncoder(label);
  const bytes = [];
  for (const ch of s) {
    const cp = ch.codePointAt(0);
    if (cp < 0x80) { bytes.push(cp); continue; }   // ASCII survived the trip
    const b = t.get(ch);
    if (b === undefined) return null;              // not reversible in this page
    bytes.push(b);
  }
  try {
    // fatal:true is the filter most implementations forget. A wrong code page
    // usually yields bytes that aren't valid UTF-8 — this rejects them for free.
    return new TextDecoder('utf-8', { fatal: true }).decode(new Uint8Array(bytes));
  } catch { return null; }
}

هذا fatal: true يؤدي عملاً حقيقياً. بدونه، يُدخل TextDecoder رمز U+FFFD في التسلسلات غير الصالحة ويعيد إليك نصاً يبدو نتيجة. ومعه، يرمي المرشحون الخاطئون استثناءً ويُستبعدون — أمراً واحداً أقل على الترتيب أن يفرزه لاحقاً.

حين يستحيل الإصلاح حقاً

حالتان لا يمكن استردادهما، وأداة تتظاهر بغير ذلك أسوأ من عديمة الفائدة.

الاسم يحتوي على حروف إحلال. إن رأيت الص رة — تلك الماسة، أو علامة استفهام ? البسيطة مكان حرف — فمعنى ذلك أن مفكّك ترميز واجه في مرحلة ما بايتات لم يستطع تمثيلها فاستبدلها. قيم البايتات الأصلية ذهبت. ولا جدول يعيدها.

الاسم اقتُطع. الموجيباكي يحافظ على الطول. فإن كان تحويل 8.3 أو حدّ نظام الملفات قد بتر الاسم، فلا شيء هناك ليفكّ ترميزه.

قول «هذا الاسم ذهب» أفضل من إرجاع تخمين يبدو معقولاً، لأن الاسم الخاطئ يُلصق بالملف، ومن تلك اللحظة لا يعود أحد قادراً على معرفة أنه كان خاطئاً يوماً ما.

اختيار المرشح الصحيح

الجزء المحرج: عدة جداول رموز تنتج الموجيباكي نفسه. البايتات العربية التي تُقرأ عبر Windows-1252 وWindows-1254 تخرج متطابقة، لأن الجدولين يشتركان في النطاق الذي تقع فيه بايتات UTF-8 العربية. ستحصل بانتظام على عدة تفكيكات صالحة بنيوياً، وعليك أن تختار بينها.

قيّمها بحسب موقع الحروف في يونيكود. لا حاجة إلى قاموس:

const BLOCKS = {
  arabic:   [[0x0600, 0x06ff], [0x0750, 0x077f], [0xfb50, 0xfdff], [0xfe70, 0xfeff]],
  latin:    [[0x0041, 0x007a], [0x00c0, 0x017f], [0x0100, 0x017f]],
  cyrillic: [[0x0400, 0x04ff]],
};

function score(s) {
  let counted = 0;
  const hits = {};
  for (const ch of s) {
    const c = ch.codePointAt(0);
    if (c < 0x80) continue;      // ASCII is neutral: extensions, digits, hyphens
    counted++;
    for (const [name, ranges] of Object.entries(BLOCKS)) {
      if (ranges.some(([lo, hi]) => c >= lo && c <= hi)) hits[name] = (hits[name] || 0) + 1;
    }
  }
  if (!counted) return 0;
  return Math.max(0, ...Object.values(hits)) / counted;
}

أبقِ ASCII خارج المقام. أخطأت في هذا في المحاولة الأولى: حساب .jpg و-01 كحروف يجعل كل اسم مثل تقرير نهائي.pdf يتوقف عند 0.77 تقريباً، فلا تستطيع استخدام عتبة نظيفة أبداً. الامتدادات والأرقام محايدة لغوياً — استبعدها فتصل النتائج الحقيقية إلى 1.0.

ولهذا أيضاً لا يجدي نطاق «فحسب جرّب الترميز الأكثر شيوعاً». أي جدول هو الصحيح يعتمد على اللغة داخل الاسم، وهي تحديداً ما لم تكن قادراً على قراءته قبل لحظة.

الكود كاملاً، جاهزاً للصق

مجمّعاً، مع تخزين مؤقت وما يصل إلى ثلاث تمريرات للأسماء مزدوجة وثلاثية الترميز. الصقه في وحدة تحكم DevTools ثم نادِ fix('Ø§Ù„ØµÙˆØ±Ø©'):

const fix = (() => {
  const LABELS = ['windows-1256', 'windows-1252', 'windows-1254'];
  const cache = new Map();

  function encoder(label) {
    if (!cache.has(label)) {
      const dec = new TextDecoder(label);
      const t = new Map();
      for (let b = 0; b < 256; b++) {
        const ch = dec.decode(new Uint8Array([b]));
        if (ch.length === 1 && ch !== '\uFFFD' && !t.has(ch)) t.set(ch, b);
      }
      cache.set(label, t);
    }
    return cache.get(label);
  }

  function pass(s, label) {
    const t = encoder(label);
    const bytes = [];
    for (const ch of s) {
      const cp = ch.codePointAt(0);
      if (cp < 0x80) { bytes.push(cp); continue; }
      const b = t.get(ch);
      if (b === undefined) return null;
      bytes.push(b);
    }
    try {
      return new TextDecoder('utf-8', { fatal: true }).decode(new Uint8Array(bytes));
    } catch { return null; }
  }

  const BLOCKS = {
    arabic:   [[0x0600, 0x06ff], [0x0750, 0x077f], [0xfb50, 0xfdff], [0xfe70, 0xfeff]],
    latin:    [[0x0041, 0x007a], [0x00c0, 0x017f], [0x0100, 0x017f]],
    cyrillic: [[0x0400, 0x04ff]],
  };

  function score(s) {
    let counted = 0;
    const hits = {};
    for (const ch of s) {
      const c = ch.codePointAt(0);
      if (c < 0x80) continue;
      counted++;
      for (const [name, ranges] of Object.entries(BLOCKS)) {
        if (ranges.some(([lo, hi]) => c >= lo && c <= hi)) hits[name] = (hits[name] || 0) + 1;
      }
    }
    if (!counted) return 0;
    return +(Math.max(0, ...Object.values(hits)) / counted).toFixed(3);
  }

  return function fix(mangled, maxPasses = 3) {
    const seen = new Map();
    seen.set(mangled, { via: 'unchanged', score: score(mangled) });
    for (const label of LABELS) {
      let cur = mangled;
      for (let i = 1; i <= maxPasses; i++) {
        const next = pass(cur, label);
        if (next === null || next === cur) break;
        cur = next;
        if (!seen.has(cur)) seen.set(cur, { via: `${label} x${i}`, score: score(cur) });
      }
    }
    return [...seen.entries()]
      .map(([text, m]) => ({ text, via: m.via, score: m.score }))
      .sort((a, b) => b.score - a.score);
  };
})();

┌─────────┬─────────────────────────────┬───────────────────┬───────┐
│ (index) │ text                        │ via               │ score │
├─────────┼─────────────────────────────┼───────────────────┼───────┤
│ 0       │ 'الصورة'                    │ 'windows-1252 x2' │ 1     │
│ 1       │ 'Ã˜Â§Ã™â€žÃ˜ÂµÃ™Ë†Ã˜Â±Ã˜Â©' │ 'unchanged'       │ 0.52  │
│ 2       │ 'Ø§Ù„ØµÙˆØ±Ø©'              │ 'windows-1252 x1' │ 0.5   │
└─────────┴─────────────────────────────┴───────────────────┴───────┘

والاسم الذي يحتوي أصلاً على U+FFFD لا يعيد شيئاً مفيداً — وهي النتيجة الصادقة:

┌─────────┬───────────────┬─────────────┬───────┐
│ (index) │ text          │ via         │ score │
├─────────┼───────────────┼─────────────┼───────┤
│ 0       │ 'Ø§Ù„Øµ Ø±Ø©' │ 'unchanged' │ 0.455 │
└─────────┴───────────────┴─────────────┴───────┘

ملاحظتان للإنتاج إن شحّنت هذا. أولاً: خزّن الجداول العكسية مؤقتاً — إعادة بناء ثلاثة جداول من 256 مدخلاً لكل اسم ملف هدرٌ حين يكون لديك أربعمئة اسم. ثانياً: احتفظ دائماً بصف unchanged، فالاسم السليم أصلاً لا شيء ليعكسه، وإرجاع نتيجة فارغة يجعل أداة تعمل تبدو معطوبة.

ولماذا نهتم أصلاً

إن كان مستخدموك في الخليج أو إيران أو تركيا فليست هذه حالة هامشية. تحدث كلما عبر أرشيف جهاز ويندوز، وكلما لمس شيء قديم اسماً حديثاً، وكلما نجا الاسم من عملية نقل ولم ينجُ إعلان ترميزه. والفشل هنا صامت: لا أحد يفتح بلاغاً عن ملف اسمه قبيح فحسب. يعيدون تسميته، أو يتعايشون معه.

الإصلاح حتمي، يستغرق أجزاء من الثانية، ويعمل بالكامل على جهاز المستخدم. قراءة اسم الملف ليست كقراءة الملف نفسه، ومعظم الناس يفضّلون ألا تقرأ الملف.

كيف كُتب هذا المقال

أنشر هذا وفق سياسة DEV للذكاء الاصطناعي، وهذه هي الرواية الصادقة: كتب المسودة وكيل ذكاء اصطناعي، انطلاقاً من مشكلة اخترتها أنا، وتحت قاعدة واحدة أصررت عليها — لا يدخل المقال شيء قبل تشغيله. كل مقطع برمجي في الأعلى نُفّذ فعلاً، والجداول ملصوقة من مخرجات حقيقية لا من الذاكرة.

هذه القاعدة أنجزت معظم العمل. ادّعاءان بدأت بهما سقطا بهدوء عند أول اختبار:

TextDecoder في Node 22 يرمي استثناءً مع x-mac-arabic وibm864. افترضت أنهما سيعملان، لأن قائمة ترميزات WHATWG تبدو شاملة — وليست كذلك. فهي تحمل x-mac-cyrillic ولا شيء غيره من عائلة Mac Arabic، ولا أي صفحة رموز من DOS إطلاقاً.
أعادت النسخة الأولى من المقطع البرمجي جدولاً فارغاً لاسم ملف لم يكن معطوباً أصلاً. أداة صحيحة، تُبلّغ عن فشل، أمام أكثر مُدخل ستواجهه على الإطلاق.

لا شيء منهما كان لينجو لو بقي مجرد وصف. كلاهما سقط من تشغيل الكود. وهذه هي الحجة كاملة لتشغيل أمثلتك — ولاعتبار عبارة «النموذج يقول ذلك» فرضية، حتى حين يكون النموذج نفسه هو من يكتب مقالك.

Your file names aren't corrupt. They're just being read in the wrong alphabet.

LIN — Fri, 02 Oct 2026 11:57:24 +0000

You open a ZIP that came from a colleague and this is what's inside:

Ø§Ù„ØµÙˆØ±Ø©.jpg
ØªÙ‚Ø±ÙŠØ± Ù†Ù‡Ø§Ø¦ÙŠ.pdf
IÅŸÄ±k.txt

The files open fine. The photo is intact, the PDF renders. Only the names are unreadable, and when there are four hundred of them, four hundred unreadable names is a genuine problem — you can't sort them, search them, or hand them back to the person who asked.

If you've mostly worked with English filenames, this looks like corruption. It isn't. Nothing happened to the bytes. Every one of those names was read with the wrong character encoding, which is a much better situation to be in, because the fix is arithmetic rather than guesswork.

What actually happened

الصورة is six Arabic letters. In UTF-8 each one takes two bytes, so the name is twelve bytes:

D8 A7  D9 84  D8 B5  D9 88  D8 B1  D8 A9
 ا      ل      ص      و      ر      ة

Now read those exact twelve bytes one at a time, treating each byte as a whole character in a single-byte code page — Windows-1252, say:

D8  A7  D9  84  D8  B5  D9  88  D8  B1  D8  A9
Ø   §   Ù   „   Ø   µ   Ù   ˆ   Ø   ±   Ø   ©

Put them together and you get Ø§Ù„ØµÙˆØ±Ø©. The bytes crossed the wire perfectly. They were just decoded against the wrong table.

That's the entire accident. It's called mojibake, and it is by far the most common reason a "damaged" filename is actually fine.

The shape of the mess tells you which table was used

Read as	What it looks like	Where it comes from
Windows-1256 (Arabic)	`ط§ظ„طµظˆط±ط©` — still Arabic letters, but nonsense	An Arabic Windows box reading UTF-8 bytes
Windows-1252 / Latin-1	`Ø§Ù„ØµÙˆØ±Ø©` — accented Latin, stray symbols	ZIP archives, FTP, cross-system copies
Windows-1254 (Turkish)	`IÅŸÄ±k` for `Işık`	Turkish Windows, older archives
Mac Arabic	`ظ\'عÑ` — Arabic mixed with ASCII punctuation	Archives created on old Macs
DOS Arabic (cp864)	`ﻅ§ﻋ▒` — box drawing and filler glyphs	Very old DOS-era archives
Applied twice	`Ã˜Â§Ã™â€ž` — a mess with a mess inside it	A name that was already wrong, converted again

That last row matters more than it looks. Double-encoded names are common: somebody sees the mess, runs it through a converter to "fix" it, and produces a deeper mess. The operation is reversible in reverse, so the fix is just to apply it twice.

Doing it in the browser

Decoding is free. TextDecoder implements the WHATWG encoding standard:

const bytes = new Uint8Array([0xd8, 0xa7, 0xd9, 0x84]);
new TextDecoder('windows-1252').decode(bytes);  // 'Ø§Ù„'
new TextDecoder('windows-1256').decode(bytes);  // 'ط§ظ„'

But there's a limit worth knowing before you build anything on this. I tried every Arabic-relevant label in Node 22:

windows-1256   OK
windows-1252   OK
windows-1254   OK
x-mac-arabic   The "x-mac-arabic" encoding is not supported
ibm864         The "ibm864" encoding is not supported

Three out of five. WHATWG's list includes x-mac-cyrillic but no x-mac-arabic, and no DOS code pages at all. So the two encodings behind the oldest archives — the ones most likely to be mangled in the first place — are exactly the ones TextDecoder won't touch. For those you need your own 256-entry table, dumped from Python (bytes.decode('mac_arabic')) or from the Unicode Consortium's mapping files, shipped as JSON.

Then comes the part that trips everyone: going backwards means char → byte, and the browser won't do that for you.

new TextEncoder().encode('Ø');   // [0xc3, 0x98]  ← UTF-8, always

TextEncoder is hardcoded to UTF-8. There is no new TextEncoder('windows-1252') and there won't be one. So you build the reverse table yourself, which takes ten lines:

function buildEncoder(label) {
  const dec = new TextDecoder(label);
  const table = new Map();
  for (let b = 0; b < 256; b++) {
    const ch = dec.decode(new Uint8Array([b]));
    if (ch.length !== 1) continue;
    if (ch === '\uFFFD') continue;   // undefined slot — several bytes land here
    if (!table.has(ch)) table.set(ch, b);
  }
  return table;
}

The '\uFFFD' guard is not cosmetic. Legacy code pages have holes — Windows-1252 leaves 0x81, 0x8D, 0x8F, 0x90 and 0x9D undefined — and the decoder maps all of them to U+FFFD. Skip that check and five different bytes collapse onto one character in your reverse table, and you corrupt data on the way back without any error.

Now the repair itself. One pass, with a detail most implementations miss:

function pass(s, label) {
  const t = buildEncoder(label);
  const bytes = [];
  for (const ch of s) {
    const cp = ch.codePointAt(0);
    if (cp < 0x80) { bytes.push(cp); continue; }   // ASCII survived the trip
    const b = t.get(ch);
    if (b === undefined) return null;              // not reversible in this page
    bytes.push(b);
  }
  try {
    // fatal:true is the filter most implementations forget. A wrong code page
    // usually yields bytes that aren't valid UTF-8 — this rejects them for free.
    return new TextDecoder('utf-8', { fatal: true }).decode(new Uint8Array(bytes));
  } catch { return null; }
}

That fatal: true is doing real work. Without it, TextDecoder inserts U+FFFD for invalid sequences and hands you back a string that looks like a result. With it, wrong candidates throw and get dropped — one less thing your ranking has to sort out later.

When it genuinely cannot be fixed

Two cases are not recoverable, and a tool that pretends otherwise is worse than useless.

The name contains replacement characters. If you see الص رة — the diamond, or a plain ? where a letter should be — then at some point a decoder met bytes it couldn't represent and substituted. The original byte values are gone. There is no table that brings them back.

The name was truncated. Mojibake preserves length. If an 8.3 conversion or a filesystem limit chopped the name, there's nothing to decode.

Saying "this one is gone" beats returning a plausible-looking guess, because a wrong name gets pasted onto a file and from then on nobody can tell it was ever wrong.

Picking the right candidate

The awkward part: several code pages produce the same mojibake. Arabic bytes read through Windows-1252 and Windows-1254 come out identical, because those two pages share the range where Arabic UTF-8 bytes land. You will regularly get multiple structurally-valid decodings and have to choose between them.

Score them by where the characters sit in Unicode. No dictionary required:

const BLOCKS = {
  arabic:   [[0x0600, 0x06ff], [0x0750, 0x077f], [0xfb50, 0xfdff], [0xfe70, 0xfeff]],
  latin:    [[0x0041, 0x007a], [0x00c0, 0x017f], [0x0100, 0x017f]],
  cyrillic: [[0x0400, 0x04ff]],
};

function score(s) {
  let counted = 0;
  const hits = {};
  for (const ch of s) {
    const c = ch.codePointAt(0);
    if (c < 0x80) continue;      // ASCII is neutral: extensions, digits, hyphens
    counted++;
    for (const [name, ranges] of Object.entries(BLOCKS)) {
      if (ranges.some(([lo, hi]) => c >= lo && c <= hi)) hits[name] = (hits[name] || 0) + 1;
    }
  }
  if (!counted) return 0;
  return Math.max(0, ...Object.values(hits)) / counted;
}

Keep ASCII out of the denominator. I got this wrong on the first pass: scoring .jpg and -01 as characters makes every تقرير نهائي.pdf top out around 0.77, so you can never use a clean threshold. Extensions and digits are language-neutral — exclude them and real results land on 1.0.

This is also why "just try the most common encoding" doesn't work. Which page is correct depends on the language inside the name, which is precisely what you couldn't read a moment ago.

The whole thing, ready to paste

Assembled, with caching and up to three passes for double- and triple-encoded names. Paste it into a DevTools console and call fix('Ø§Ù„ØµÙˆØ±Ø©'):

const fix = (() => {
  const LABELS = ['windows-1256', 'windows-1252', 'windows-1254'];
  const cache = new Map();

  function encoder(label) {
    if (!cache.has(label)) {
      const dec = new TextDecoder(label);
      const t = new Map();
      for (let b = 0; b < 256; b++) {
        const ch = dec.decode(new Uint8Array([b]));
        if (ch.length === 1 && ch !== '\uFFFD' && !t.has(ch)) t.set(ch, b);
      }
      cache.set(label, t);
    }
    return cache.get(label);
  }

  function pass(s, label) {
    const t = encoder(label);
    const bytes = [];
    for (const ch of s) {
      const cp = ch.codePointAt(0);
      if (cp < 0x80) { bytes.push(cp); continue; }
      const b = t.get(ch);
      if (b === undefined) return null;
      bytes.push(b);
    }
    try {
      return new TextDecoder('utf-8', { fatal: true }).decode(new Uint8Array(bytes));
    } catch { return null; }
  }

  const BLOCKS = {
    arabic:   [[0x0600, 0x06ff], [0x0750, 0x077f], [0xfb50, 0xfdff], [0xfe70, 0xfeff]],
    latin:    [[0x0041, 0x007a], [0x00c0, 0x017f], [0x0100, 0x017f]],
    cyrillic: [[0x0400, 0x04ff]],
  };

  function score(s) {
    let counted = 0;
    const hits = {};
    for (const ch of s) {
      const c = ch.codePointAt(0);
      if (c < 0x80) continue;
      counted++;
      for (const [name, ranges] of Object.entries(BLOCKS)) {
        if (ranges.some(([lo, hi]) => c >= lo && c <= hi)) hits[name] = (hits[name] || 0) + 1;
      }
    }
    if (!counted) return 0;
    return +(Math.max(0, ...Object.values(hits)) / counted).toFixed(3);
  }

  return function fix(mangled, maxPasses = 3) {
    const seen = new Map();
    seen.set(mangled, { via: 'unchanged', score: score(mangled) });
    for (const label of LABELS) {
      let cur = mangled;
      for (let i = 1; i <= maxPasses; i++) {
        const next = pass(cur, label);
        if (next === null || next === cur) break;
        cur = next;
        if (!seen.has(cur)) seen.set(cur, { via: `${label} x${i}`, score: score(cur) });
      }
    }
    return [...seen.entries()]
      .map(([text, m]) => ({ text, via: m.via, score: m.score }))
      .sort((a, b) => b.score - a.score);
  };
})();

┌─────────┬─────────────────────────────┬───────────────────┬───────┐
│ (index) │ text                        │ via               │ score │
├─────────┼─────────────────────────────┼───────────────────┼───────┤
│ 0       │ 'الصورة'                    │ 'windows-1252 x2' │ 1     │
│ 1       │ 'Ã˜Â§Ã™â€žÃ˜ÂµÃ™Ë†Ã˜Â±Ã˜Â©' │ 'unchanged'       │ 0.52  │
│ 2       │ 'Ø§Ù„ØµÙˆØ±Ø©'              │ 'windows-1252 x1' │ 0.5   │
└─────────┴─────────────────────────────┴───────────────────┴───────┘

And a name that already contains U+FFFD returns nothing usable — the honest outcome:

┌─────────┬───────────────┬─────────────┬───────┐
│ (index) │ text          │ via         │ score │
├─────────┼───────────────┼─────────────┼───────┤
│ 0       │ 'Ø§Ù„Øµ Ø±Ø©' │ 'unchanged' │ 0.455 │
└─────────┴───────────────┴─────────────┴───────┘

Two production notes if you ship this. Cache the reverse tables — rebuilding three 256-entry maps per filename is wasteful when you have 400 of them. And always keep the unchanged row: a name that was already fine has nothing to reverse, and returning an empty result makes a working tool look broken.

Why bother

If your users are in the Gulf, Iran or Türkiye, this isn't an edge case. It happens every time an archive crosses a Windows box, every time something legacy touches a modern filename, every time a name survives a transfer but its encoding declaration doesn't. And the failure is quiet — nobody files a bug about a file whose name is merely ugly. They rename it, or they live with it.

The repair is deterministic, takes milliseconds, and runs entirely on the user's device. Reading a filename is not the same as reading the file, and most people would rather you didn't read the file.

How this was written

I'm publishing this under DEV's AI guidelines, so here's the honest version: the draft was written by an AI agent, working from a problem I picked and under one rule I insisted on — nothing goes into the post until it has been run. Every snippet below was executed, and the tables are pasted from real output rather than from memory.

That rule did most of the work. Two claims I started with quietly failed on contact:

TextDecoder in Node 22 throws on x-mac-arabic and ibm864. I assumed they'd work, because the WHATWG encoding list looks comprehensive — it isn't. It carries x-mac-cyrillic and nothing else from the Mac Arabic family, and no DOS code pages at all.
The first version of the snippet returned an empty table for a filename that was never broken. A correct tool, reporting failure, for the most common input it would ever see.

Neither would have survived as a description. Both fell out of running the code. Which is the whole argument for running your examples — and for treating "the model says so" as a hypothesis, including when the model is the one writing your blog post.