Function looks_binary 

pub fn looks_binary(content: &[u8]) -> bool

Whether git — and therefore we — would treat this content as binary.

A byte-for-byte port of git’s gather_stats plus convert_is_binary, measured against git 2.55 rather than taken from documentation. Binary means a NUL byte anywhere, a lone CR — one not followed by LF — or too many disallowed control characters relative to printable ones.

The three details that make it a port rather than an approximation, each of which git-xcrypt got wrong before and each of which moves real files across the boundary:

• CR and LF are counted as line endings and go into neither bucket;
• DEL (0x7f) counts as non-printable, despite being above 0x20;
• of the bytes below 0x20 only BS, TAB, FF and ESC are forgiven;
• a trailing SUB (0x1a, the DOS end-of-file marker) is taken back off the non-printable count after the scan. One byte, only the last one.

Bytes at or above 0x80 count as printable, which is why UTF-8 text is recognised as text. The whole content is scanned; the 8000-byte window belongs to a different heuristic, the one git diff uses to print Binary files differ.

The lone-CR rule is not decoration. Without it, content such as a\r\r\nb normalises to a\r\nb, which normalises again to a\nb — so the conversion is not closed over its own output, the working tree comes back different after a checkout and git status reports a file nobody edited. Git avoids that the same way, by declining to convert at all.

This rule is frozen with the format from 2026-08-04, and not before: the trailing-SUB correction landed on that date (roadmap S-08), deliberately ahead of the first release. Changing it moves the text/binary boundary, so every file that crosses the boundary encrypts differently — after a release that stops being a fix and becomes a new suite.