Ticket #37649

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

Open Date: 2017-11-09 20:18 Last Update: 2018-12-15 17:44

Reporter:
Owner:
Type:
Status:
Closed
Component:
(None)
MileStone:
(None)
Priority:
5 - Medium
Severity:
5 - Medium
Resolution:
Invalid

Details

題記の通りです。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$

Attachment File List

No attachments

Ticket History (3/10 Histories)

2017-11-09 20:18 Updated by: efialtes
  • New Ticket "MIME デコード時に UTF-8 BOM を削除していない" created
2017-12-24 22:16 Updated by: naruse
  • Details Updated
Comment

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

2017-12-28 00:04 Updated by: efialtes
Comment

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

2017-12-28 02:09 Updated by: naruse
Comment

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

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

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

2017-12-28 21:01 Updated by: efialtes
Comment

間違いだと思います。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 Updated by: naruse
Comment

その記述でいえば、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 Updated by: efialtes
Comment

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

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

2017-12-31 11:11 Updated by: efialtes
Comment

もうひとつ、

「一方で出力側はそうした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 Updated by: naruse
Comment

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

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

2018-12-15 17:44 Updated by: naruse
  • Status Update from Open to Closed
  • Resolution Update from None to Invalid

Edit

You are not logged in. I you are not logged in, your comment will be treated as an anonymous post. » Login