Hacker News Reader

Comment by Aozora7 | Hacker News Reader

My favorite unicode character is zero width space. One of its funniest properties is that it's not a whitespace.

Also, some programming languages treat it as a valid identifier.

> My favorite unicode character is zero width space. One of its funniest properties is that it's not a whitespace.

My editor is configured to never show any character (except the one and proper newline) at less than the full-width of a regular character (in the monospace font I'm using ofc).

And if it's not a visible ASCII char, not only it's always shown at least at full-width, it's also shown as bold magenta on a black background. As the non visibe zero-width is empty, it shows as full-width on a black background.

Sticks out like a sore thumb.

Would you mind sharing your editor and magic recipe?

That's new

> For example, U+200B ZERO WIDTH SPACE was originally classified as a space character (General_Category=Zs), but it was reclassified as a Format character (General_Category=Cf) to clearly distinguish it from space characters in its function as a format control for line breaking.

Ha! Yes I discovered that this is true in C as part of my IOCCC entry:

https://github.com/ioccc-src/winner/blob/master/2025/ncw3/pr...

Braille Pattern Blank "⠀" (U+2800) is another one of my favourites, since it's also not considered whitespace, but it looks like it. It can actually be fairly helpful for forms that won't let you leave any field blank, since it bypasses most whitespace checks.

Indeed, the ossification of this old absurdity can be helpful, also for visual alignment within names.

This prompted me to finally dig a bit and find the official reference why they didn't fix the bug despite a plea from some Braille council

https://www.unicode.org/L2/L2025/25183-utc184-properties-rec...

> It was found that many publications that use Unicode Braille characters use U+2800 with a marking glyph. A marking space is not without precedent, consider U+1680 OGHAM SPACE MARK. However, in some cases, U+2800 is clearly used as a symbol, to indicate the presence of a space when describing a Braille sequence corresponding to a symbol or punctuation, similar to the use of ␣ (U+2423 OPEN BOX) to indicate the presence of a space. Especially in cases where it is used in a trailing position, as in the [UNE13] example, it is clear that it would be inappropriate for this symbol to disappear.

> Considering this usage as a marking symbol, together with concerns about changing the relatively stable—and often hardcoded—White_Space property (a property of only 25 code points, last changed in Unicode 6.3, when U+180E MONGOLIAN VOWEL SEPARATOR ceased to be a space), the PAG preferred a more targeted change.

This doesn't seem that unreasonable.

but still unreasonable. In the presence of issues for each of the two options, you pick the correct one unless you have rather strong reasons, which they don't:

> U+2800 is clearly used as a symbol, to indicate the presence of a space when describing a Braille sequence corresponding to a symbol or punctuation, similar to the use of ␣

Why is that? Have you perhaps forgotten to add "␣" equivalent for Braille? So maybe do that instead so people can us a mark to mark something?

> Especially in cases where it is used in a trailing position, as in the [UNE13] example, it is clear that it would be inappropriate for this symbol to disappear

Nothing disappears in the cited example, the line is very short , how is it possible to reject a fix when you can't even find an example of that fix breaking someone?

> last changed in

and this approach is why we can't have nice things and generations of computer users continue to suffer due to some dumb oversight decades ago. And it's not like we get a payoff of great stability, not, that standard is uber complicated and changes all the time

Over a decade ago this caused a quite bit of head scratching for me as to why in our C# application a certificate's thumbprint was not matching with that in our App.config file, even though the characters were seemingly identical.

Turns out Windows Certificate Manager had an "easter egg" that if you copied a certificate's thumbprint to your clipboard it included a zero width space with it.

Very, very subtle and actually very hard to spot without doing a debug or something.

There is a Stack Overflow of exactly this issue: https://stackoverflow.com/questions/11115511/how-to-find-cer...

At some point (Windows 10?) Microsoft "fixed" the Certificate Manager to stop doing this.

I use it for sites like Facebook where I want to type :) without it changing to the terrible `U+1F642 SLIGHTLY SMILING FACE` [1]. I wouldn't really mind if it were the `U+1F60A SMILING FACE WITH SMILING EYES` [2], but the first one is so laughably terrible, as if I'd really want to send an emoji to communicate a disingenuous, pained smile as a default. Some platforms let you backslash-escape sequences so they don't get turned to emoji, like \:), but for Facebook and the like, putting a ZWS in between the letters stops the conversion.

Though if your emoji is at the end of a line, it'll potentially break your emoji between the two lines. since That's what a ZWS is for, after all.

1. https://util.unicode.org/UnicodeJsps/character.jsp?a=%F0%9F%...

2. https://util.unicode.org/UnicodeJsps/character.jsp?a=1F60A&B...

My favorite use for it is putting it into mandatory surname fields, which sometimes works.

Try using the zero-width non-joiner instead (U+200C).

I look like U+1F642 when I smile genuinely

Reply on news.ycombinator.com