回答:
Emacsは、使用しているコーディングシステムに応じてBOMを書き込むかどうかを指定します。Emacsは、ファイルにアクセスするときに使用するコーディングシステムを自動的に選択します。
コーディングシステムをutf-8-with-signatureに変更できます。これにより、EmacsにBOMを書き込むよう指示します。
アクセスしたファイルのコーディングシステムを変更するには:
C-x RET r utf-8-with-signature RET
Emacsが特定のファイルに使用するコーディングシステムを設定するには、ファイル変数を設定します。方法については、マニュアルの「57.3.4ファイル内のローカル変数」を参照してください。
Richard Hoskinsの回答のフォローアップ:BOMをemacsで非表示にしたくない場合は、次のスニペットで* -with-signatureコーディングを無効にできます。
(setq auto-coding-regexp-alist
(delete (rassoc 'utf-16be-with-signature auto-coding-regexp-alist)
(delete (rassoc 'utf-16le-with-signature auto-coding-regexp-alist)
(delete (rassoc 'utf-8-with-signature auto-coding-regexp-alist)
auto-coding-regexp-alist))))
BOMはU + FEFF、つまり「ゼロ幅の改行なしのスペース」であり、emacs 23.1.1ではボックスとして表示されません。代わりに、ファイルの一番上の行がわずかに下に移動し、ボックスが表示される場合があります最初の行の周りに表示されますが、BOMがそこにあることがわかり、必要に応じて削除します。
Emacsの「それ自体」はBOMを台無しにすべきではありません。それが本当にそれをしているなら、それはあなたがBOMを削除するXMLファイルを編集するために使用しているEmacsの「モード」を実装するコードでなければならないでしょう。どちらであるかは言わないので、そのモードのドキュメント、またはファイルをfundamental-mode
(または同様の非破壊モード)で開くことのみを参照できます。またはM-x find-file-literally
、他のすべてが失敗した場合に試してください。
find-file-literally
とM-x sgml-mode
、BOMは削除されません。特殊文字は文字どおりにファイルにアクセスするときにUTF-8でエンコードされないため、基になる形式変換と文字コード変換コードでBOMが削除されている場所を特定すると便利です。
テストでは、UTF-8
ファイルを編集してもエンコードは変更されず、BOMは残ります(efbb bf
)。(nxml-mode)
まあ、これはxml-mode
とnxml-mode
、またはemacsのバージョン(24対26)の間で異なる場合があります。下部にモードと書いてあります。
EmacsをUnicode(UTF-16
リトルエンディアン)でエンコードされたXMLファイルを編集すると、エンコードがUTF-16
ビッグエンディアンに変更されます。多分それは彼が話していることです。
しかし、BOMはまだあり、からfffe
に変更されffef
、ヌルは偶数バイトではなく奇数バイトにあります。hexl-modeで確認できます。
サンプルxmlファイル。encoding属性は、emacsがxml-modeまたはnxml-modeで保存するときにエンコードを指示します。将来のバージョンでは、最初にBOMをチェックするようにパッチが適用されます。
<?xml version="1.0" encoding="UTF-16"?>
<hi />
EmacsはUTF-16
として受け取るように見えますがUTF-16BE
、Windowsはそれを受け取りますUTF-16LE
(BEとLEはEmacsでエンコード属性として機能しません)。エンコーディング属性は、おそらくここでの問題の鍵となります。
powershellに保存すると、utf-16leに変換されます。
[xml]$xml = get-content test.xml; $xml.save('test.xml')
encoding = "UTF-16LE"とencoding = "UTF-16BE"を使用すると、bomが削除され、ファイルがemacsで認識されなくなります。これはパッチが適用される確認済みのバグです:http : //lists.gnu.org/archive/html/bug-gnu-emacs/2019-05/msg00892.html