Правильно ли я полагаю, что единственная разница между "файлами Windows" и "файлами Unix" - это перенос строки?
У нас есть система, которая была перенесена с компьютера с Windows на компьютер с Unix, и у нас проблемы с форматом.
Мне нужно автоматизировать перевод между unix / windows, прежде чем файлы будут доставлены в систему в нашей "транспортной системе". Возможно, мне понадобится что-то, чтобы определить текущий формат, и что-то, чтобы преобразовать его в другой формат. Если разница заключается только в новой строке, то я рассматриваю просто чтение файлов с помощью java.io. Насколько я знаю, они способны справиться с обоими с readLine. А затем просто напишите каждую строку обратно с
while (line = readline)
print(line + NewlineInOtherFormat)
....
Резюме:
В этом разница только в текстовых файлах, где UNIX использует один перевод строки (LF) для обозначения новой строки, Windows использует возврат каретки / перевод строки (CRLF), а Mac использует только CR.
к которому Cebjyre разрабатывает:
OS X использует LF, так же, как UNIX - MacOS 9 и ниже использовали CR, хотя
Также может быть разница в кодировке национальных символов. Не существует "unix-encoding", но многие linux-варианты используют UTF-8 в качестве кодировки по умолчанию. Mac OS (которая также является Unix) использует свою собственную кодировку (macroman). Я не уверен, что такое кодировка Windows по умолчанию.
Помимо различий в новой строке, метка порядка байтов может вызвать проблемы, если файлы рассматриваются как Unicode в Windows.
Однако другой набор проблем, с которыми вы можете столкнуться, может быть связан с однобайтовыми / многобайтовыми кодировками символов. Если вы видите странные неожиданные символы (не в конце строки), то это может быть причиной. Особенно, если вы видите квадратные квадраты, вопросительные знаки, перевернутые вопросительные знаки, лишние символы или неожиданные символы с акцентом.
В Unix файлы, начинающиеся с. скрыты В Windows это флаг файловой системы, к которому у вас, вероятно, нет простого доступа. Это может привести к тому, что файлы, которые должны быть скрыты, теперь становятся видимыми на клиентских компьютерах.
Права доступа к файлам варьируются между двумя. Когда вы копируете файлы в систему Unix, вы, вероятно, обнаружите, что файлы теперь принадлежат пользователю, который сделал копирование, и имеют ограниченные права. Вам нужно будет использовать chown / chmod, чтобы убедиться, что правильные пользователи имеют к ним доступ.
Существуют инструменты, помогающие решить проблему:
Если вас просто интересует содержание текстовых файлов, то да, окончания строк разные. Взгляните на что-то вроде dos2unix, это может помочь здесь.
Как полагает Пол, такие инструменты, как dos2unix, могут быть очень полезны. Обратите внимание, что они могут быть в вашей системе Linux / Unix как fromdos или tofrodos, или, возможно, даже как перекодирование набора инструментов общего назначения.
Помощь по кодированию Java
При записи в файлы или чтении из файлов (которые вы контролируете) часто стоит указывать используемую кодировку, поскольку большинство методов Java позволяют это. Однако, также гарантируя, что системные языковые соответствия могут сэкономить много боли
В этом разница только в текстовых файлах, где UNIX использует один перевод строки (LF) для обозначения новой строки, Windows использует возврат каретки / перевод строки (CRLF), а Mac использует только CR.
В двоичных файлах не должно быть различий (т.е. JPEG на компьютере с Windows будет байтом для байта такой же, как и тот же JPEG на коробке с Unix).
Также может быть разница в кодировке национальных символов. Не существует "unix-encoding", но многие linux-варианты используют UTF-8 в качестве кодировки по умолчанию. Mac OS (которая также является Unix) использует свою собственную кодировку (macroman). Я не уверен, что такое кодировка Windows по умолчанию.
Но это может быть еще одним источником проблем (кроме разных разрывов строк).
Какие у тебя проблемы? Проблемы, связанные с разрывом строки, можно легко исправить с помощью программ dos2unix или unix2dos на unix-машине.
Если вас просто интересует содержание текстовых файлов, то да, окончания строк разные. Взгляните на что-то вроде dos2unix , это может помочь здесь.
(Конечно, есть много других вещей, которые отличают файлы Unix и Windows, но я не думаю, что вас сейчас интересуют другие различия.)
Помимо различий в новой строке, метка порядка байтов может вызвать проблемы, если файлы рассматриваются как Unicode в Windows.
Как полагает Пол, такие инструменты, как dos2unix, могут быть очень полезны. Обратите внимание, что они могут быть в вашей системе Linux / Unix как fromdos или tofrodos , или, возможно, даже как перекодирование набора инструментов общего назначения .
Однако другой набор проблем, с которыми вы можете столкнуться, может быть связан с однобайтовыми / многобайтовыми кодировками символов. Если вы видите странные неожиданные символы (не в конце строки), то это может быть причиной. Особенно, если вы видите квадратные квадраты, вопросительные знаки, перевернутые вопросительные знаки, лишние символы или неожиданные символы с акцентом.
Выполнение языкового стандарта команды на вашем * nix поле подскажет вам, каков системный языковой стандарт. Если это отличается от кодировки, используемой в текстовых файлах, которые были переданы с компьютера Windows, то это может иногда вызывать проблемы, в зависимости от использования этих файлов. Вы можете использовать очень мощную команду recode, чтобы попытаться преобразовать различные кодировки, а также любые проблемы с окончанием строки. recode -l покажет вам все форматы и кодировки, между которыми инструмент может конвертироваться. Вероятно, это будет ОЧЕНЬ длинный список.
При записи в файлы или чтении из файлов (которые вы контролируете) часто стоит указывать используемую кодировку, поскольку большинство методов Java позволяют это. Тем не менее, также гарантируя, что соответствие системного языкового стандарта может сэкономить много боли.
В дополнение к приведенным ответам могут возникнуть проблемы с различными файловыми системами:
В Unix файлы, начинающиеся с . скрыты В Windows это флаг файловой системы, к которому у вас, вероятно, нет простого доступа. Это может привести к тому, что файлы, которые должны быть скрыты, теперь становятся видимыми на клиентских компьютерах.
Права доступа к файлам варьируются между двумя. Когда вы копируете файлы в систему Unix, вы, вероятно, обнаружите, что файлы теперь принадлежат пользователю, который сделал копирование, и имеют ограниченные права. Вам нужно будет использовать chown / chmod, чтобы убедиться, что правильные пользователи имеют к ним доступ.