MemoryStream из string-путаница в использовании кодировки
У меня есть кусок кода, который преобразует строку в поток памяти:
using (MemoryStream stream = new MemoryStream(Encoding.UTF8.GetBytes(applicationForm)))
однако я немного смущен, если это правильно. В основном я всегда путаю кодировку .NET.
итог: использую ли я правильный объект кодирования (utf8 в), чтобы получить байт?
Я знаю, что внутренне .NET хранит строку как UTF-16, но мой applicationForm переменной на основе файла с текстом, который был сохранен в UTF-8 кодировка.
Спасибо,Павел
EDIT 1: давайте объясним, как именно я получаю applicationForm переменной. У меня есть доступ к сборке, которую предоставляет класс с метод GenerateApplicationForm. Этот метод возвращает строку. Однако я знаю, что где-то за кулисами, компонент использует файлы, хранящиеся на диске.Содержание этих файлов в кодировке UTF-8. Поэтому я не могу читать файл напрямую и т. д. У меня есть только эта струна, и я знаю ... , первоначально используется кодированный файл UTF-8. В клиентском коде, который использовал GenerateApplicationForm компонент, я должен преобразовать applicationForm переменной в поток, потому что другие компоненты (из другой сборки) ждет поток. Вот где использование.... заявление, упомянутое в вопросе, вступает в действие.
5 ответов
предполагая, что applicationForm
это строка, которую Вы читаете из некоторых UTF8
текстовый файл. Это будет UTF16
/Unicode
, независимо от кодировки исходного файла. Преобразование произошло, когда вы загрузили файл в строку.
ваш код будет кодировать applicationForm
в строку MemoryStream
of UTF8
байт.
это может или не может быть правильным в зависимости от того, что вы хотите сделать с ним.
строки .Net всегда UTF16
или Unicode
. Когда Strings
преобразуются к файлам, потокам или byte[]
, они могут быть закодированы по-разному. 1 байт недостаточно для хранения всех различных символов, используемых во всех языках, поэтому более сложные строки должны быть закодированы, чтобы один символ мог быть представлен более чем одним байтом, иногда или всегда в зависимости от используемой кодировки.
если вы используете простую кодировку, как ASCII
один characheter всегда будет состоять из одного байта, но данные будут ограничены ASCII
набор charachter. Преобразование для "ASCII" из любой кодировки UTF может потерять данные, если используются какие-либо многобайтовые characheters.
для полной картины о unicode идите сюда.
изменить 1:
За исключением дополнительной информации о GenerateApplicationForm компонент, enconding UTF8
вероятно, будет правильным выбором. Если это doesent работы, попробовать ASCII
или UTF16
. Лучше всего проконсультироваться с исходным кодом компонента или поставщиком компонентов.
редактирование 2: Определенно
просто используйте ту же кодировку для чтения,что и для записи. Если это UTF8 --> используйте UTF8. Если вы пишете по-китайски, кто-то должен уметь читать по-китайски, чтобы понять вас...
для UTF - 8 байт знак заказа (BOM) должен быть добавлен в начале файла. См. файл utf-8, затем используйте конвертер utf-8.
байтовая кодировка UTF8 создает представление ваших данных, которое обратно совместимо с набором символов ASCII для представления ваших данных. Поскольку ASCII является наименьшим общим знаменателем для передачи данных, вы можете гарантировать, что это представление будет работать в подавляющем большинстве систем.
хотя вы можете изменить его, вы предполагаете, что любая система, которую он идет, тоже поймет, что вы ее изменили, и поддержит ваше новое представление. Это довольно сложно предположение проверить. Кодировки на обоих концах очень совпадают.
Если, как вы говорите, вы не можете изменить систему, которая генерирует строку, то да, вы все делаете правильно. Это работает так почему вы считаете, что нужно внести изменения? Внутренние части того, как .NET представляет строку, не вступают в игру здесь, вы не получаете строку .NET, вы получаете кодированное UTF-8 представление значения, поэтому вы должны использовать UTF8 для декодирования его до исходного значения.