This appears to have prompted GitHub to warn on ambiguous Unicode characters in diffs like other source control programs (namely Gitea from the article) already do. Love it.
this post was submitted on 19 May 2025
51 points (98.1% liked)
Programming
21106 readers
282 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
https://github.blog/changelog/2025-05-01-github-now-provides-a-warning-about-hidden-unicode-text/ since may 1st (OP is from may 16th)
Ah, I see. GitHub reached out to Daniel saying “hey we’re actually doing that” not because it was a reaction to the post.
It's possible their communication happened before that, and it just took a while to write and post OP post. 16 days is not that long or delayed. I haven't checked the dates of the commits in question though.
I have a bit of a radical approach preventing these issues: don't allow unicode unless explicitly indicated or in contexts where it's required or harmless
That sounds good, but when you start thinking about how to implement this practically, it seems like it would either be unfeasible or would fail to really address the problem.
Maybe the rule would be: Unicode is allowed only in resource files. It would make code comments awkward for many non-English-speaking programmers. But suppose you did it, then since URLs can include Unicode, it would become normal to put URLs in resource files. If the VCS flagged up Unicode commits in source code, it would have to give resource files a pass. So in any case where you're not hardcoding a URL it wouldn't flag up Unicode URL abuses like the one illustrated here. You wouldn't really have fixed the problem, just hidden it in a different way. You'd still need to flag up ambiguous Unicode characters in resource files.
A linter can get quite a bit more in depth than a file-to-file approach. At the very least you can use an ambigious character block list for function names
That's exactly the solution from the article 👌
In the curl git repository most files and most content are plain old ASCII so we can “easily” whitelist a small set of UTF-8 sequences and some specific files, the rest of the files are simply not allowed to use UTF-8 at all as they will then fail the CI job and turn up red.