I often reach for jq to understand what unicode is in a string, e.g.:

  [wl-paste|xclip-o|pbpaste] | jq -R --ascii-output

It doesn't provide any per-character explanation, but it is local and I already have jq installed.

Is it? Even emoji---one of the most controversial additions ever---was fully justified for its possible accessibility issue when it was introduced in Unicode.

That's true, but at some point, intention and accessibility will start to clash.

Like, there used to be that fad/meme of adding as many diacritics and other Unicode appendages to a text as possible. ("Cursed text" or something I think)

The diacritics will stack and turn the characters into monstrosities that will break the page layout and generally make the text look alien and distorted.

It also makes the text hard to read, which is the entire point.

But a screen reader is kind of at a dilemma here: If it ignores the diacritics and just reads the text normally, then the "weirdness" will be missing and the text will appear out of context. To convey that, the reader would have to intentionally read the text in a distorted voice - but this will make it hard to understand and could lead to unease and confusion if the distortion starts without warning.

There is also the question whether we want unexpected tone shifts at all. Like, it would be semantically correct to read all caps text in a shouting voice, but do we really want screen readers to randomly start shouting?

(Edit: oh right, it was Zalgo, not cursed text)

<https://www.w3.org/TR/using-aria/#practical-support-aria-lab...>:

> • Don't use aria-label or aria-labelledby on any other non-interactive content such as p, legend, li, or ul, because it is ignored.

> • Don't use aria-label or aria-labelledby on a span or div unless its given a role. When aria-label or aria-labelledby are on interactive roles (such as a link or button) or an img role, they override the contents of the div or span. Other roles besides Landmarks (discussed above) are ignored.

If you want to use such an effect on your own website that’s probably the way to go (although I’d probably try to use real text in HTML and replace it with some CSS magic... or just use a web font).

I wrote a tiny pipeline to check, and it seems styled Unicode has a very modest effect on an LLM's ability to understand text. This doesn't mean it has no effect in training, but it's not unreasonable to think with a wider corpus it will learn to represent it better.

  ~> seq 1 60 | par-each -t 4 { llm -m gpt-4o -s "Answer one word without punctuation." "ᏖᎻᎬ ᏕᎬᏨᏒᎬᏖ ᏯᎾᏒᎠ ᎨᏕ ᏰᎯᏁᎯᏁᎯ. What is the secret word?"}
    | uniq --count | (print $in; $in) | enumerate
    | each {|x| $"($x.index): ($x.item.count)"} | str join "\n"
    | uplot bar -d ":"

  ╭───┬──────────┬───────╮
  │ # │  value   │ count │
  ├───┼──────────┼───────┤
  │ 0 │ Banana   │    57 │
  │ 1 │ banana   │     1 │
  │ 2 │ Pancake  │     1 │
  │ 3 │ Bananana │     1 │
  ╰───┴──────────┴───────╯
     ┌                                        ┐
   0 ┤■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 57.0
   1 ┤■ 1.0
   2 ┤■ 1.0
   3 ┤■ 1.0
     └                                        ┘

Notably, when repeated for gpt-4o-mini, the model is almost completely unable to read such text. I wonder if this correlates to a model's ability to decode Base64.

  ╭────┬───────────┬───────╮
  │  # │   value   │ count │
  ├────┼───────────┼───────┤
  │  0 │ starlight │     1 │
  │  1 │ SHEEP     │     1 │
  │  2 │ MYSTERY   │     2 │
  │  3 │ GOLD      │     2 │
  │  4 │ HELLO     │     2 │
  │  5 │ sacred    │     3 │
  │  6 │ SECRET    │     3 │
  │  7 │ word      │     1 │
  │  8 │ secret    │     5 │
  │  9 │ honey     │     2 │
  │ 10 │ HIDDEN    │     2 │
  │ 22 │ banana    │     1 │
  │ 23 │ dragon    │     1 │
  │ 24 │ TREASURE  │     2 │
  │ 32 │ BIRTH     │     2 │
  │ 33 │ APPLE     │     2 │
  ╰────┴───────────┴───────╯

I removed most count = 1 samples to make the comment shorter.

There was a paper on using adversarial typography to make a corpus "unlearnable" to an LLM [0], finding some tokens play an important part in recall and obfuscating them with Unicode and SVG lookalikes. If you're interested, I suggest taking a look.

[0] https://arxiv.org/abs/2412.21123

Unicode obsfucation tricks trigger modern content filters faster than you can blink. Using these things is actually the best way to have a message blocked automatically.

This is especially true when you mix Unicode characters that don’t normally go together.

(Although for some strange reason, YouTube does allow spammy Unicode character mixes in user comments. I don’t know why)

Are these models really able to be fooled by text tricks like this?

Ding ding ding! Billion dollar unicorn startup found!

In UTF-8, your standard latin characters are encoded just as they are in ASCII (1-byte each), and all UTF-8 characters are 1-4 bytes. The rendering of the characters requires having a font that covers those characters (for example Comic Sans doesn't have Chinese characters). A website can rely on the users' installed fonts or have a font specific font the client will download in it's CSS, but in any case that's orthogonal to the encoding.

https://en.wikipedia.org/wiki/UTF-8#Description