Могу ли я гарантировать, что методы Stream.Write () для Response.Filter не будут иметь частичный символьный байт? - PullRequest
1 голос
/ 07 октября 2009

Я создаю реализацию System.IO.Stream с целью установки фильтра для HttpContext.Response.Filter. Я хотел бы знать, будут ли все вызовы Write(byte[], int, int) гарантировать, что записанные байты содержат целые символьные последовательности байтов или если возможно, что один символ (в случае кодировки utf-32) может быть разделен между вызовами.

public override void Write(byte[] buffer, int offset, int count) {
    // Here `e' is a reference to `ctx.Response.ContentEncoding'
    // from the original context.
    char[] chars = e.GetChars(buffer, offset, count);
    //... Stream processing logic here.
}

Мое текущее тестирование с использованием utf-32 показало, что вызовы, кажется, всегда содержат только целые последовательности символов, но я хотел получить подтверждение, прежде чем подтвердил свое предположение.

Если существует вероятность того, что записываемые байты могут быть разделены между вызовами Write, каков наилучший подход для решения этой проблемы? Я думал о том, чтобы выполнить такую ​​же проверку ширины одного байта в моем конструкторе и использовать ее, чтобы посмотреть, делится ли массив байтов на это значение. Однако это, естественно, нежелательно, хотя и довольно тривиально для реализации.

// Here `e' is a reference to `ctx.Response.ContentEncoding'
// from the original context.
// `charLen' will yield 4 for a utf-32 encoding.
charLen = e.GetByteCount(new char[] { ' ' });

1 Ответ

4 голосов
/ 07 октября 2009

Потоки не знают, имеют ли они дело с символьными данными или двоичными данными. Это зависит от фильтра или, возможно, от StreamWriter, который может обернуть ваш поток, чтобы решить, будет ли он записывать целый символ за раз.

Лично я бы ожидал, что StreamWriter когда-либо будет писать только полные символы, но я не думаю, что я на это полагаюсь. Я не вижу ничего, гарантирующего такое поведение.

Я предлагаю вам использовать System.Text.Decoder (полученный по телефону Encoding.GetDecoder) и использовать его для поддержания соответствующего состояния. На самом деле, это именно то, для чего он предназначен :) См. Дополнительную информацию в связанных документах.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...