チケット #37649

MIME デコード時に UTF-8 BOM を削除していない

登録: 2017-11-09 20:18 最終更新: 2018-01-03 23:37

報告者:
担当者:
チケットの種類:
状況:
オープン [担当者決定済み]
コンポーネント:
(未割り当て)
マイルストーン:
(未割り当て)
優先度:
5 - 中
重要度:
5 - 中
解決法:
なし

詳細

題記の通りです。MIME で UTF-8 エンコーディング、BOMありでエンコードしたものを nkf で UTF-8 エンコーディング、BOMありでデコードすると、BOMが2個ついてしまいます。

@hyades:~/skf/skftst$ jxd aiu.txt
00000000 82 a0 82 a2 82 a4 0a                             .......
@hyades:~/skf/skftst$ nkf -S -w8 -M aiu.txt | nkf -w8 -m | jxd
00000000 ef bb bf ef bb bf e3 81  82 e3 81 84 e3 81 86 0a  ................
@hyades:~/skf/skftst$

添付ファイルリスト

添付ファイルはありません

チケットの履歴 (9 件中 3 件表示)

2017-11-09 20:18 更新者: efialtes
  • 新しいチケット "MIME デコード時に UTF-8 BOM を削除していない" が作成されました
2017-12-24 22:16 更新者: naruse
  • 詳細が更新されました
コメント

MIME decodeでBOMって無条件に削除してしまってよいのですっけ。 まぁ現実的にはほぼ全てのケースで消してよいとは思うのですが。

2017-12-28 00:04 更新者: efialtes
コメント

入力に BOM が付いていることと、出力に BOM をつけるべきかどうかは全く独立の話でしょう。持ち回っていること自体太い間違いだと思います。

2017-12-28 02:09 更新者: naruse
コメント

まず出力側で言うと、nkfはストリーム中のU+FEFFは"ZERO WIDTH NO-BREAK SPACE"という文字だとして扱っています。 文字扱いなので、出力時にBOM付きを指定した場合、何も考えずにさらにBOMをつけ加えるのは意図した挙動です。

問題は入力で、通常ルートでの入力ではnkfは自動でBOMを認識して削除します。

一方、エンコーディングが外部から与えられる仕組みである、MIME下でBOMとみなすべきなのかがよくわかりません。 基本的にはそのようなケースでは内容に対してはフィルタは中立であった方がよいという考えでいますが、 現実のBOM付きのUTF-8をMIMEで出力するメールアプリケーションなりが存在するならば考慮します。

2017-12-28 21:01 更新者: efialtes
コメント

間違いだと思います。Unicode 仕様 (例えば Unicode 10.0 p.866) には

Systems that use the byte order mark must recognize when an initial U+FEFF signals the byte order.

となっているので、ZERO WIDTH NO-BREAK SPACE と解釈する上に BOM をつけるという解釈はあり得ないです。

2017-12-29 00:07 更新者: naruse
コメント

その記述でいえば、nkf -w8 -mの入力側、つまりMIME encoded wordのdecoderは "Systems that use the byte order mark"ではないと考えています。 大きくいえば、前の段落でいう"Where the byte order is explicitly specified"の場合を慣用出来る状態ですね。

一方で出力側はそうしたSystemsなので同段落の後半に記述される "To represent an initial U+FEFF zero width no-break space in a UTF-16 file, use U+FEFF twice in a row. The first one is a byte order mark; the second one is the initial zero width no-break space. See Table 23-6 for a summary of encoding scheme signatures." と類似した状況だと考えます。

2017-12-31 10:54 更新者: efialtes
コメント

でも、現に nkf の MIME encoder 側の出力は U+FEFF を BOM としてつけているわけで、首尾一貫していないし、仕様違反だと思います。また、MIME の時だけ BOM を用いないシステムに化けるのはどう考えてもおかしい。 MIME以外でも一貫して UTF-8 BOM をつけない、入力側は ZWNBSP として扱うなら仕様違反ではないですが。

また、そもそも現在の仕様では ZWNBSP は使うべきではない (should not) なので、ZWNBSP に配慮する必要はあまり感じられない。

2017-12-31 11:11 更新者: efialtes
コメント

もうひとつ、

「一方で出力側はそうしたSystemsなので同段落の後半に記述される "To represent an initial U+FEFF zero width no-break space in a UTF-16 file, use U+FEFF twice in a row. The first one is a byte order mark; the second one is the initial zero width no-break space. See Table 23-6 for a summary of encoding scheme signatures." と類似した状況だと考えます。」

現時点で、UTF-8 MIME で U+FEFF, U+FEFF というシーケンスがあったら ZWNBSP 二個と解釈されるので、"To represent an initial U+FEFF zero width no-break space in a UTF-16 file, use U+FEFF twice in a row. The first one is a byte order mark" にはなりません。全然類似した状況ではないと思います。

2018-01-03 23:37 更新者: naruse
コメント

でも、現に nkf の MIME encoder 側の出力は U+FEFF を BOM としてつけているわけで、首尾一貫していないし、仕様違反だと思います。また、MIME の時だけ BOM を用いないシステムに化けるのはどう考えてもおかしい。 MIME以外でも一貫して UTF-8 BOM をつけない、入力側は ZWNBSP として扱うなら仕様違反ではないですが。

-w8 ではなく -w を使えばそうなりますね。 言い換えれば、明示的にBOMをつけているとみなしているので、なぜMIMEでBOMをつけたいのかよくわかりませんが、指定通りにつけています。

編集

ログインしていません。ログインしていない状態では、コメントに記載者の記録が残りません。 » ログインする