Строки, руны и байты: почему len не считает символы, а подстрока держит мегабайты

Что здесь на самом деле спрашивают

Тема выглядит разминочной, и в этом ловушка: вопросы почти всегда идут парами, где второй проверяет, понята ли причина первого.

1. «Что вернёт len(s) для строки с иероглифами?» — и сразу: «а почему?»
2. «Что такое руна?» — и: «руна и символ — это одно и то же?»
3. «Почему строки неизменяемы?» — вопрос не про безопасность, а про подстроки.
4. «Сколько стоит s[2:5]?» — и: «что при этом остаётся в памяти?»
5. «Чем += в цикле плох?» — и: «а на трёх кусках тоже?»

Спина у темы одна, и её стоит проговорить вслух: строка — это заголовок над неизменяемым куском байтов. Неизменяемость делает подстроку бесплатной, бесплатная подстрока удерживает массив, а неизменяемость же делает склейку квадратичной. Три разных вопроса — одно свойство.

База: строка — это байты

Строка хранит текст, а память умеет хранить только числа. Значит, между текстом и памятью стоит договорённость: каким числом записывается какой знак. Такая договорённость называется кодировкой, и в Go она одна — UTF-8.

Устроена она неравномерно: частые знаки записываются одним байтом, остальные — двумя, тремя или четырьмя. Латинская буква занимает один байт, иероглиф — три, эмодзи — четыре. Номер, который кодировка присваивает знаку, называется кодовой точкой; в Go у него есть своё имя — руна.

Возьмём строку из трёх знаков разной длины — "A世🙂" — и пройдём с ней весь вход в тему.

Длина возвращает байты. Знаков три, а длина — восемь: один плюс три плюс четыре. Длина строки в Go — не число знаков, а место, которое текст занимает.

Обход идёт по знакам. for range по строке шагает по кодовым точкам и выдаёт «A», «世» и «🙂» — три шага, а не восемь. Но номер, который он выдаёт вместе со знаком, — это байтовое смещение начала знака: 0, 1 и 4.

Обращение по индексу даёт байт. s[0] — это не первый знак, а первый байт: 65, и он же оказывается целой буквой «A», потому что она однобайтовая. А s[1] — 228, и это лишь первая треть иероглифа: остальные две трети лежат в s[2] и s[3].

Вот и весь вход. Три ответа на вопрос «сколько тут всего» — восемь байтов, три знака, восемь позиций для индекса, — и ни один из них не «настоящее» число строки: правильный зависит от того, зачем спрашивают.

Этого уже достаточно, чтобы ответить на базовый вопрос собеседования: длина строки в Go считает байты, а не символы, потому что текст хранится в UTF-8, где знак занимает от одного до четырёх байтов. Всё дальнейшее — про то, где эта разница режет: почему руна всё ещё не равна видимому знаку, как срез строки разрубает знак пополам и что следует из того, из чего сделана сама строковая переменная.

Механизм 1: одна строка, три системы отсчёта

Ту же строку — "A世🙂" — урок проносит через все механизмы. Она выбрана так, чтобы покрыть все три длины UTF-8 сразу: латинская буква занимает один байт, иероглиф три, эмодзи четыре.

Это не педантизм. На чисто латинской строке ни одна ошибка этой темы не проявляется: len совпадает с числом символов, s[0] даёт первый символ, индексы range идут подряд. Ровно поэтому такие ошибки живут в коде до первого нелатинского ввода — и всплывают в проде, а не в тестах.

Прогон bench/gostring/practice.go печатает:

8        len(s) — байты
3        utf8.RuneCountInString(s) — руны
65       s[0] — байт, и он же целиком буква «A»
228      s[1] — байт, и он ПОЛОВИНА иероглифа
3        len([]rune(s))
0 1 4    байтовые смещения из range
1        len(string(s[0]))
2        len(string(s[1]))

Разберём то, что здесь важно, по трём пунктам.

len считает байты. Восемь против трёх — это одна и та же строка в двух системах отсчёта, и ни одна из них не «настоящая». Правильный ответ на вопрос «сколько тут символов» зависит от того, зачем спрашивают.

s[i] — это byte, а не символ. И вот пара, ради которой строка выбрана такой: s[0] даёт 65, и это действительно вся буква «A»; s[1] даёт 228, и это первый байт из трёх. Первый случай работает случайно — и потому маскирует второй.

Отсюда же две последние строки вывода. string(s[i]) не декодирует байт: это конвертация числа в руну с таким кодом. Из 65 выходит «A» длиной 1 байт — верно по совпадению. Из 228 выходит «ä» длиной 2 байта — символ, не имеющий к исходной строке никакого отношения.

range отдаёт байтовые смещения: 0 1 4, а не 0 1 2. Это прямо в спецификации:

Практическое следствие: индекс из range годится для нарезки строки (s[i:]), но не годится как номер символа. Счётчик символов заводят отдельной переменной.

Механизм 2: байты, руны и графемы — три разных числа

«Руна — это символ» — самое живучее упрощение темы, и его стоит разрушить сразу, пока оно не встроилось в решения. Прогон bench/gostring/internals.go:

Две средние строки — один и тот же знак на экране и разные числа рун. é существует в двух формах: готовой (U+00E9) и составной (e плюс комбинирующий акут U+0301). Значит, руна не равна символу, и счётчик рун отвечает на вопрос «сколько символов» верно только тогда, когда текст заведомо в готовой форме, — а текст из внешнего мира этого не гарантирует.

Последняя строка доводит различие до предела: восемнадцать байт, пять рун, один видимый знак. Пять рун — это три эмодзи и два соединителя нулевой ширины.

То, что человек называет символом, называется графемным кластером, и разбиения на кластеры в стандартной библиотеке нет вовсе. Это и есть содержательный ответ на собеседовании: «посчитать символы» в общем случае решается отдельным пакетом, а len и []rune отвечают на два других вопроса.

Три уровня стоит держать в голове именно как три:

байты      единица хранения          len(s)
руны       кодовые точки Unicode     utf8.RuneCountInString(s)
графемы    то, что видит человек     отдельный пакет

Механизм 3: нарезка режет по байтам

Индексы среза строки — байтовые, и это значит, что s[:n] с произвольным n способно разрубить последовательность UTF-8 пополам. Прогон:

Вторая строка — разрубленный иероглиф. Программа не упала и ничего не сообщила: строка в Go — последовательность произвольных байтов, и некорректный UTF-8 в ней законен.

Обратите внимание на счётчик рун в этой строке: он насчитал две руны там, где вторая не существует. Обход подставляет вместо каждого некорректного байта символ замены U+FFFD — то есть повреждение превращается не в ошибку, а в вопросительный знак в ромбике, который заметят пользователи.

Практический вывод узкий и частый: обрезать текст по длине байтовым срезом нельзя. Превью на сто символов, отрезанное как s[:100], рано или поздно разрубит символ. Резать надо по границам, которые даёт range, — он идёт ровно по началам рун.

Механизм 4: что лежит в переменной — и почему подстрока бесплатна

Замер печатает размеры заголовков:

Восьми байтов разницы хватает, чтобы объяснить половину темы: у строки нет ёмкости, потому что дописывать в неё нельзя.

Отсюда сразу: s[0] = 'x' не компилируется, и это не ограничение из осторожности. Записать в строку — значит испортить все подстроки, которые смотрят в тот же массив, а смотрят они в него именно потому, что строка неизменяема. Свойство держит само себя.

Подстрока бесплатна — и поэтому дорога

Вот пара, которую и хотят услышать вместе.

Подстрока s[10:20] — ноль выделений: новый заголовок указывает внутрь того же массива. И ровно поэтому:

Десять байт удерживают восемь мегабайт. Сборщик собирает массив целиком или не собирает вовсе; ссылка внутрь массива держит его весь.

Где это встречается на самом деле: разобрали большой ответ сервиса, вынули из него идентификатор, положили в долгоживущий кеш — и ответ остался в памяти вместе с идентификатором. Симптом характерный: память растёт, а по числу объектов ничего не видно.

Правило, которое из этого следует, узкое: strings.Clone нужен только там, где короткий кусок переживает длинную строку. Клонировать всё подряд — значит платить копированием за задачу, которой нет.

Механизм 5: склейка в цикле — почему это не про скорость операции

Прежде чем смотреть на числа, стоит вывести ответ из того, что уже сказано. Строка неизменяема — это первое утверждение урока. Значит, «дописать к строке» невозможно в принципе: каждый += строит новую строку и копирует в неё всё накопленное. На k-м шаге копируется k кусков, а всего за n шагов — сумма от 1 до n, то есть работа квадратична.

Предсказание отсюда однозначное: кратность против Builder должна расти вместе с числом кусков. Именно рост, а не сама кратность: одно число ничего не скажет, потому что зависит от длины цикла.

Предсказание подтвердилось: ×2,3 → ×23,3 → ×111,8. Растущая кратность и есть подпись квадратичной работы; если бы работа была линейной, столбец стоял бы на месте.

Выделений на тысяче кусков: 999 против 15 у Builder и 1 у Builder с Grow.

Builder пишет в растущий буфер и отдаёт его строкой без копии; Grow убирает и промежуточные расширения, когда итоговый размер известен заранее.

И оговорка, без которой правило вредит. На двух-трёх кусках a + b + c быстрее Builder и читается лучше: компилятор склеивает такое одним вызовом. Builder заводят там, где кусков много и их число заранее неизвестно — то есть в цикле.

Глубже: конвертации — что копируется, а что нет

Здесь начинается другой сорт утверждений, и разницу стоит проговорить. Контракт говорит только, что string и []byte — разные типы; всё остальное ниже — про то, что делает нынешний компилятор, и про числа, снятые на конкретной машине.

Здесь у темы самое устаревшее общее место.

Первое. len([]rune(s)) — выражение, которое советуют заменять на utf8.RuneCountInString, — не выделяет памяти. Замер:

Компилятор узнаёт форму len([]rune(s)) и считает руны на месте, среза не строя. Совет, повторяемый в статьях, описывает компилятор, которого давно нет. Платить приходится там, где срез действительно нужен — когда его сохраняют и индексируют.

Второе. Часть конвертаций []byte → string бесплатна:

Правило простое: копия нужна тогда, когда строка переживает выражение. Если она нужна только внутри одного выражения и наружу не попадает, компилятор её не строит. Отсюда практический вывод: искать в map[string]T по ключу из []byte можно прямо, без unsafe и без ручных обходов.

Как отвечать на собеседовании

Короткий ответ: строка в Go — это последовательность байтов в кодировке UTF-8, а не последовательность символов. Поэтому длина считает байты, обращение по индексу даёт байт, а for range идёт по кодовым точкам и отдаёт байтовые смещения. Вторым предложением добавьте устройство: строка — это указатель и длина над неизменяемыми байтами, и из неизменяемости выводится и бесплатная подстрока, и квадратичная склейка.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

Про len отвечайте числом и причиной. «Байты. У "A世🙂" — восемь при трёх рунах: буква занимает один байт, иероглиф три, эмодзи четыре».

Про s[i] скажите тип и приведите обе половины. «byte. У той же строки s[0] — это 65 и вся буква «A», а s[1] — 228 и треть иероглифа. И string(s[1]) даёт не иероглиф, а постороннее «ä»: это конвертация числа в руну с таким кодом, а не декодирование байта».

Про символы разведите три уровня. «Байты, руны и графемы — три разных числа. é в составной форме — две руны при одном видимом знаке, семья из эмодзи — пять рун при одном. Разбиения на графемы в стандартной библиотеке нет».

Про руну добавьте вторую половину. «Руна — кодовая точка, но не символ на экране: é может быть двумя рунами, и тогда счётчик покажет два при одном видимом знаке».

Про подстроку называйте обе стороны сразу. «Ноль выделений — и удержание всего массива. У меня десять байт держали восемь мегабайт; лечится strings.Clone».

Про склейку говорите о росте, а не о кратности. «Квадратично: каждый += копирует накопленное. На тысяче кусков вышло ×109 против Builder. Но на двух- трёх кусках плюс быстрее».

Дальше спросят

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

fmt.Println(len(s))
fmt.Println(utf8.RuneCountInString(s))
fmt.Println(s[0])
fmt.Println(s[1])
fmt.Println(len([]rune(s)))

var offsets []string
for i := range s {
offsets = append(offsets, strconv.Itoa(i))
}
fmt.Println(strings.Join(offsets, " "))

fmt.Println(len(string(s[0])))
fmt.Println(len(string(s[1])))

8
3
65
228
3
0 1 4
1
2

3
3
65
228
3
0 1 2
1
1

8
3
65
228
3
0 1 4
1
1

8
8
65
228
8
0 1 2 3 4 5 6 7
1
2

Проверка знаний