Какой смысл использовать std :: ios_base :: binary?

У меня была проблема с чтением файла Linux в Window. Вот обсуждение вопроса: Использование fstream :: seekg под windows для файла, созданного под Unix.

Проблема была решена путем открытия текст файл с std::ios_base::binary указано.

Но какой смысл в этом режиме? Если указан, вы все еще можете работать с вашим файлом как текстовым файлом (запись с mystream << "Hello World" << std::endl и читать с std::getline).

Под Windows единственное отличие, которое я мог заметить, заключается в том, что mystream << "Hello World" << std::endl использует:

  • 0x0D 0x0A в качестве разделителя строк, если std::ios_base::binary не был указан (EOL и возврат каретки)
  • 0x0A в качестве разделителя строк, если std::ios_base::binary был указан (только EOL)

Блокнот не показывает строки при открытии файлов, созданных с помощью std::ios_base::binary, Лучшие редакторы, такие как vi или Wordpad, показывают их.

Разве это единственная разница между файлами, созданными с и без std::ios_base::binary? Документация говорит Consider stream as binary rather than text.Что это значит в конце?

Безопасно ли всегда устанавливать std::ios_base::binary если я не забочусь об открытии файла в блокноте и хочу иметь fstream::seekg всегда работать?

7

Решение

Различия между двоичным и текстовым режимами являются реализацией
определены, но касаются только самого низкого уровня: они не меняют
смысл таких вещей, как << а также >> (которые вставляют и извлекают текстовые
данные). Кроме того, формально, выводя все, кроме нескольких непечатных
символы (как '\n') неопределенное поведение, если файл находится в тексте
Режим.

Для наиболее распространенных ОС: в Unix нет различий; оба
идентичны. Под виндой '\n' внутренне будет сопоставлен с двумя
последовательность символов CR, LF (0x0D, 0x0A) внешне и 0x1A будет
интерпретируется как конец файла при чтении. В более экзотических (и в основном
вымершие) ОС, однако, они могут быть представлены совершенно разными
типы файлов на уровне ОС, и может быть невозможно прочитать файл в
текстовый режим, если он был написан в двоичном режиме, и наоборот. Или ты
мог видеть что-то другое: лишние пробелы в конце строки или
нет '\n' в двоичном режиме.

Что касается всегда настройки std::ios_base::binary: моя политика для
переносимые файлы, чтобы решить, как именно я хочу их отформатировать, установите
двоичный файл, и выведите то, что я хочу. Который часто CR, LF, а не просто
LF, так как это сетевой стандарт. С другой стороны, самый
У программ Windows нет проблем только с LF, но я сталкивался
более чем несколько Unix-программ, которые имеют проблемы с CR, LF; который
выступает за систематическое использование только LF (что тоже проще). дела
все это означает, что я получаю одинаковые результаты независимо от того,
Я работаю под Unix или под Windows.

7

Другие решения

Значение текстового потока против двоичного потока зависит от платформы и несколько непредсказуемо.

Но что касается популярных платформ, то все просто: в Linux и MacOS X разницы нет. В Windows единственная разница заключается в том, что внутренний \n переводится на \r\n во внешнем потоке.

0

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector