Регистр — это таблицы

Обработка через руны и таблицы

Обрабатывать текст нужно рунами — функция принимает руну и возвращает руну:

import (
    "strings"
    "unicode"
)

func upper(s string) string {
    var b strings.Builder
    for _, r := range s {
        b.WriteRune(unicode.ToUpper(r))
    }
    return b.String()
}

unicode.ToUpper('й') вернёт 'Й', и для кириллицы этого достаточно. strings.Builder нужен потому, что итоговый размер заранее неизвестен, а WriteRune сам закодирует руну обратно в UTF-8. Обычно хватает готового strings.ToUpper, но ручная версия показывает механизм: текст обрабатывается рунами, а не байтами.

Граница простого сопоставления

Одна оговорка: unicode.ToUpper делает простое сопоставление, руна в руну. Полного преобразования регистра, где у «ß» заглавная форма — две буквы «SS», в стандартной библиотеке нет:

Раскрытие в несколько символов умеет golang.org/x/text/cases — cases.Upper(language.Und).String("straße") даёт «STRASSE». В повседневном коде до него доходит редко.

Граница понятия «символ»

Руна — это code point, и для большинства задач это правильная единица: поиск, сравнение, разбиение по «буквам». Но видимый пользователем символ не всегда совпадает с code point. «е́» — это «е» плюс отдельный combining-акцент: два code point'а, а человек видит один значок. Такой видимый символ называется grapheme cluster, и готового обхода по ним в стандартной библиотеке нет — обычно берут github.com/rivo/uniseg. Рядом живёт golang.org/x/text/unicode/norm для нормализации: «е» с combining-акцентом и готовый символ «é» (U+00E9) выглядят одинаково, но как строки не равны, и нормализация приводит их к одной форме.

Для уроков и 99% рабочего кода рун достаточно; просто держи в голове, что «символ» в Go строго означает «code point», и когда понадобится полноценная текстовая сегментация, она будет строиться поверх рун, а не вместо них. Самый яркий пример того, что руны — это ещё не видимые символы, — составные эмодзи: о них следующий урок.