The need to do this is because if the file system encoding is something that isn't byte-based, such as utf-16be on Windows, then you have a combination of the ascii output from fontconfig with the embedded filename path in utf-16.

It is possible that '\n' could be in the filename, but again, that's kind of a degenerate case.  It would not appear unexpectedly as a utf-8 surrogate pair (since utf-8 ensures that the control characters always remain control characters).  It could appear in utf-16 as an upper byte, I suppose.

The colon is indeed an issue, however.

Looking at the fc-list manpage further, I think we can provide it with a custom output format that would only contain the filepath (which is the only part we care about anyway).  That would simplify this...