UTF-8 byte[] в string в C#: какой способ быстрее и лучше?

Онлайн-тренажер Python для начинающих

Изучайте Python легко и без перегрузки теорией. Решайте практические задачи с автоматической проверкой, получайте подсказки на русском языке и пишите код прямо в браузере — без необходимости что-либо устанавливать.

Начать курс

Почему вопрос "UTF-8 byte[] to string" не теряет актуальности?

Представьте: вы получили массив байтов от сетевого запроса, прочитали бинарный файл или десериализовали данные из API. Внутри — обычный текст на русском, английском или эмодзи. Но C# видит только byte[]. Ваша задача — превратить эти нули и единицы в понятную строку string.

Казалось бы, что может быть проще? Один вызов метода — и готово. Но на Stack Overflow вопрос "How to convert UTF-8 byte[] to string" собирает тысячи просмотров и десятки ответов. Почему? Потому что дьявол кроется в деталях: кодировка, производительность, безопасность и неожиданные исключения.

В этой статье мы не просто дадим готовый код. Мы сравним подходы, замерим скорость, обсудим подводные камни и выберем лучший инструмент для каждой задачи. Если вы пишете на C# и работаете с сетью, файлами или сериализацией — этот материал для вас.

Проблема: byte[] — это не строка

В C# строка string хранится в кодировке UTF-16. А байты, которые вы получили, скорее всего, закодированы в UTF-8 (стандарт интернета, JSON, большинство текстовых протоколов). Прямое приведение типов невозможно — компилятор выдаст ошибку.

Нужен декодер, который преобразует последовательность байтов UTF-8 в символы UTF-16. И здесь начинается самое интересное: у разработчика есть как минимум три принципиально разных пути.

Метод 1: Классика — Encoding.UTF8.GetString

Самый очевидный и рекомендуемый Microsoft способ — использовать статический класс System.Text.Encoding:

byte[] utf8Bytes = { 72, 101, 108, 108, 111, 32, 208, 191, 209, 128, 208, 176, 208, 178, 208, 176 }; // "Hello права"
string result = Encoding.UTF8.GetString(utf8Bytes);
Console.WriteLine(result); // Вывод: Hello права

Плюсы:

Простота — одна строка кода.
Поддержка всех кодировок, включая UTF-8, UTF-16, ASCII, Latin-1.
Встроенная обработка BOM (Byte Order Mark) — если в начале массива есть маркер UTF-8, он будет проигнорирован.
Безопасность — никаких unsafe блоков.

Минусы:

Каждый вызов создаёт новую строку и внутренний буфер.
Если байты повреждены или содержат невалидную UTF-8 последовательность, метод по умолчанию выбросит DecoderFallbackException (если не настроить fallback).
Неоптимально для очень больших массивов (сотни мегабайт) — двойное копирование данных.

Когда использовать?

В 95% случаев. Это стандарт индустрии. Если вы не пишете высоконагруженный парсер или не работаете с гигабайтами логов — берите Encoding.UTF8.GetString.

Метод 2: Быстрый и опасный — unsafe с указателями

Для тех, кто гонится за скоростью и не боится unsafe. Идея: мы знаем, что UTF-8 и UTF-16 — разные кодировки, но если массив содержит только ASCII-символы (коды до 127), то каждый байт можно "растянуть" в 2-байтовый символ без декодирования.

unsafe string UnsafeAsciiBytesToString(byte[] bytes)
{
    fixed (byte* pBytes = bytes)
    {
        return new string((sbyte*)pBytes, 0, bytes.Length);
    }
}

Этот код работает только для ASCII! Для русского текста (символы > 127) результат будет мусором. Но для чистого английского он работает в 2-3 раза быстрее Encoding.UTF8.GetString.

Плюсы:

Минимальные накладные расходы — нет копирования, нет декодирования.
Идеально для парсинга HTTP-заголовков, JSON-ключей (если они ASCII).

Минусы:

Опасен для многобайтовых символов — поломка данных.
Требует разрешения unsafe в проекте (не везде допустимо).
Не обрабатывает BOM и невалидные последовательности.

Реалистичный тест: когда это оправдано?

Представьте, что вы пишете высокопроизводительный TCP-сервер, который принимает тысячи запросов в секунду. Каждый запрос содержит маленький ASCII-заголовок. Здесь выигрыш в скорости может быть критичен. Но для обычного веб-приложения — это premature optimization.

Метод 3: Современный — ReadOnlySpan и Encoding.UTF8.GetString

Начиная с .NET Core 2.1 / .NET 5, Microsoft представила Span и ReadOnlySpan. Они позволяют работать с памятью без лишних копирований. Комбинация ReadOnlySpan<byte> и Encoding.UTF8.GetString даёт лучшее из двух миров:

byte[] utf8Bytes = GetUtf8Bytes(); // откуда-то
ReadOnlySpan span = utf8Bytes.AsSpan();
string result = Encoding.UTF8.GetString(span); // перегрузка для Span

Этот код не копирует массив в промежуточный буфер. Метод GetString(ReadOnlySpan<byte>) работает напрямую с памятью массива.

Плюсы:

Высокая производительность — на уровне unsafe, но без риска.
Полная поддержка UTF-8, включая многобайтовые символы и эмодзи.
Не требует дополнительных пакетов — встроено в современные версии .NET.

Минусы:

Не работает в .NET Framework 4.x (только через NuGet-пакет System.Memory).
Требует понимания концепции Span — небольшой порог входа.

Сравнение производительности (бенчмарк)

Мы провели простой тест: массив из 1 000 000 байт (смесь ASCII и кириллицы). Запускали 10 000 итераций. Результаты (время в миллисекундах на 1000 вызовов):