Unicode Blog
blog.unicode.org · Company blog · on HN since 2015
The Unicode Consortium's official blog announcing new Unicode versions, emoji releases, flag emoji policy, and tools like ICU4X.
What HN saysHN links it for Unicode release announcements and mainly for the 2022 post saying the Consortium accepts no new flag emoji proposals.
55HN people shared it
16linked it in comments
51stories submitted
269story points
1 year agolast shared
2015people per year2026
Most-shared posts
- 1The Past and Future of Flag Emoji10 people · 7 points · first shared 2022 · discussion on HN
- 2New Japanese unicode character needs to be implemented worldwide5 people · 10 points · first shared 2018 · discussion on HN
- 3The Unicode Standard, Version 15.04 people · 19 points · first shared 2022 · 1 comments on HN
- 4Emoji 12.0 released3 people · 4 points · first shared 2019 · discussion on HN
- 5Unicode Standard, Version 12.02 people · 67 points · first shared 2019 · 55 comments on HN
- 6Announcing the Unicode Standard, Version 11.02 people · 26 points · first shared 2018 · 1 comments on HN
- 7ICU4X 1.0 Released – New Internationalization Library from Unicode2 people · 19 points · first shared 2022 · discussion on HN
- 8Unicode 17.0 Release Announcement2 people · 3 points · first shared 2025 · 1 comments on HN
- 9Unicode Standard 15.12 people · 2 points · first shared 2023 · discussion on HN
- 10The Unicode Standard, Version 16.01 people · 39 points · first shared 2024 · 1 comments on HN
- 11The Unicode Standard, Version 14.01 people · 11 points · first shared 2021 · discussion on HN
- 12Announcing the Unicode Standard, Version 8.01 people · 7 points · first shared 2015 · discussion on HN
- 13The Unicode Blog: ICU Joins the Unicode Consortium1 people · 4 points · first shared 2016 · 1 comments on HN
- 14Unicode Version 12.1 Released in Support of the Reiwa Era1 people · 4 points · first shared 2019 · discussion on HN
- 15Unicode Version 8.0 – Complete Text of the Core Specification Published1 people · 3 points · first shared 2015 · discussion on HN
What HN people wrote when they linked it
Rendello · 2025-09-11
As of 2022 the Unicode Consortium will not accept proposals for any new flags. Moving forward, anything with an ISO 3166-1 code will automatically get a flag. The Iraq Kurdistan subdivision mentioned below has a 3166-2 subcode, so doesn't automatically get a flag pushed though. They could've worded it less confusingly, but the rest of the article is quite thorough.
> As a recent example, Kurdistan (a subdivision of Iraq) became an official subdivision in ISO 3166-2 (IQ-KR) on May 3, 2021. The corresponding Unicode subdivision code (iqkr) is slated for release in CLDR v41 on Apr 6, 2022. At that point the flag for Kurdistan will officially be valid — any platform, app, or font could support it. But that doesn’t mean it automatically gets in the queue for everyone’s phone. Only countries with ISO 3166-1 region codes are automatically recommended and require no proposal to move forward.
https://blog.unicode.org/2022/03/the-past-and-future-of-flag-emoji.htm…
gred · 2025-09-12
> My understanding is that codepoints beyond 65,536 are only used for languages that are no longer in use, and emojis
This week's Unicode 17 announcement [1] mentions that of the ~160k existing codepoints, over 100k are CJK codepoints, so I don't think this can be true...
[1] https://blog.unicode.org/2025/09/unicode-170-release-announcement.html
Someone · 2025-02-04
> Unicode's mission is to be able to represent all written text. Once you decide that flags should be part of that you kind of have to include all of them.
Unicode has decided flags shouldn’t be part of Unicode.
There are a few flag emoji that got included before they reached that decision and there are “regional indicator symbols” that often get displayed as flags, but that’s it. They won’t, for example, include flags of cantons of Liechtenstein.
See https://blog.unicode.org/2022/03/the-past-and-future-of-flag-emoji.htm…
Esras · 2024-09-14
I was specifically referring to this: https://blog.unicode.org/2022/03/the-past-and-future-of-flag-emoji.htm…
voxadam · 2023-07-15
It looks like, at least for the time being, the Unicode Consortium isn't accepting any new flag emoji.[0] While I don't necessarily support their position I can understand it. The amount of international pressure to support or oppose the recognition of some flags (e.g. Republic of China AKA Taiwan, Tibet, Crimea, Kosovo, Abkhazia etc.) is likely substantial.
[0] https://blog.unicode.org/2022/03/the-past-and-future-of-flag-emoji.htm…
capableweb · 2023-07-15
There is a precedent (https://blog.unicode.org/2022/03/the-past-and-future-of-flag-emoji.htm… to stop accepting new emojis in certain categories, so the hope is not fully out that that can happen to other sections. Maybe at one point they say "We won't be accepting Emoji proposals regarding sports anymore, unless they're listed by X entity or in the Plympics", or something like that.
Thing123456 · 2023-02-26
Here's the blog post for the Unicode 15 release: https://blog.unicode.org/2022/09/announcing-unicode-standard-version-1…
A tiny portion consists of "fun fashionable clip art." The vast majority of the changes are new scripts and symbols that allow people to correctly input existing texts.
nindalf · 2023-02-03
> It is far easier to write bindings from an existing C API to a managed implementation than write, audit and maintain a whole new stack from scratch.
I’d agree, if rustls wasn’t already written, audited and maintained. And there are other examples as well. The internationalisation libraries Icu4c and Icu4j exist, but the multi-language, cross-platform library Icu4x is written in Rust. Read the announcement post on the Unicode blog (http://blog.unicode.org/2022/09/announcing-icu4x-10.html?m=1) - security is only one of the reasons they chose to write it in Rust. Binary size, memory usage, high performance. Also compiles to wasm.
Your comment implies that people rewrite in Rust for security alone. But there are so many other benefits to doing so.
pacaro · 2022-09-14
https://blog.unicode.org/2022/09/announcing-unicode-standard-version-1…
Seems like it might be a better link
Animats · 2021-04-14
let s = "hello world".to_string();
for ch in s.chars() {
print!({},ch);
}
will iterate through a string character by character. That's the most common use of the "char" type - one at a a time, not arrays of them.
Although the proper grapheme form is:
use unicode_segmentation::UnicodeSegmentation; // 1.7.1
let s = "hello world".to_string();
for gr in UnicodeSegmentation::graphemes(s.as_str(), true) {
print!("{}", gr)
}
This will handle accented characters and emoji modifiers.
A line break in the middle of a grapheme will mess up output.
By the way, open season for proposing new emoji starts tomorrow.[1]
[1] http://blog.unicode.org/2020/09/emoji-150-submissions-re-open-april-2.…
gpvos · 2019-04-23
There will also be a new Unicode character: http://blog.unicode.org/2018/09/new-japanese-era.html
anoncake · 2019-04-12
> - Emacs is now compliant with the latest version 11.0 of the Unicode Standard.
http://blog.unicode.org/2019/03/announcing-unicode-standard-version-12…
Gaelan · 2019-04-01
http://blog.unicode.org/2018/09/new-japanese-era.html was posted here yesterday, but the short answer is that the era can be referred to using two existing characters (for the current era: 平成) or with one new combined one (㍻). Wiki is using the former, so it doesn't need software support.
fenomas · 2019-04-01
The new name just uses standard characters, but what you're probably referring to is the fact that Unicode 12.1 will have a character for the two of them compressed into one glyph.
Details: http://blog.unicode.org/2018/09/new-japanese-era.html
Compressed glyphs like that are sometimes used on paperwork and whatnot, but everyday usage just uses the standard characters.
_old_dude_ · 2019-03-30
One issue is that most programming languages links their version to a particular unicode version, by example, .NET 4 supports Unicode 5.1 while .NET 4.5 supports Unicode 6, etc.
The new Era will be soon supported by Unicode 12.1 [1].
For older version of .Net (or Java) you also need to support the new Era without supporting the whole Unicode 12.1 spec, introducing a non backward compatibility behavior because the new code point U+32FF has now a different meaning.
Currently we have already added tests for the new code point in all our supported applications and are ready to update them using the same channel as a security issue.
[1] http://blog.unicode.org/2018/09/new-japanese-era.html