HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
rivo
uniseg
Go2021–2025
rivo / uniseg

uniseg

Unicode Text Segmentation, Word Wrapping, and String Width Calculation in Go

3Distinct people
3Mentions
0Explicit recommenders
742GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Unicode Text Segmentation, Word Wrapping, and String Width Calculation in Go

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year3 dated mentions

Observed mentions: 2021-03-23 13:48:36 UTC to 2025-12-02 08:30:26 UTC.

012021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101

What Hacker News says

3 sources
Recently I compared Unicode handling in Rust, Swift and Go for my own curiosity. Sharing it here, in the hope someone finds it useful: Get bytes representing utf8-encoding of string Only ASCII characters map 1:1 to their utf8-encoding. Everything else expands to multiple bytes. https://en.wikipedia.org/wiki/UTF-8#Description Rust line.bytes() Swift line.utf8 Go line // slice of bytes // assuming line is valid utf8, which is not enforced Get Unicode codepoints of string Most characters and emojis consist of a single codepoint. Some are made up of multiple codepoints. If it isn't guaranteed that only this limited set of characters is used, this is not a safe way to iterate over what users would consider characters. Codepoints are 4 bytes, usually stored internally as u32 or i32 but with different API for the programmer.
Read the rest
Rust line.chars() // https://doc.rust-lang.org/std/primitive.char.html Swift line.unicodeScalars // https://developer.apple.com/documentation/swift/unicode/scalar Go []rune(line) // or iterate with range for index, runeValue := range line { fmt.Printf("%#U starts at byte position %d\n", runeValue, index) } // https://go.dev/blog/strings Get extended grapheme clusters of string What a reader would actually consider to be a character. E.g, this character consists of two codepoints but is one grapheme cluster: a̐ Rust use unicode_segmentation::UnicodeSegmentation; line.graphemes(true) Swift for ch in line { print(ch) } // This is the default view - just iterate over string (or map, filter etc.) // In Swift, a `Character` is a grapheme cluster. // https://developer.apple.com/documentation/swift/string#Accessing-String-Elements Go // https://pkg.go.dev/github.com/rivo/uniseg Normalize strings A character like é can be represented in different forms: either as one codepoint (U+00e9) or as a combination of e + ◌́ (U+0065, U+0301). Some characters are defined multiple times with different names: Ω can be found as "greek capital letter omega" (U+03a9) and as "ohm sign" (U+2126). Normalization converts a string to use only one of those forms and is required to consistently compare strings. Rust use unicode_normalization::UnicodeNormalization; line.nfc() line.nfd() Swift line.precomposedStringWithCanonicalMapping line.decomposedStringWithCanonicalMapping Go // https://pkg.go.dev/golang.org/x/text/unicode/norm Remove diacritics This can be considered a destructive form of normalization, which can be useful in some cases. Rust use diacritics::remove_diacritics; remove_diacritics(line) Swift line.applyingTransform(.stripDiacritics, reverse: false) // and others to transform between alphabets etc. // https://developer.apple.com/documentation/Foundation/StringTransform
In Dark Corners of Unicode (2015)
I spent quite a bit of time coming up with an algorithm that gives me the correct width for any Unicode character, including emojis [1]. The reality is much more complicated than what wcwidth does and using the East Asian Width attribute will give wrong results, as outlined in the article. Unfortunately, since a lot of terminals simply use wcwidth, you often have to use that same flawed algorithm in your application to make it work in those terminals. [1] https://pkg.go.dev/github.com/rivo/uniseg#hdr-Monospace_Widt...
In Terminal Support for Emoji

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.