Uploading Mac screenshots results in broken images, due to question marks inserted in filenames

[room34]

macOS 15 Sequoia (and possibly earlier versions) uses a special character, rather than a regular ASCII space, in screenshot filenames, between the time and the AM/PM. For instance:

Screenshot 2025-02-19 at 2.17.33 PM.png

It may get lost here, but the character before PM in that filename is not a regular space. I ran the filename text string through a hex converter, and it identified it as the Unicode [the narrow no-break space](​https://www.fileformat.info/info/unicode/char/202f/index.htm) (U+202F).

The problem is, when uploading a file with that type of filename (tested in both Safari and Firefox), the WordPress function that standardizes Media Library filenames converts that character into a question mark, rather than a hyphen.

For obvious reasons, there should never be a question mark in filenames in the Media Library. The result is of course that the browser interprets the part after the question mark as a query string, and now the URL is requesting a non-existent file, causing a broken image on the page.

The attached screenshot shows the filename with a question mark after uploading the image to the Media Library.

[room34]

Screenshot showing filename with question mark in Media Library

[audrasjb]

Hello and thanks for the ticket,

Could you please attach the exact file you can't upload so we can try to reproduce the issue?

[room34]

Replying to audrasjb:

Hello and thanks for the ticket,

Could you please attach the exact file you can't upload so we can try to reproduce the issue?

The file I uploaded is a screenshot itself with the same type of filename, so it could be used for testing. However I suspect its filename has been converted by Trac in a different way and the issue would not happen. Testing can be done easily by anyone on a Mac by just creating a screenshot and trying to upload it.

[audrasjb]

@room34 I can confirm this file can't be used to reproduce the issue. Maybe compress your initial file to a zip file and try to attach it?

[room34]

@audrasjb I think it’s possible/likely that you need to be on a Mac file system to properly reproduce the issue, so you or whoever is trying to reproduce could just take a screenshot on that system and use it for testing.

[audrasjb]

Replying to room34:

@audrasjb I think it’s possible/likely that you need to be on a Mac file system to properly reproduce the issue, so you or whoever is trying to reproduce could just take a screenshot on that system and use it for testing.

I am on a Mac system. But as my computer's locale is French, I don't have the same default file names than yours (and it works on my side).

[room34]

@audrasjb Of course… I apologize for my US-centric mindset. I've zipped the file and am adding it as another attachment.

[room34]

Zipped version of the file for testing

[audrasjb]

Thanks! By the way I can't reproduce the issue on my side: the media is successfully uploaded. Maybe it's an environment issue on your side?
Could you please try on a fresh instance of WP? Or on this ​Playground instance?

[room34]

Interesting...

Tested in Playground: Uploads successfully.

Tested with clean WordPress install of a new site on the same server: Uploads successfully.

Tested on original site with all plugins deactivated, Twenty Twenty-Five theme, and WP core reinstalled: Error still occurs.

It looks like it has to do with the data tables. The original site where the error is happening is a very old installation. It's running 6.7.2, but it was originally created with WordPress 2.1 in 2007.

I noticed the installations where this was successful did not replace the narrow no-break space character in the filename. I checked the database, and the core WP tables have "latin1_swedish_ci" collation, so they're not UTF-8. That would explain the question marks.

Anyway… I do think this still points to an issue that should be addressed. Since WordPress is already modifying Media Library filenames to be maximally compatible for URLs, I would think ideally it would strip out most non-ASCII characters, at least non-essential ones, like the narrow no-break space.