I'm thinking that making your hack vaguely compatible with existing solutions is more important than human convention, which you are obviously breaking anyway.
There are some common encodings which you might find easier to use because there are existing tools etc which can help you manage the conventions you choose, though of course there is no OS support for making it work reliably and transparently.
- URLs have percent encoding; a literal per cent sign followed by two hex digits; so to represent "5/5%=0" you would end up with
5%2F5%25=0
(the literal per cent sign obviously also needs to be encoded)
- Email (or more generally MIME) has quoted-printable encoding, which is quite similar, except the "magic" character is an equals sign. So to represent "5/5%=0" you would end up with
5=2F5%=3D0
(where obviously the literal equals sign needs to be encoded).
- If you need to make it reasonably obvious what you are doing, at the expense of legibility and convenience, the email header RFC2047 encoding should look vaguely familiar to many computer-literate users;
=?us-ascii?Q?5=2F5%=3D0?=
- There is also a separate encoding for file names etc in RFC2231 but it's probably more complex than you like.
- Many programming languages allow a notation like
\uFEDC
but the backslash is clearly cumbersome for other reasons. This is obviously restricted to Unicode strings (so you can't encode arbitrary sequences of bytes like you could with e.g. URL encoding like %88%88%88
)
For your own ad-hoc convention, perhaps at least choose symbolic names which are used by other encodings, too; !solidus!
for forward slash is obscure, but gets some support from various Unicode libraries etc (though !slash!
would probably also work, as that is a synonym in many contexts); Unicode calls backslash REVERSE SOLIDUS but !backslash!
could also work, and is a known synonym (see e.g. https://www.fileformat.info/info/unicode/char/5c/index.htm)