These are documented here:
When decoding, the UTF-16BE and UTF-16LE charsets interpret the initial byte-order marks as a ZERO-WIDTH NON-BREAKING SPACE; when
encoding, they do not write byte-order marks.
When decoding, the UTF-16 charset interprets the byte-order mark at the beginning of the input stream to indicate the byte-order of the
stream but defaults to big-endian if there is no byte-order mark; when
encoding, it uses big-endian byte order and writes a big-endian
byte-order mark.
So in short, UTF_16BE
and UTF_16LE
do not care about BOM, and so does not correspond to the "UTF-16 BE BOM" or "UTF-16 LE BOM" options in notepad++ as you seem to imply.
On the other hand, UTF_16
does write a BE BOM when encoding, so would correspond to choosing the "(Convert to) UTF-16 BE BOM" option in notepad++. Note that for decoding, the BOM is "optional".
As for the NotePad options, they do not say whether they include a BOM, so I'm not sure if they do. If they do not, then it would be equivalent to UTF_16BE
and UTF_16LE
's encoding behaviour.
As for why notepad++ does not have the equivalent of the UTF_16BE
and UTF_16LE
options, or why Java doesn't have a "UTF-16 LE BOM" option, it is not really a useful question to ask. As Eric Lippert said,
features are not magically implemented by default and then the implementations have to get removed by the development team for a good reason. Rather, all features are unimplemented by default and have to be thought of, designed, specified, implemented, tested, approved and shipped to customers. All that costs time and effort.