关于Java：Unix和Windows文件之间的差异

我是否假设" Windows文件"和" unix文件"之间的唯一区别是换行符？

我们有一个系统已经从Windows机器移至UNIX机器，并且格式有问题。

在将文件传送到我们的" transportsystem"中的系统之前，我需要自动在unix / windows之间进行转换。我可能需要确定当前格式的东西，以及将其转换为其他格式的东西。
如果仅仅是换行符，那就是最大的区别，那么我正在考虑仅使用java.io读取文件。据我所知，他们能够使用readLine处理这两种情况。然后只写回每一行

摘要：

samjudson:

This is only a difference in text files, where UNIX uses a single Line Feed (LF) to signify a new line, Windows uses a Carriage Return/Line Feed (CRLF) and Mac uses just a CR.

Cebjyre详细阐述了以下内容：

OS X uses LF, the same as UNIX - MacOS 9 and below did use CR though

莫

There could also be a difference in character encoding for national characters. There is no"unix-encoding" but many linux-variants use UTF-8 as the default encoding. Mac OS (which is also a unix) uses its own encoding (macroman). I am not sure, what windows default encoding is.

麦克道尔

In addition to the new-line differences, the byte-order mark can cause problems if files are treated as Unicode on Windows.

厚脸皮

However, another set of problems that you may come across can be related to single/multi-byte character encodings. If you see strange unexpected chars (not at end-of-line) then this could be the reason. Especially if you see square boxes, question marks, upside-down question marks, extra characters or unexpected accented characters.

萨迪

On unix, files that start with a . are hidden. On windows, it's a filesystem flag that you probably don't have easy access to. This may result in files that are supposed to be hidden now becoming visible on the client machines.

File permissions vary between the two. You will probably find, when you copy files onto a unix system, that the files now belong to the user that did the copying and have limited rights. You'll need to use chown/chmod to make sure the correct users have access to them.

有一些工具可以解决此问题：

pauldoo

If you are just interested in the content of text files, then yes the line endings are different. Take a look at something like dos2unix, it may be of help here.

厚脸皮

As pauldoo suggests, tools like dos2unix can be very useful. Note that these may be on your linux/unix system as fromdos or tofrodos, or perhaps even as the general purpose toolbox recode.

Java编码帮助

Cheekysoft

When writing to files or reading from files (that you are in control of), it is often worth specifying the encoding to use, as most Java methods allow this. However, also ensuring that the system locale matches can save a lot of pain

---

这只是文本文件的区别，在UNIX中，UNIX使用单个换行(LF)表示新行，Windows使用回车/换行(CRLF)，而Mac仅使用CR。

二进制文件应该没有区别(即Windows计算机上的JPEG将与unix框上的相同JPEG逐字节地存储)。

---

国家字符的字符编码也可能有所不同。没有" unix编码"，但是许多linux变体使用UTF-8作为默认编码。 Mac OS(也是Unix)使用自己的编码(宏)。我不确定Windows默认编码是什么。

但这可能是麻烦的另一个来源(除了不同的换行符之外)。

你有什么问题与换行有关的问题可以通过unix机器上的dos2unix或unix2dos程序轻松解决。

---

除了给出的答案之外，您可能还会发现不同文件系统的问题：

• 在UNIX上，以开头的文件。隐藏。在Windows上，这是一个文件系统标志，您可能无法轻松访问。这可能会导致应该被隐藏的文件现在在客户端计算机上变得可见。

• 两者之间的文件权限有所不同。将文件复制到UNIX系统上时，您可能会发现文件现在属于进行复制的用户，并且权限有限。您需要使用chown / chmod来确保正确的用户可以访问它们。

---

如果您只对文本文件的内容感兴趣，那么可以，这些行的结尾是不同的。看一下dos2unix之类的东西，这可能对您有所帮助。

(当然，还有很多其他因素使UNIX和Windows文件有所不同，但我认为您现在对这些其他差异不感兴趣。)

---

正如pauldoo所建议的，dos2unix之类的工具可能非常有用。请注意，这些可能以fromdos或tofrodos的形式出现在您的linux / unix系统上，甚至可能以通用工具箱的重新编码形式出现。

但是，您可能遇到的另一组问题可能与单字节/多字节字符编码有关。如果看到奇怪的意外字符(不在行尾)，则可能是原因。特别是如果您看到方盒，问号，上下颠倒的问号，多余的字符或意外的重音字符。

在* nix框上运行命令语言环境将告诉您系统语言环境是什么。如果这与从Windows计算机传输过来的文本文件中使用的编码不同，则有时会导致问题，具体取决于这些文件的用法。您可以使用功能非常强大的recode命令尝试在不同的字符集以及任何行尾问题之间进行转换。 recode -l将向您显示该工具可以转换的所有格式和编码。这很可能会很长。

在写入文件或从文件中读取文件(由您控制??)时，通常值得指定要使用的编码，因为大多数Java方法都允许这样做。但是，确保系统区域设置匹配也可以避免很多麻烦。

---

除了换行符以外，如果在Windows上将文件视为Unicode，则字节顺序标记还会引起问题。

---