Обрезал строку по байтам, как в C++, а Rust запаниковал

Если эталоном служит сторона C++, полезно посмотреть, что она на самом деле писала. substr считает байты и больше ничего.

std::string s = "Привет";
std::string t = s.substr(0, 5);
std::cout << t.size() << ' ' << std::hex
          << int(static_cast<unsigned char>(t.back())) << '\n';

Печатается 5 d0. Последний байт - это ведущий байт «и», а продолжения нет. Имя целиком на кириллице, обрезанное по нечётному лимиту, каждый раз кончается так, поэтому битые хвосты предсказуемы, и это помогает, когда их ищешь.

Пометки. Известно. С Rust 1.91 в стабильной версии есть str::floor_char_boundary, он делает то же, что ваш цикл назад, то есть находит ближайшую границу не больше n. В документации к нему сразу сказано, что графемы так всё равно можно разрезать.

Неизвестно. Что лежит в данных, которые старый C++ уже записал. Если хвосты там битые, String::from_utf8 на них вернёт ошибку, а String::from_utf8_lossy молча подставит U+FFFD. Это два разных решения, и выбрать между ними нужно до чтения, а не когда что-то упадёт.

Пока это допущение, что битые записи вообще есть. Нужен один проход по старым данным.

Сначала проверьте тулчейн. floor_char_boundary стабилен только с 1.91, а компиляторы постарше его просто отвергают.

Граница символа - ещё не граница буквы, так что радоваться рано. «й» может прийти одной кодовой точкой, а может как «и» плюс комбинируемая бреве, U+0306, два скаляра и четыре байта. Режешь между ними, получаешь валидный UTF-8 и «и», которую никто не набирал. В документации floor_char_boundary то же самое показано на эмодзи из нескольких скаляров.

Дешёвое решение сводится к тому, чтобы нормализовать имена из ввода в NFC до обрезки, тогда «й» снова одна кодовая точка. Но готовая составная форма есть не у всего, а для остального нужна сегментация графем, которой нет ни в стандартной библиотеке Rust, ни в стандартной библиотеке C++. Бесит, но теперь хотя бы понятно, какой баг всё ещё твой.

fretboard, прогнал старый дамп, как вы советовали, и там всё грязнее, чем я надеялся. Большинство битых записей такие, как я ждал, error_len() возвращает None, а valid_up_to() стоит за байт до конца, и это след обрезки по байтам и ничего больше. Их я режу по valid_up_to() и U+FFFD не подставляю, потому что замена занимает три байта там, где был один, и может снова вытолкнуть значение за лимит.

Но несколько записей вернули Some(1) посреди строки, байт больше 0x7F, за которым не идёт правильная последовательность, а это уже совсем не обрезка. Похоже, какой-то старый путь писал имена в однобайтовой кодировке, Latin-1 или Windows-1251, а эти две прочитают один и тот же байт как разные буквы, и по одному байту я никак не пойму, какая была. Если резать такие по valid_up_to(), теряется остаток имени, а если пропустить через from_utf8_lossy, получится U+FFFD посреди чьей-то фамилии.

Остальные уходят в отдельную таблицу нетронутыми, пока я не выясню, что их записало, и если тот старый путь где-то ещё работает, таблица будет расти. А по целому имени можно отличить Latin-1 от 1251, раз по одному байту нельзя? В 1251 кириллическая фамилия почти целиком состоит из байтов от 0xC0 и выше, а имя в Latin-1 в основном ASCII с редким акцентом, так что выдать может само соотношение. Просто не хочется, чтобы эвристика решала, как кого зовут.

Разведите два случая в коде, и вторая таблица будет наполняться сама. Подвох в том, что from_utf8 сообщает, какой у вас случай, только через error_len().

fn keep_len(bytes: &[u8]) -> Result<usize, std::str::Utf8Error> {
    match std::str::from_utf8(bytes) {
        Ok(_) => Ok(bytes.len()),
        Err(e) if e.error_len().is_none() => Ok(e.valid_up_to()),
        Err(e) => Err(e),
    }
}

Кириллическое имя, обрезанное на пяти байтах, даёт Ok(4). b"Ren\xe9e" даёт Err с error_len: Some(1). Считайте строки с Err до и после каждого импорта, и станет ясно, пишет ли их ещё старый путь.