Sanitize filename in nodejs

https://github.com/parshap/node-sanitize-filename https://www.npmjs.com/package/sanitize-filename https://github.com/minimaxir/big-list-of-naughty-strings https://raw.githubusercontent.com/minimaxir/big-list-of-naughty-strings/refs/heads/master/blns.json

Why this breaks

Most filesystems reject or mishandle special Unicode "noncharacters" like U+FFFE or U+FFFF.

That’s why fs.writeFile can’t even create/open the file—it’s not a valid filename on your system (likely macOS or Linux).

What to do

Sanitize your filename before writing. You’re already testing sanitize-filename, so the bug might be that your sanitization didn’t catch this edge case (U+FFFE).

const sanitize = require("sanitize-filename");
const safePath = sanitize(filepath) || "default.txt";
fs.writeFile(safePath, "foobar", ...);

Or, if this is part of the test suite: The test is intentionally checking that sanitize-filename strips out unsafe Unicode. It’s failing because the library allowed � to pass through.

✅ In short: Your code is failing because the filepath contains U+FFFE (�), which the filesystem rejects. The solution is to sanitize filenames to remove such invalid characters before writing.

Do you want me to show you how to patch sanitize-filename so that U+FFFE and similar invalid Unicode points get stripped out automatically?

You said: Yes, but shouldn't the npm library already strip those invalid characters? ChatGPT said:

Good instinct — you’re right to expect that. The sanitize-filename library is supposed to make sure you end up with a safe, cross-platform filename. But here’s the nuance:

What sanitize-filename does

It removes characters that are explicitly invalid in Windows (<>:"/\|?*) and control chars (\x00–\x1f).

It also trims things like "." or reserved names (CON, PRN, etc.) that would break on Windows.

But it does not filter out all Unicode noncharacters (like U+FFFE or U+FFFF), because:

POSIX filesystems (Linux, macOS) technically allow almost any byte sequence except \0 and /.

The library was designed with cross-platform minimum guarantees, not absolute safety for every kernel/filesystem quirk.

Why you’re seeing the error

� (U+FFFE) is a noncharacter — Unicode defines it as “never valid for interchange”.

Many libc / filesystem layers treat it as an illegal byte sequence → EILSEQ.

So while it’s technically not in the set that sanitize-filename strips, in practice it still breaks.

So… is this a bug?

Yes (practically): A “sanitized” filename should never crash on common systems.

No (technically): The library never promised to catch every invalid Unicode noncharacter. It only guaranteed Windows-invalid and control chars.

If you look at sanitize-filename issues on GitHub , people have reported similar gaps — the maintainers typically say: if your application cares about stricter sanitization (e.g., reject/strip all noncharacters, private-use code points, etc.), you need to extend it.

How to patch

You can wrap sanitize-filename with an extra filter for these code points:

const sanitize = require("sanitize-filename");

function strictSanitize(input) {
  let safe = sanitize(input);

  // Remove Unicode noncharacters (U+FDD0–U+FDEF, U+FFFE, U+FFFF)
  safe = safe.replace(
    /[\uFDD0-\uFDEF\uFFFE\uFFFF]/g,
    ""
  );

  return safe || "default.txt";
}

Now, when you run your test with �, it should get stripped out and succeed.

✅ Bottom line: The npm library doesn’t strip � because it’s not in its default invalid-char set. If you need bulletproof safety, you’ll want to extend it as shown above.

primaryobjects/readme.md