文字コードをShift-jisからUTF-8に変換する場合、DW　CS４では「BOMあり」で変換しないと文字化けする。

----------------------------------
UTF-8で符号されたテキストデータはエンディアンに関わらず同じ内容になるので、UTF-8で符号化されていることが確定しているのならバイト順マーク（英: Byte Order Mark、略語：BOM）を付加する必要はない。しかし、一部のテキスト処理アプリケーション (エディタなど) では、作成したテキストデータの先頭にBOMを付加する (付加するかどうかを選択できるものもある)。付加する場合は、EF BB BF (16進。U+FEFFのUTF-8での表現) をデータの先頭に付加する。なお、BOMありの方をUTF-8、なしの方をUTF-8Nと呼ぶこともあるが、このような呼び分けは日本以外ではほとんど知られておらず、また公的規格などによる裏付けもない。このため、UTF-8という呼び名を使っていれば情報交換の相手が文書先頭にBOMがあると見なすと期待すべきではないし、いっぽう、UTF-8Nという呼び名は情報交換の際に用いるべきではない。

BOMを付加する目的は、その文書がUTF-8であることを確実に認識できるようにするためだと考えられる。 一方で、UTF-8のBOMを認識しない（単に8ビットスルーであるというだけの、正式にはUTF-8に対応していない）プログラムでは、BOMが余分なデータとみなされて問題となる場合もある。例えば、UNIX系OSにおける実行可能スクリプトは、ファイル先頭が「#!」から始まるとき、それに続く文字列をインタプリタのコマンドとして認識するが、現状の多くのシステムでは、BOMが存在するとこの機能が働かず実行できない。ただし、これはテキストエディタで編集可能とはいえ、あくまでも実行可能な"バイナリ形式"での事例であり、テキストファイルにおけるBOMの取り扱いとは別の問題である。

逆にBOMがないとUTF-8と認識できないプログラムも存在する (とくにASCII部以外の文字が少ない場合に誤認することが多い)。

プロトコルが常にUTF-8である事を強制しているものである場合はBOMを禁止するべきで、この場合ファイル先頭のBOMは "ZERO WIDTH NO-BREAK SPACE" と見なされる。逆にプロトコルがそれを保証しない場合BOMは禁止されずファイル先頭のそれはBOMと見なされる。

----------------------------------