Unique Strings and Unicode
The account was created in June 2019 but the first commit dates back to 2018. One day I might blog a bit about how it works under the hood, but today I’d like to talk about a small bug that made me crazy for a while.
The bot has been running stable for a couple of years without me touching the code at all. But recently, I noticed that sometimes it would tweet some very common words as if they were new, like “économie” or “opéra”. I deleted them when I saw them, but I didn’t understand why it happened.
I initially attributed the bug to an issue with the search engine: when the bot sees a word it never saw before, it uses Le Monde’s internal search engine to verify that this word indeed appears in a single article. Around the end of 2019,Le Monde ditched their previous search engine, which was slow but exact, in favor of a Qwant-based one which is fast but inexact: it doesn’t respect your query (it may or may not autocorrect your query and there’s no way to prevent it from doing so), it’s not accurate (no result may or may not mean that there is no match) and it’s not stable (do the same query twice and you can get different results; even by a large order of magnitude). In French, we would say this is “de la merde”.
Anyway, I thought it was an issue where maybe using the internal search engine would give a single result instead of multiple ones, but this doesn’t make sense: the bot doesn’t check every single word with the search engine, but only those it thinks are unique. Since it has already scrapped virtually all articles from the newspaper, there’s no way it would consider “économie” as a new word.
Today, I decided to tackle the issue.
First, I searched in the database for a recent example, and I got “vaccinées” (the feminin plural form
of “vaccinated”). This is a very old word; it first appeared in Le Monde in 1946 and we saw it more than
1.7k times since then. The word even showed up twice in the database, despite a
UNIQUE constraint on the field:
I inspected the strings and noticed they were encoded differently, although they were both in UTF-8. The difference was
on the “é” character: it turns out that both are different: one is represented as the Unicode character
LATIN SMALL LETTER E WITH ACUTE while the other is a combination of
LATIN SMALL LETTER E and
COMBINING ACUTE ACCENT. They both render exactly the same on screen, which makes this issue so hard to detect by a
The fix was to normalize the text before interpreting its words. I did it in Python using
There are multiple normalization forms, and I chose
NFKC: normalize equivalent characters to their canonical one, and
compose all combining characters such that the non-combined and the combined versions become the same.
After fixing the code, I needed to fix the database to fix already-parsed words. In PostgreSQL, we can use
SIMILAR TO to search for strings matching a certain characters range: in my case, the “Combining Diacritical Marks”,
I use Peewee to interact with Postgres from Python. While it doesn’t support
SIMILAR TO out of the box, it’s
simple to use a custom expression:
Unfortunately this feature is not available in SQLite, the database I use to run my integration tests, and so I had to
adapt the code a little bit: first use
SqliteExtDatabase instead of
SqliteDatabase to get support for
REGEXP, and then use the
I was then able to run a quick function to normalize the ~1k words affected by the issue.
To conclude, it seemed a very weird issue at first but in the end it allowed me to learn a few things about Unicode, Postgres, and Python’s fantastic standard library.