tags:

views:

1136

answers:

4

I am looking for a utility method or constant in Java that will return me the bytes that correspond to the appropriate byte order mark for an encoding, but I can't seem to find one. Is there one? I really would like to do something like:

byte[] bom = Charset.forName( CharEncoding.UTF8 ).getByteOrderMark();

Where CharEncoding comes from Apache Commons.

+1  A: 

There isn't anything in the JDK as far as I can see, nor any of the Apache projects.

Eclipse EMF has an Enum however that provides support:

org.eclipse.emf.ecore.resource.ContentHandler.ByteOrderMark

I'm not sure whether that's of any help to you?

There's some more info here on the various BOM's for each encoding type, you could write a simple helper class or enum for this...

http://mindprod.com/jgloss/bom.html

Hope that helps. I'm surprised this isn't in Commons I/O to be honest.

Jon
+1  A: 

It worth noting that many encodings don't have any byte order marks. e.g. an empty string in UTF-8 is just an empty byte[].

Peter Lawrey
Downvoted, because this seems to be incorrect as written. A three-byte sequence of bytes containing the UTF-8 BOM (EFBBBF) will be interpreted as an empty UTF-8 string *if* the application understands how to handle BOMs. (And if it doesn't, the BOM is going to cause trouble, empty string or no.)
Dan Breslau
Java doesn't understand BOMs for UTF-8. I've seen people get bit by this (text editor decided to add a BOM, javac puked.)
Adam Jaskiewicz
+1  A: 

You can generate the BOM like this:

byte[] utf8_bom = "\uFEFF".getBytes("UTF-8");
byte[] utf16le_bom = "\uFEFF".getBytes("UnicodeLittleUnmarked");

If you wish to create the BOMs for other encodings using this method, make sure you use the version of the encoding that does not automatically insert the BOM or it will be repeated. This technique only applies to Unicode encodings and will not produce meaningful results for others (like Windows-1252).

McDowell
My specific case is writing a CSV file that is UTF-8. As far as I can tell, the UTF-8 BOM is the only way to convince Excel to not attempt to read the file in the default character encoding.
Brandon DuRette
There isn't a util method that will help you with your Excel file, but writing 0xEF 0xBF 0xBF to your OutputStream shouldn't be a problem. Just flush those bytes before you wrap your stream in a UTF-8 encoded Writer.
McDowell
I've updated the information on generating the BOM.
McDowell
I wouldn't say that "its usage is discouraged" by the FAQ. It is true that the UTF-8 BOM doesn't specify a "byte-order mark" (making it something of a misnomer), but it definitely helps in signifying that the stream uses UTF-8 encoding.
Dan Breslau
That's a fair comment - I've updated the post. I can't help feeling they used favour not using it, though: http://blogs.msdn.com/oldnewthing/archive/2007/04/17/2158334.aspx
McDowell
A: 

Java does not recognize byte order marks for UTF-8. See bugs 4508058 and 6378911.

The gist is that support was added, broke backwards compatibility, and was rolled back. You'll have to do BOM recognition in UTF-8 yourself.

Adam Jaskiewicz