Magyar szöveg Rustban: byte, char, grapheme és Unicode-normalizálás

A „hossz” üzleti döntés is

Egy regisztrációs űrlapon a név legfeljebb húsz karakter lehet. Ez egyszerű követelménynek hangzik, amíg meg nem kérdezzük, mit számol a rendszer: byte-ot, Unicode skalárértéket vagy a felhasználó által egy jelnek érzékelt egységet? Egy adatbázis- vagy hálózati korlát byte-okban is értelmes lehet. A képernyőn megjelenő név rövidítésénél viszont más szempont számít.

Rustban a String UTF-8 szöveget tárol. A len() byte-okat számol, a chars() Unicode skalárértékeken halad. A String dokumentációja és a str műveletei részletezik a reprezentációt. Ezt a két számot már egy rövid magyar szóval is megkülönböztethetjük.

fn main() {
    let nev = "Őrs";
    assert_eq!(nev.len(), 4);
    assert_eq!(nev.chars().count(), 3);
    assert_eq!(nev.get(..1), None);
    assert_eq!(nev.get(..2), Some("Ő"));
}

Az első byte levágása az Ő közepére esne. A get ezért None eredményt ad. Ez jobb kiindulás felhasználói bemenet feldolgozásához, mint az indexelésből eredő panic. Ha a tulajdonjog és a kölcsönzött szöveg még új, előbb a referenciák leckét nézd át, a tesztelési parancsokat pedig a Cargo leckében találod.

Egy látható jel több skalárértékből is állhat

A char még nem feltétlenül egy megjelenített betű. Az é lehet egyetlen előre összeállított kódpont, vagy egy e és egy külön kombináló ékezet. Ezért a szöveg véletlenszerű skalárérték-határon történő rövidítése is furcsa kijelzést eredményezhet. A unicode-segmentation könyvtár grapheme-határokon tud végighaladni.

A cikk kísérő projektje egy elso_jelek függvényben a grapheme-ekből választ prefixet. Nulla kérésre üres szöveget ad vissza, a túl hosszú kérés az egész eredetit adja. A tesztek kiterjednek a kombináló ékezetre és egy több kódpontból álló emoji-szekvenciára is. Ez a függvény felhasználói felülethez hasznos modell; protokollmező byte-korlátját továbbra is byte-ban kell ellenőrizni.

Normalizálás keresés és összehasonlítás előtt

Két azonosnak látszó szöveg byte-sorozata eltérhet. A unicode-normalization dokumentációja bemutatja a normalizálási formákat. Az NFC hasznos egységes tárolási vagy összehasonlítási döntés lehet, de nem old meg minden keresési problémát: nem általános ékezeteltávolítás, és nem a magyar rendezési szabályok megvalósítása.

Ne írd át észrevétlenül a felhasználó eredeti nevét csak azért, mert a keresőhöz más alakot készítesz. Őrizd meg a megjelenítendő értéket, és külön állíts elő keresési kulcsot. Egy jogosultsági azonosítónál vagy fájlnévnél további, a feladatra szabott szabályok is szükségesek. Az, hogy két karakter hasonlóan néz ki, önmagában nem teszi őket biztonságosan felcserélhetővé.

Ellenőrizd a határokat is

A mintaprojekt tesztje nem pusztán azt ellenőrzi, hogy a függvény „működik” a Réka névvel. Van üres szöveg, nulla limit, túl nagy limit, előre összeállított ékezet, kombináló jel és összetett emoji is. A normalizálási próba összehasonlítja az összeállított és a bontott é változatát, majd azt is ellenőrzi, hogy a feldolgozás megismétlése nem változtat az eredményen.

Az ellenőrzési környezet Rust 1.97.1, edition 2024. A kísérő projekt pontos függőségeit a Cargo.toml és a Cargo.lock rögzíti. A grapheme-szegmentálás nem betűszélesség-mérés: egy termináloszlop, egy betűtípus és egy többjegyű magyar betű külön kérdés. A követelményben ezért mindig nevezd meg, milyen egységre és milyen megjelenítésre vonatkozik a korlát.