Live data from Hacker News

How to chop off bytes of an UTF-8 string to fit into a small slot and look nice

domm.plix.at

31–40 of 66 posts

Re: How to chop off bytes of an UTF-8 string to fit into a small slot and look nice

#31
MARC can do all kinds of crazy things. I used to work with folks who had been hacking on MARC since the 1960s. If I remember correctly, at one point it got punched onto dangling chad cards (and of course was used to print the cards in the card catalog in the library).

> The real problem is that USMARC uses an int with 4 digits to store the size of a field, followed by 5 digits for the offset.

A colleague told me they used to exploit this "feature" to leave hidden messages in MARC records between fields.

Re: How to chop off bytes of an UTF-8 string to fit into a small slot and look nice

#32
post #19

Earlier quoted context omitted.

The emoji "" can't be normalized further -- it's a "" followed by a "". If you just split on code points rather than grapheme clusters, even after normalizing, your naïve truncation algorithm will have accidentally changed the skin colors of emoji. Or turned the flag of Norway into an "". Or turned the rainbow flag into a white flag . EDIT: oh lord Hacker News strips emoji. You get the idea even though HN ruined the…

HN is not broken, it's working as designed.

[poop]

Re: How to chop off bytes of an UTF-8 string to fit into a small slot and look nice

#33
Fun fact: part of why TOML 1.1 has taken so long to land is because of open questions around unicode key normalization. That in itself sounds dry and boring, but the discussion threads are anything but.

https://github.com/toml-lang/toml/issues/994

https://github.com/toml-lang/toml/issues/966

https://github.com/toml-lang/toml/issues/989

https://github.com/toml-lang/toml/pull/979

Re: How to chop off bytes of an UTF-8 string to fit into a small slot and look nice

#34

Earlier quoted context omitted.

To avoid this and a bunch of other confusion, when accepting user input I recommend normalizing it to the composed form before writing to a DB or file. While unicode-aware tools and software should handle either form just fine, you probably want to avoid that there's something in the pipeline somewhere that treats the decomposed and composed form of the same string as different.

Not all grapheme clusters have composed forms so normalization doesn't actually gain you anything here.

> Not all grapheme clusters have composed forms so normalization doesn't actually gain you anything here.

Just because the worst case can't improve doesn't mean that making the average case better is worthless.

Re: How to chop off bytes of an UTF-8 string to fit into a small slot and look nice

#35

Don't do this. Use a language (like C#) or library (like libunistring) that can do grapheme cluster segmentation. In .NET it's StringInfo.GetTextElementEnumerator(). In libunistring it's u8_grapheme_breaks(). In ICU4C it's icu::BreakIterator::createCharacterInstance(). In Ruby it's each_grapheme_cluster(). Other ecosystems with rich Unicode support should have similar functionality.

"I had a problem, and here's my working solution for my specific case."

-"Don't do this. Instead use a completely different programming language."

Re: How to chop off bytes of an UTF-8 string to fit into a small slot and look nice

#36

Don't do this. Use a language (like C#) or library (like libunistring) that can do grapheme cluster segmentation. In .NET it's StringInfo.GetTextElementEnumerator(). In libunistring it's u8_grapheme_breaks(). In ICU4C it's icu::BreakIterator::createCharacterInstance(). In Ruby it's each_grapheme_cluster(). Other ecosystems with rich Unicode support should have similar functionality.

That’s fine unless you are a language or library creator in which case knowing how to do it properly can’t be deferred to someone else. Perhaps porting someone else’s correct implementation is good but someone somewhere has to implement this. If they don’t share their knowledge this will always be esoteric knowledge locked away unless those who do that kind of work share their knowledge and experience. Most of us are not those people, but some are.

Re: How to chop off bytes of an UTF-8 string to fit into a small slot and look nice

#37

MARC can do all kinds of crazy things. I used to work with folks who had been hacking on MARC since the 1960s. If I remember correctly, at one point it got punched onto dangling chad cards (and of course was used to print the cards in the card catalog in the library). > The real problem is that USMARC uses an int with 4 digits to store the size of a field, followed by 5 digits for the offset. A colleague told me they…

Well, until some system comes along that relies on the directory for the tags only and just splits the record using the separator characters. Which is a valid enough approach to either work around bad encoding or if your record is on something other than a magnetic band and you don't need to know what exact offset to move to.

Hidden is a very relative term there.

Re: How to chop off bytes of an UTF-8 string to fit into a small slot and look nice

#38

Don't do this. Use a language (like C#) or library (like libunistring) that can do grapheme cluster segmentation. In .NET it's StringInfo.GetTextElementEnumerator(). In libunistring it's u8_grapheme_breaks(). In ICU4C it's icu::BreakIterator::createCharacterInstance(). In Ruby it's each_grapheme_cluster(). Other ecosystems with rich Unicode support should have similar functionality.

I pasted your comment here into GPT-4o and asked for the Python equivalent, it suggested this which seems to work well:

    import regex as re
    
    def grapheme_clusters(text):
        # \X is the regex pattern that matches a grapheme cluster
        pattern = re.compile(r'\X')
        return [
            match.group(0)
            for match in
            pattern.finditer(text)
        ]
https://chatgpt.com/share/481c9c94-0431-4fcb-82aa-a44a4f3c21...

Re: How to chop off bytes of an UTF-8 string to fit into a small slot and look nice

#39
post #8

Earlier quoted context omitted.

MARCXML is just a new format to encode what's the vast majority of the MARC 21 standard (or for that matter any other MARC variety). BIBFRAME is gonna make it obsolete Any Day Now! ("any day now" in this sector means that librarians have been talking about it for two decades and in about two decades something might actually happen)

I do wish the community had leaned into the MODS direction vs going over to RDF.

Yeah I don't know what the sell is there... throw away the fidelity of your data when WEMI/FRBR/BIBFRAME/semantic web is coming any ~year~ decade now, soon (lol), while re-learning everything, definitely going out to tender because your current system won't do it and shift your processes and integrations. All so you can end up halfway to DC, yeah no.

The reason libraries don't do cataloguing any longer anywhere near as much hasn't got much to do with MARC 21 being hard.

Re: How to chop off bytes of an UTF-8 string to fit into a small slot and look nice

#40
post #36

Don't do this. Use a language (like C#) or library (like libunistring) that can do grapheme cluster segmentation. In .NET it's StringInfo.GetTextElementEnumerator(). In libunistring it's u8_grapheme_breaks(). In ICU4C it's icu::BreakIterator::createCharacterInstance(). In Ruby it's each_grapheme_cluster(). Other ecosystems with rich Unicode support should have similar functionality.

That’s fine unless you are a language or library creator in which case knowing how to do it properly can’t be deferred to someone else. Perhaps porting someone else’s correct implementation is good but someone somewhere has to implement this. If they don’t share their knowledge this will always be esoteric knowledge locked away unless those who do that kind of work share their knowledge and experience. Most of us are…

Hi, I'm one of the people who are library authors in this area.

This article is very specific to Perl, and the way it does so is also subject to question - it does not look efficient.

You will be better off by reading excellent wikipedia page on UTF-8: https://en.wikipedia.org/wiki/UTF-8

Now, extended grapheme cluster enumeration is much more complex than finding the next non-continuation byte (or counting such), but to perform those correctly you would ultimately end up reading the official spec at unicode.org and perusing reference implementations like ICU (which is painful to read) or from standard library/popular packages for Rust/Java/C#/Swift (the decent ones I'm aware of, do not look at C++).

Post reply on HN