如何在不使用BOM且以非ASCII字符开头的情况下识别针对文件的不同编码?

时间:2011-04-14 01:54:05

标签: java unicode encoding byte-order-mark non-ascii-characters

我在尝试识别没有BOM的文件的编码时遇到了问题,特别是当文件以非ascii字符开头时。

我发现了以下两个关于如何识别文件编码的主题,

目前,我创建了一个类来识别文件的不同编码(例如UTF-8,UTF-16,UTF-32,UTF-16无BOM等),如下所示,

public class UnicodeReader extends Reader {
private static final int BOM_SIZE = 4;
private final InputStreamReader reader;

/**
 * Construct UnicodeReader
 * @param in Input stream.
 * @param defaultEncoding Default encoding to be used if BOM is not found,
 * or <code>null</code> to use system default encoding.
 * @throws IOException If an I/O error occurs.
 */
public UnicodeReader(InputStream in, String defaultEncoding) throws IOException {
    byte bom[] = new byte[BOM_SIZE];
    String encoding;
    int unread;
    PushbackInputStream pushbackStream = new PushbackInputStream(in, BOM_SIZE);
    int n = pushbackStream.read(bom, 0, bom.length);

    // Read ahead four bytes and check for BOM marks.
    if ((bom[0] == (byte) 0xEF) && (bom[1] == (byte) 0xBB) && (bom[2] == (byte) 0xBF)) {
        encoding = "UTF-8";
        unread = n - 3;
    } else if ((bom[0] == (byte) 0xFE) && (bom[1] == (byte) 0xFF)) {
        encoding = "UTF-16BE";
        unread = n - 2;
    } else if ((bom[0] == (byte) 0xFF) && (bom[1] == (byte) 0xFE)) {
        encoding = "UTF-16LE";
        unread = n - 2;
    } else if ((bom[0] == (byte) 0x00) && (bom[1] == (byte) 0x00) && (bom[2] == (byte) 0xFE) && (bom[3] == (byte) 0xFF)) {
        encoding = "UTF-32BE";
        unread = n - 4;
    } else if ((bom[0] == (byte) 0xFF) && (bom[1] == (byte) 0xFE) && (bom[2] == (byte) 0x00) && (bom[3] == (byte) 0x00)) {
        encoding = "UTF-32LE";
        unread = n - 4;
    } else {
        // No BOM detected but still could be UTF-16
        int found = 0;
        for (int i = 0; i < 4; i++) {
            if (bom[i] == (byte) 0x00)
                found++;
        }

        if(found >= 2) {
            if(bom[0] == (byte) 0x00){
                encoding = "UTF-16BE";
            }
            else {
                encoding = "UTF-16LE";
            }
            unread = n;
        }
        else {
            encoding = defaultEncoding;
            unread = n;
        }
    }

    // Unread bytes if necessary and skip BOM marks.
    if (unread > 0) {
        pushbackStream.unread(bom, (n - unread), unread);
    } else if (unread < -1) {
        pushbackStream.unread(bom, 0, 0);
    }

    // Use given encoding.
    if (encoding == null) {
        reader = new InputStreamReader(pushbackStream);
    } else {
        reader = new InputStreamReader(pushbackStream, encoding);
    }
}

public String getEncoding() {
    return reader.getEncoding();
}

public int read(char[] cbuf, int off, int len) throws IOException {
    return reader.read(cbuf, off, len);
}

public void close() throws IOException {
    reader.close();
}

}

上述代码可以在所有情况下正常工作,除非文件没有BOM且以非ascii字符开头。由于在这种情况下,检查文件是否仍然是没有BOM的UTF-16的逻辑将无法正常工作,并且编码将默认设置为UTF-8。

如果有办法检查没有BOM的文件编码并且使用非ascii字符开头,特别是对于UTF-16 NO BOM文件?

谢谢,任何想法都会受到赞赏。

3 个答案:

答案 0 :(得分:1)

一般来说,如果没有提供编码,就无法确定编码。

您可以通过文本中的特定模式猜测UTF-8(高位设置,设置,设置,未设置,设置,设置,设置,未设置),但仍然是猜测。

UTF-16很难;您可以在同一个流上成功解析BE和LE;这两种方式都会产生一些字符(虽然可能是毫无意义的文字)。

那里的一些代码使用统计分析来猜测符号频率的编码,但这需要对文本进行一些假设(即“这是一个蒙古语文本”)和频率表(可能与文本不匹配) 。在一天结束时,这仍然是一个猜测,并且在100%的情况下无法帮助。

答案 1 :(得分:1)

最好的方法不是自己尝试实现。而是使用现有的库来执行此操作;见Java : How to determine the correct charset encoding of a stream。例如:

应该注意,可以做的最好的事情是猜测文件最可能的编码。在一般情况下,你不可能100%确定你已经找到了正确的编码;即创建文件时使用的编码。


  

我想说这些第三方库也无法识别我遇到的文件的编码[...]它们可以根据我的要求进行改进。

或者,您可以认识到您的要求非常难以满足......并进行更改;例如

  • 限制自己使用某种编码,
  • 坚持提供/上传文件的人正确说明其编码(或主要语言)是什么,和/或
  • 接受您的系统在某个百分比的时间内会出错,并提供一些方法,以便有人可以纠正错误陈述/猜测的编码。

面对事实:这是一个理论上无法解决的问题。

答案 2 :(得分:0)

如果您确定它是一个有效的Unicode流,如果它没有BOM,它必须是UTF-8(因为既不需要也不推荐使用BOM),如果它没有,那么你知道它是什么

如果它只是一些随机编码,则无法确定。你可以期望的最好的只是有时候是错的,因为在所有情况下都无法正确猜测。

如果您可以将可能性限制为非常小的子集it is possible to improve the odds of your guess being right

唯一可靠的方法是要求提供商告诉您他们提供的内容。如果您想要完全可靠,那么这是您唯一的选择。如果你不需要可靠性,那么你猜 - 但有时候猜错了。

我觉得你必须是一个Windows用户,因为我们其他人一开始很少有BOM的原因。我知道我经常处理tgagabytes的文本(在Mac,Linux,Solaris和BSD系统上),超过99%的UTF-8,只有两次我遇到了BOM文本。我听说过Windows用户一直都会遇到它。如果这是真的,这可能会或可能不会使您的选择更容易。