回答編集履歴
3
修正
answer
CHANGED
|
@@ -10,11 +10,17 @@
|
|
|
10
10
|
以下の通り修正いたします。
|
|
11
11
|
|
|
12
12
|
## ISO-2022-JP か UTF-8 かの問題(蛇足)
|
|
13
|
-
メールの送信では、7bit データのみをテキストとみなします。
|
|
13
|
+
~~メールの送信では、7bit データのみをテキストとみなします。
|
|
14
14
|
そのため、過去には 素の 8bit テキストの送信で中途半端なサーバ対応(過剰な自動エンコードや従来から言われている 8bit 未対応)により、問題が発生していた時期もありました。
|
|
15
|
-
そのため、UTF-8(8bit charset) は避けるほうが良いとの判断がなされていました。
|
|
15
|
+
そのため、UTF-8(8bit charset) は避けるほうが良いとの判断がなされていました。~~
|
|
16
|
+
|
|
17
|
+
元々メールの送信は、7bit データのみをテキストとみなしていました。
|
|
18
|
+
そのため、素の 8bit テキストを送信すると中途半端なサーバ対応(過剰な自動エンコードや従来から言われている 8bit 未対応)により、問題が発生していた時期がありました。
|
|
19
|
+
その影響で、UTF-8(8bit charset) は避けるほうが良いとの判断がなされていました。
|
|
20
|
+
|
|
16
21
|
また、クライアントの対応でも UTF-8 の取扱には問題が発生していたようです。
|
|
22
|
+
|
|
17
|
-
しかし、UTF-8 での送信で 7bit へ適切にエンコード(base64, quoted-printable) すれば、クライアントも
|
|
23
|
+
しかし、UTF-8 での送信で 7bit へ適切にエンコード(base64, quoted-printable) すれば、現在ではクライアントも正しくデコードするので、UTF-8 での送信も問題ありません。
|
|
18
24
|
**つまり、ISO-2022-JP と UTF-8 のどちらを選択しても正しい手法で送信すれば、問題は発生しません**
|
|
19
25
|
**ただし上記は、メール本文の話です。**
|
|
20
26
|
|
2
微修正
answer
CHANGED
|
@@ -14,7 +14,7 @@
|
|
|
14
14
|
そのため、過去には 素の 8bit テキストの送信で中途半端なサーバ対応(過剰な自動エンコードや従来から言われている 8bit 未対応)により、問題が発生していた時期もありました。
|
|
15
15
|
そのため、UTF-8(8bit charset) は避けるほうが良いとの判断がなされていました。
|
|
16
16
|
また、クライアントの対応でも UTF-8 の取扱には問題が発生していたようです。
|
|
17
|
-
しかし、
|
|
17
|
+
しかし、UTF-8 での送信で 7bit へ適切にエンコード(base64, quoted-printable) すれば、クライアントも昨今では正しくデコードするので、UTF-8 での送信も問題ありません。
|
|
18
18
|
**つまり、ISO-2022-JP と UTF-8 のどちらを選択しても正しい手法で送信すれば、問題は発生しません**
|
|
19
19
|
**ただし上記は、メール本文の話です。**
|
|
20
20
|
|
1
修正
answer
CHANGED
|
@@ -1,5 +1,34 @@
|
|
|
1
|
-
ISO-2022-JP か UTF-8 かの問題は、中継サーバが 8bit に対応しているかどうかがポイントなので、届いたあとの処理にはおおよそ関係ないです。
|
|
1
|
+
~~ISO-2022-JP か UTF-8 かの問題は、中継サーバが 8bit に対応しているかどうかがポイントなので、届いたあとの処理にはおおよそ関係ないです。
|
|
2
|
-
なので、今回発生している問題と「使ってもいいのか？」の間にはおおよそ関係がありません。
|
|
2
|
+
なので、今回発生している問題と「使ってもいいのか？」の間にはおおよそ関係がありません。~~
|
|
3
3
|
|
|
4
|
-
なぜおおよそだらけかと言うと、Gmail が独自処理で解釈して表示している可能性があるからです。本件の対象メールを確認しない限り特定できないですが、対象メールが開示されれば、ちゃんと正しいフォーマットになっているかどうか確認してくれる人が出てくるかもしれません。
|
|
4
|
+
~~なぜおおよそだらけかと言うと、Gmail が独自処理で解釈して表示している可能性があるからです。本件の対象メールを確認しない限り特定できないですが、対象メールが開示されれば、ちゃんと正しいフォーマットになっているかどうか確認してくれる人が出てくるかもしれません。
|
|
5
|
-
＊私はめんどいので確認しません。
|
|
5
|
+
＊私はめんどいので確認しません。~~
|
|
6
|
+
|
|
7
|
+
# 指摘を受けての修正
|
|
8
|
+
本回答に対して、誤りがあるという指摘をいただきましたので、関連情報を再整理しました。
|
|
9
|
+
メール本文とヘッダの仕様の違いに対して言及がなく、かつヘッダに関しては記述がなかったので質問に対して誤った回答でした。
|
|
10
|
+
以下の通り修正いたします。
|
|
11
|
+
|
|
12
|
+
## ISO-2022-JP か UTF-8 かの問題(蛇足)
|
|
13
|
+
メールの送信では、7bit データのみをテキストとみなします。
|
|
14
|
+
そのため、過去には 素の 8bit テキストの送信で中途半端なサーバ対応(過剰な自動エンコードや従来から言われている 8bit 未対応)により、問題が発生していた時期もありました。
|
|
15
|
+
そのため、UTF-8(8bit charset) は避けるほうが良いとの判断がなされていました。
|
|
16
|
+
また、クライアントの対応でも UTF-8 の取扱には問題が発生していたようです。
|
|
17
|
+
しかし、昨今では UTF-8 で送信しても 7bit へ適切にエンコード(base64, quoted-printable) され受け取り側も正しくデコードするので、UTF-8 での送信も問題ありません。
|
|
18
|
+
**つまり、ISO-2022-JP と UTF-8 のどちらを選択しても正しい手法で送信すれば、問題は発生しません**
|
|
19
|
+
**ただし上記は、メール本文の話です。**
|
|
20
|
+
|
|
21
|
+
**以下はヘッダの日本語記述に関してです**
|
|
22
|
+
メールのヘッダ(subject from 等)に関しては、本文に対しての仕様とは別のルールが存在します。
|
|
23
|
+
ヘッダの値で日本語文字列を使用するには、charset の指定と共にエンコードが必須となります。
|
|
24
|
+
```
|
|
25
|
+
"=?" charset "?" encoding "?" encoded-text "?="
|
|
26
|
+
```
|
|
27
|
+
エンコードされることで ISO-2022-JP と UTF-8 のいずれであっても、7bit テキストとして伝送されます。
|
|
28
|
+
つまり、**ヘッダでも ISO-2022-JP と UTF-8 のいずれを選んでも問題ないです**
|
|
29
|
+
|
|
30
|
+
## teratail から送られてくる mail の subject encode は正しいのか(本論)
|
|
31
|
+
結論としては変わらないのですが、ISO-2022-JP と UTF-8 の選択による問題は発生しません。
|
|
32
|
+
問題は、charset の選定以外にあります。
|
|
33
|
+
なんらかの不整合を Gmail は(賢く適当に)対応し、Windows 10 標準のメーラーは対応できなかったものと思われます。今ある情報では、エンコードの問題なのか、フォーマットの問題なのかそれ以外なのか、切り分けが出来ません。
|
|
34
|
+
**つまり対象メールがソースごと開示されなければ判断できないです**
|