Q&A
>Windows 10 標準のメーラーで、 Gmail のメールを取り込んだら
自己都合なので自己責任では。
Windows 10 標準のメーラーで、 Gmail のメールを取り込んだら、 teratail のメール だけ 、題名が decode されない。
メールに使う文字コードには色々と問題があるが、とりあえず JIS (ISO-2022-JP) を使っとけば間違いなし！という認識です、私は。
ということで、
utf-8 は使ってもいいのか？ subuject とかに。もちろん CC, BCC も含めて。
みなさんの意見をお聞かせください。
メーラーを作成するのはプログラミングです。昔、 WebMail とか作っていました。
たとえば、グラフィックソフトで、 PNG ファイルを作って、それをほかのグラフィックソフトで使えなかったら、どうしますか？ 自己都合なので自己責任なのでしょうか。
なぜプログラミングに関係がないのか、関係性がない具体的な理由をお聞かせください。
抽象すぎて、理解ができません。
メーラーを自分で作っているなら修正して対応してください。他人の作ったものならプログラミングに関係ないでしょう。
プログラミングとはプログラムを使うことではなく作ることです。自動車に乗る人が「この道は一方通行ですか？」と尋ねるのは自動車の製造に関係ない質問です。
これで理解できますか？
すばらしい！
理解できました。作っている本人が悩んでいることを質問するのが、正しい使い方で、他人が作ったモノに対して、それどうなの？と質問するのは、おかしい。
という認識をしました。
けど、プログラミングはプログラミングです。 teratail にはふさわしくないと言われたら納得しますが、プログラミングではないということには、まったく理解できません。
「teratail のメール 」が具体的になんのメールのことか知りませんが、送信側は相手がどう使うか知らないわけですよね。
メーラーが何かとか。それはともかくGMailに取り込むとかあなたの自己都合でしかないじゃないですか。
単に受信したメールが文字化けするとかならともかく、他のメーラーに取り込むという既に大元から離れたことをやってるわけですよね。
Windows10タグしかつけてないのに抽象的だなんだ騒ぐのは自身の質問の仕方を見直してからだと思います。
理解できていません。他人の作った小説を読むのは小説の執筆ですか？
あと、自動車は道路交通法に合わせて作りません。一方通行や二車線やら信号やら、関係ありません。ちょっと比喩がおかしいと思います。
ワードで文章を作るのはプログラミングですか？ エクセルで表計算するのはプログラミングですか？ メーラーでメールを読むのはプログラミングですか？
規格はありますよ、3ナンバー ５ナンバー、とか軽自動車とか。それには合わせて作ります。
UTF-8 メールに対応していないメーラーで取り込んで文字化けするのはプログラミングですか？
メールに UTF-8 を使っていいかどうかというのにイエスノーで答えるなら、使っていいです。対応してない方が悪い、そしてそれを選ぶ方が悪い、それだけです。
「Windows 10 標準のメーラーで、 Gmail のメールを取り込んだら、 teratail のメール だけ」というのは、『teratailから送られてくるメールはGmailを利用している』、『teratail から送られてくるのメール だけ 、題名が decode されていない』（題名は、どんなコードで送られてくるのかなぁ？）、それで「teratailの運営組織は、『utf-8 は使ってもいいのか？ subuject とかに。もちろん CC, BCC も含めて』と問題提起している」という話の流れですか？
質問の意図が理解できなくて困っています。
すいません。 "だけ" は嫌味がはいっています。いまどき、decode されないメールがくるなんて、なんてことだ！ と感情的になってしまいました。
質問にも書いてある通り、 JIS 使っとけば問題は最小限にすむ。という、認識をしているので、 JIS を使うのが一般常識。
しかし、それが果たして本当に一般常識なのか、それを知りたかった。 Windows は世界で販売されていて、その世界で販売されている OS を使っていて問題が出る。それって、なぜなの？ と思ったからです。
"メールに UTF-8 を使っていいかどうかというのにイエスノーで答えるなら、使っていいです。"
これが客観的な意見ですね。
"対応してない方が悪い、そしてそれを選ぶ方が悪い"
これは主観ですね。しかし、さすがに Microsoft におかしいとはいえなかったりします。ヨーロッパや北米で、バグだ！って Microsoft に提訴しているのでしょうか。私なら提訴しません。
で、Windows10の質問は何でしょうか
タグがそれしかなかったので、一番関係性があるのを選択しました。
それが間違っているのは、承知しています。もうしわけありません。
Windows 10の質問ではありません。
文字化けのバグごときでいちいち提訴しないでしょう。他に乗り換えるだけです。
ではタグを修正してください。本当にWindows10の質問や回答をする人に迷惑です。
「teratailから送られるメール」なら「teratail」タグだけで良いです
例えばメモ帳で UTF-8 BOM 無しのテキストは保存できません。これを改良するのは提訴でなく要望申請になりますし、メモ帳が低機能だということはみんな知っています。
Linux などと違って Windows 備え付けのアクセサリーはみな低機能なおまけです。
わかりました！タグを修正します。ありがとうございます！
使っているソフトの話ではないです。”ということで。” を入れたことで、前置きがあって、その次に本題を書いたつもりでした。そして、本題について意見が来ると思っていました。前置きで意見がくるとはとは思っていませんでした。
本題については一番始めにリンクしました。それ以降は「プログラミングに関係あるのか」という質問に対する回答です。
「自分で作っているのか」と確認したところ、そうでなさそうな答えが返ってきたのでプログラミングの問題ではなく使用上の問題と判断しています。
質問の意図とちがうのなら明確な表現を使って質問を書き直してください。誰にも伝わっていないようです。
趣旨も「teratail から送られてくる mail の subject encode は正しいのか」ではなさそうですので、タイトルも変更されたほうがよいかと思います。
既に回答で指摘がある通り質問の仕方、書き方の問題です。
前置きなら前置き、本題なら本題ときちんとマークダウン使って伝わりやすいように書いてください。
改行以外にメリハリがない文章で、それすらも覚束なかったら正しく伝わらないのは当然です。
どこにメリハリがないのでしょうか。
初めの１文には、”されない” と断定しています。
次の文では、”という認識です、私は” と主観を書いています。
”と、いうことで” という一文をいれています。
これで、メリハリがないとは、どういうことでしょうか？
少なくとも私にはプログラミングに関係のない質問に見えましたし、他にも複数そう読んだ人がいるようです。
また質問の意図が不明なので同じ質問へのリンクをここに記載するにとどめ、回答を控えました。
teratail ではタイトルと本文前半と後半がちぐはぐな質問が数多くあります。その場合、どれが本題なのかは回答者が見極めなければなりませんが、この質問は前置きが多く本題が一行で少なすぎます。タイトルとも合っていません。とても読みにくい質問です。
markdown は、書式フォーマットです。文章の書き方とは、およそ関係性がありません。
見出しなり引用なり表現の工夫は幾らでもできるじゃないですか。
現にご自身でも「前置きで意見がくるとは」と仰ってますよね。
メリハリがなければ他人は適当に解釈します。きちんと質問を「誰でも伝わるように」そして「具体的に」記載してください。
（伝わっていないようなので「」で強調しました）
タグについて「teratail」に変更いただきましたが、
趣旨が
「teratailから送られるメール」のSubjectについての議論
ではなく
システムでメール送信する際に「utf-8 は使ってもいいのか？ subuject とかに。もちろん CC, BCC も含めて。」
であれば、「Email」が適切だと思いますのでこちらに変更いただけないでしょうか？
※teratailから送信されるメールだけについての議論であれば 「teratail」のままで問題ないです。
ありがとうございます！ はじめに、 mail としたら出てこなかったので、ないと思っていました。
あと、メリハリがない理由を聞かせてください。そして、具体的ではない理由も。どこに抽象的な文章を書いているのでしょうか？
これだけ指摘して分からないならたぶんあなたにはずっと分かりません。
けんか売ってるなら買うけど。
>mail としたら出てこなかったので
https://teratail.com/tags
Gmail,Email,Sendmail と出てきますが。
いやいや、その返事はおかしいでしょう。文章がおかしいと指摘していて、その指摘がまったく具体性がない。それじゃ、治しようがないじゃないですか。
主観的すぎ、あなたが理解できないから、ほかの人も理解できないって、おかしくないですか？
これだけみんなわかんないって言ってるのにまだそういうことを言う？
私は、私が理解できないからほかの人も理解できないと思っていないから、なぜ理解できないのか聞いているのです。
私はこれで理解できます。私なら理解できる文章をかきました。でも理解できない人がいるから、理解してもらうために、理解できない理由を聞いているのです。そして直したり説明したりしています。具体的に。
それにたいして、”これだけ指摘している” とか、どこに具体的な指摘をしているのでしょうか。指摘もしていないのに、これだけ指摘していると、なぜ言えるのでしょうか？
伝えたいことを知ってるのはあなただけ。なら伝えたいことを伝わるように書けるのもあなただけ。
指摘は具体的。要約すると「何聞きたいか分からない」
それとも要件伝えられてない人たちに「(自分では伝わるように書ける文章力がないから)代わりにお前が書け」ってことでしょうか。
まず聞きますが、質問の正確な意図は誰に伝わっていますか？
意図のわからないものをこちらで直して具体化しろってむちゃくちゃでしょ。
どこがわからないかは具体的に複数の人から尋ねられています。具体的に。
これどこまで本気なんですか？
エイプリルフールなら終わりましたよ。
>markdown は、書式フォーマットです。文章の書き方とは、およそ関係性がありません。
伝えたいことを有効に伝えるための手段としても使えます。
前提と主題がわかりづらいのは明白。そこに見出しをつければ読む側も間違いなくそのつもりで読む。
あなた文中に太字使ってますよね？なんのため？目立たせたいからでしょ？
私の指摘「メリハリがない」はそのことです。具体的に書いてるじゃないですか。
自分が分かるようにしか書けないならQiitaに備忘録でも投稿しておいてください。自分しか見れないように。
他人に意見を求めるなら他人に理解できる文章を心がけてください。
https://teratail.com/help/avoid-asking
「みなさんの意見をお聞かせください。」的な質問は推奨されていないとのことです。
teratailからのメールのヘッダエンコーディングがおかしいことについては過去にも質問があります。「tag:teratail tag:メール」で検索して、私の回答とそのコメントを読んで下さい。
当時、運営にはメールで、根本的な解決策 (CakeEmailをやめることを含む) と当面の回避策 (直りはしないがましになる) とを提案しましたが、回避策のほうが採用されました。そういうわけで、おかしいままです。
では離脱します。
回答5件
0
質問のタイトル、質問本文に複数の質問内容が混在しているので
本当に質問なさりたいことを整理して質問タイトル、本文を修正した方が良いと思います。
- teratail から送られてくる mail の subject encode は正しいのか
回答：
タイトルで記載されている質問文に対してして回答すると、正しいです。
- Windows 10 標準のメーラーで、 Gmail のメールを取り込んだら、 teratail のメール だけ 、題名が decode されない。
回答1：
Windows10の標準メーラーの仕様（または不具合）。
Microsoftに要望を出しましょう。
対応されるかもしれません。（対応されないかもしれません）
回答2：
teratailに意見として要望を出しましょう。
対応されるかもしれません。（対応されないかもしれません）
- utf-8 は使ってもいいのか？
メールを送信するシステム（プログラム）を作成している前提で、
メール送信の際にメールヘッダー内でutf-8を使用することの是非を問われている。
回答：
これは、Zuishin さんがコメントされている
メールの文字コードはUTF-8でOK？
と同じ質問となりますのでこちらを参照ください。
参照した結果、問題が解決しない場合は、具体的に何がどう解決しておらず何が問題となっているのかを質問に追記いただければと思います。
投稿2019/04/03 03:12
総合スコア7914
”ということで” を入れていて、前置きには、現象や症状を書いているだけで、質問や回答を求めている文章ではありません。そこを、突っ込まれるのはなぜなのでしょうか？
・タイトルが「teratail から送られてくる mail の subject encode は正しいのか」なので
質問の要約がこのタイトル記載の内容で
この質問タイトルに至った現象（症状）が「Windows 10 標準のメーラーで、 Gmail のメールを取り込んだら、 teratail のメール だけ 、題名が decode されない。」
・「ということで」は、
「メールに使う文字コードには色々と問題があるが、とりあえず JIS (ISO-2022-JP) を使っとけば間違いなし！という認識です、私は。」にかかると読みました。
ヘルプの（質問するときのヒント）に記載されている
3. 正しく伝わる質問の仕方 https://teratail.com/help/question-tips#questionTips3
を一読していただき、質問する際の参考にされてはどうでしょうか？
質問のコメントから。（長くなるのでこちらに移動しました。）
> 私は、私が理解できないからほかの人も理解できないと思っていないから、なぜ理解できないのか聞いているのです。
今回の私の回答に至った経緯。
私はタイトルと最初の３行くらいで質問内容を把握します。
質問者さんは一番困っていて解決したいことを最初に記述すると私は思っていますので。
ここにそれっぽいことが記載されていると、そのあとの記述も
すべてそれに引っ張られて解釈するので誤解が生まれます。
（ただし、見出しで「経緯」など記載があれば誤解しないです。）
何度か質問を読み返して3通りの解釈ができるため回答を3パターン記載しました。
＞そこを、突っ込まれるのはなぜなのでしょうか？
の回答になってますでしょうか？
0
私もISO-2022-JP派ですが、utf-8を使ってはいけない理由もないかと思います。
他の回答のコメントにも書きましたが、utf-8でのContent-Transfer-Encoding: 8bit派は少数派のようです。ほとんどのutf-8メールは7bitです。utf-8で7bitだと効率が悪い（データ長の意味で）と思いますが、そもそも日本語について言うとutf-8の時点で効率悪いので。
うちに届いたメールをざっと見てみましたが、
・昔からある大手日本企業はISO-2022-JP派が多い。utf-8派もあり
・Teratailも含んだような、ネット系というかウェブ系というか、そういう企業はutf-8が多数派
・外資系は国内企業でもまず間違いなくutf-8派
・プロバイダのウェブメールらしき物はどちらが多数派かよく分からない。若干utf-8が多い気がする
・携帯メールはうちの場合サンプル数が少ないのでよく分からない
ただ、なんとAndroid携帯から、From: =?Shift_JIS?B?～～～というメールも有り
まあ、あくまでうちに届いたメールですが。
タイトルの、
teratail から送られてくる mail の subject encode は正しいのか
に関して言うと、RFC2047に、
While there is no limit to the length of a multiple-line header field,
each line of a header field that contains one or more 'encoded-word's is limited to 76 characters.
とありますが、Teratailから来る「otnさんの活動レポートをお送りします」というメールはこれを満たしていないので、「正しくない」と言うことになるでしょう。そんなこと気にせずにデコードしてくれるメーラーが多いとは思いますが。
余談：
1980年代だと、生のISO-2022-JPが通らない中継ノードもめずらしくなかったですね。ESCを落としてしまう。なので、$Bや(Bの前にESCを補うプログラムが作られたりしてました。
投稿2019/04/03 13:29
編集2019/04/08 04:24
総合スコア84533
0
ISO-2022-JP か UTF-8 かの問題は、中継サーバが 8bit に対応しているかどうかがポイントなので、届いたあとの処理にはおおよそ関係ないです。
なので、今回発生している問題と「使ってもいいのか？」の間にはおおよそ関係がありません。
なぜおおよそだらけかと言うと、Gmail が独自処理で解釈して表示している可能性があるからです。本件の対象メールを確認しない限り特定できないですが、対象メールが開示されれば、ちゃんと正しいフォーマットになっているかどうか確認してくれる人が出てくるかもしれません。
＊私はめんどいので確認しません。
指摘を受けての修正
本回答に対して、誤りがあるという指摘をいただきましたので、関連情報を再整理しました。
メール本文とヘッダの仕様の違いに対して言及がなく、かつヘッダに関しては記述がなかったので質問に対して誤った回答でした。
以下の通り修正いたします。
ISO-2022-JP か UTF-8 かの問題(蛇足)
メールの送信では、7bit データのみをテキストとみなします。
そのため、過去には 素の 8bit テキストの送信で中途半端なサーバ対応(過剰な自動エンコードや従来から言われている 8bit 未対応)により、問題が発生していた時期もありました。
そのため、UTF-8(8bit charset) は避けるほうが良いとの判断がなされていました。
元々メールの送信は、7bit データのみをテキストとみなしていました。
そのため、素の 8bit テキストを送信すると中途半端なサーバ対応(過剰な自動エンコードや従来から言われている 8bit 未対応)により、問題が発生していた時期がありました。
その影響で、UTF-8(8bit charset) は避けるほうが良いとの判断がなされていました。
また、クライアントの対応でも UTF-8 の取扱には問題が発生していたようです。
しかし、UTF-8 での送信で 7bit へ適切にエンコード(base64, quoted-printable) すれば、現在ではクライアントも正しくデコードするので、UTF-8 での送信も問題ありません。
つまり、ISO-2022-JP と UTF-8 のどちらを選択しても正しい手法で送信すれば、問題は発生しません
ただし上記は、メール本文の話です。
以下はヘッダの日本語記述に関してです
メールのヘッダ(subject from 等)に関しては、本文に対しての仕様とは別のルールが存在します。
ヘッダの値で日本語文字列を使用するには、charset の指定と共にエンコードが必須となります。
"=?" charset "?" encoding "?" encoded-text "?="
エンコードされることで ISO-2022-JP と UTF-8 のいずれであっても、7bit テキストとして伝送されます。
つまり、ヘッダでも ISO-2022-JP と UTF-8 のいずれを選んでも問題ないです
teratail から送られてくる mail の subject encode は正しいのか(本論)
結論としては変わらないのですが、ISO-2022-JP と UTF-8 の選択による問題は発生しません。
問題は、charset の選定以外にあります。
なんらかの不整合を Gmail は(賢く適当に)対応し、Windows 10 標準のメーラーは対応できなかったものと思われます。今ある情報では、エンコードの問題なのか、フォーマットの問題なのかそれ以外なのか、切り分けが出来ません。
つまり対象メールがソースごと開示されなければ判断できないです
投稿2019/04/03 03:12
編集2019/04/07 23:19
退会済みユーザー
総合スコア0
"ISO-2022-JP か UTF-8 かの問題は、中継サーバが 8bit に対応しているかどうかがポイントなので”
ありがとうございます！
しかし、 8bit に対応してない可能性もあるから、 7bit にしとこう。というのが私の意見。
で、使っていいのか？にもかかってくるとおもいます。関係性はあるかと思います。
Gmail のクライアントで表示されている以上、おおよそ関係ないです。
「mail utf8」でぐぐって出てくるのを一通り読んでみよう。
>「mail utf8」でぐぐって
結局これだけでいい気がしてきた
いや、中継サーバーを返してメールが届いているので、関係性はあるのではないのでしょうか。
"理由にはならない" のならわかります。中継サーバーが、どうであれ、それを理由に 7bit にするのか 8bit にするのなら。というのならわかりますが。
日本の郵便屋さんは関係ない。住所をアラビア語で書いても。そうですか？運ぶのは日本人なので、日本語で住所を書いた方がよくありませんか？関係性はあると思います。
あーすまん。
コメントもらうタイミングで、一つ前のコメント編集してしまった＾＾；
Gmail のサーバには、エンコード関係なく文字化けしないものが「届いて」います。
たとえ話は嫌いですが、届いたあとの手紙を虫眼鏡で見ようが眼鏡越しに見ようが、文字が変化することはありません。
変化するなら、虫眼鏡かメガネがおかしいです。郵便屋はアラビア語でもちゃんと届けてくれているので。
「mail utf8」でぐぐって出てくるのを一通り読んでみよう。
あーこの喩えはダメだな＾＾；
原理を理解すると良いです。なぜ 7bit で送らなければならなかったか？8 bit だとどこに問題が発生するか？
すると、Gmail のクライアントで表示された時点で、エンコード問題はおおよそクライアントの問題であると切り分けられます。
utf-8のメールで、8bitのまま送られてくることはまず無くて、7bitにエンコードされていると思いますよ。
まぁ、質問の内容だけだと分からないですよね＾＾；対象のメール開示されたら現象の原因わかるかもしれないですけど。
> teratail のメール だけ 、題名が decode されない
の問題についてはそうですね。何ビットとも書いてない。私のコメントは、ビット数に言及している
> ISO-2022-JP か UTF-8 かの問題は、中継サーバが 8bit に対応しているかどうかがポイント
についてです。
utf-8 + Base64 なら ISO-2022-JP と条件変わらんよ(間に 7bit サーバあっても問題ないよ)。って指摘と認識しましたがあってます？
"ISO-2022-JP か UTF-8 かの問題は、中継サーバが 8bit に対応しているかどうかがポイントなので”
んなわけないだろ。-1。
> utf-8 + Base64 なら
そうですね。
utf-8 + quoted-printable というケースも多いですね。日本語の場合Base64より効率悪いですが。
> ikedas さん otn さん
質問では「Gmail のメールを取り込んだら、 teratail のメール だけ 、題名が decode されない」ことの原因を、ISO-2022-JP か UTF-8 かの問題と捉えています。で、その場合、中継サーバが 8bit に対応しているかどうかがポイントと回答しています。今回は、Gmail では表示されているので、7bit 8bit の問題はおよそ関係ないというのが回答主旨です。
で、原因に関しての言及は、メールソースが開示されないと追求できないとしています。これは、Gmail が賢く、よしなにやっている可能性があるので、クライアントの問題でしょうという回答です。
この辺はコメントでも触れています。
otn さんの回答のように、フォーマットが適切でないものを Gmail は賢く読んだけど、Windows 10 標準のメーラーでは読めなかったってのが現象の原因かもしれないですね。
ただ、それは対象メールが開示されないと判定できないと思っています。
ろくに調べもしないで自分の推測をあたかも事実かのように堂々と書くのいい加減やめてくれないか。入会以来まったく進歩ないのな。
そんなに自己顕示欲満たしたいのならせめてほかの場所行ってやってくれ。
もちろん、あなたの回答のどこがおかしいのかはいちいち教えてあげないから自分で基礎からある程度の高度な内容まで学習し直してください。
それまでは、ここteratail で、少なくとも電子メール関連の質問には関わらないでくれませんか。
(電子メール関連だけじゃないのだが、いちいち指摘して回るのは一苦労だし、私はあなたのお母さんでもないので、全部は言ってあげません。自分で考えて何とかしてください)。
別にオレの回答にコメントいらんから、回答つければ？
あなたの知ったかぶりののでたらめを打ち消すために私が回答して回れっちゅうの? わからないのなら、そして何が分かってないのかも分からないのなら回答しないでくれ。teratailの品質向上にご協力ください。
いいと思った回答には＋1しときました (もうたくさんついてるのにはつけなかったけどね)。あなたのでたらめの見た目のもっともらしさに騙される人がいると評価が評価として機能しなくなるのよ。人に尻拭いを頼る前にあなたが変われ。
間違いがあればコメントできるし、回答もできるシステムになっているのよ。
ってことは、品質向上したいならあなたが手を動かせば可能ということなの。
人を変えるより、自分を変えるほうが現実的なのよ。
これが理解できないのなら、退会すれば？
品質保つためには、全く質問にも回答にも関係ないコメントつけるより有意義よ。
って、もしかしたらあなたのお母さんは言ってるかもしれない！
> メールの送信では、7bit データのみをテキストとみなします。
誤り。仮にそういう時期があったとしても、遅くとも1993年以降はそうではなくなっている。相変わらず調べてないでやんの。それとも前世紀からタイムリープしてきた人か?
> そのため、過去には 素の 8bit テキストの送信で中途半端なサーバ対応(過剰な自動エンコードや従来から言われている 8bit 未対応)により、問題が発生していた時期もありました。
根拠を示さない知ったかぶり。そういう事実があったのなら、あなただけが知っているはずがないから「言われていた」ことを示す信頼できる資料を示せ。
ところで最初から思っているのだが、あなたの言う「中継サーバ」とやらはいちいちメッセージヘッダをデコードしているのか? もちろんそういうものもあるだろうが、そこは電子メール配送の本質ではないので「8ビット対応がポイント」ではないのよ。
> そのため、UTF-8(8bit charset) は避けるほうが良いとの判断がなされていました。
また、クライアントの対応でも UTF-8 の取扱には問題が発生していたようです。
知ったかぶりから導き出した推測。上記参照。
私は「基礎からある程度の高度な内容まで学習し直してくれ」と書いたはずだ。そうしないと、あなたは間違った理由を説明されても理解できないからだ。
それだけのことをたった1日あまりで学習できたのか? そんな筈はないよな。
なら今までは、学習の成果を生かさずにわざわざでたらめを書いていたのか? だったらあなたのやっていることはteratailとその利用者にとって害毒でしかないので今すぐ退会してくれ。
少なくとも、今後はあなたのでたらめを回答だなどと称してばらまくことはやめろ。teratailはあなたの屑篭ではない。
> 誤り。仮にそういう時期があったとしても、遅くとも1993年以降はそうではなくなっている。相変わらず調べてないでやんの。それとも前世紀からタイムリープしてきた人か?
指摘さんきゅ。某所からのコピペ後の編集ミスです。タイムリープはしてないけど、1993年以前の話ですね。
直後の 8bit ～ とも文章的につながらんね＾＾；
全体の文言を少し見直し、修正しました。
> 根拠を示さない知ったかぶり。そういう事実があったのなら、あなただけが知っているはずがないから「言われていた」ことを示す信頼できる資料を示せ。
＊8bit 未対応サーバに対しての言及
RFC 1428 で、「8bit sender to 7bit non-MIME receiver」の組み合わせで、データ欠損が発生すると記述がある。
＊過剰な自動エンコードに対しての言及
RFC 1428 で非 US-ASCII なメールのオレオレ仕様の乱立が記述されていて、「8 ビットのテキストから Base-64 で符号化された判読不能なテキストや quoted-printable で符号化された “文字化け” のテキストへ変換」するサーバの存在に関しての記述がある。
＊結論
上記通りの事実が発生していたのであろう記事もいくつかあったけど、お母さんも生まれる前の時代の事例なので、事例が正確かどうかは不明。
まぁ、根拠資料としては RFC だけでいいんじゃね？
>> また、クライアントの対応でも UTF-8 の取扱には問題が発生していたようです。
> 知ったかぶり。上記参照。
https://support.microsoft.com/ja-jp/help/881816
MS 系は結構 UTF-8 の文字化け(自動判別ミス)があったみたいよ。
使ってないから知ったかだけどｗ
0
「mail utf8」でぐぐって出てくるのを一通り読んでみよう。はなしはそれから。
投稿2019/04/03 01:55
総合スコア87774
なぜ一通り読む必要があるのでしょうか？具体的に理由を教えてください。
これらのいわゆる「一般常識」をあなたが知っているという前提でないと、最低限の議論が成立しないからです。
質問の文章だけでは、あなたがどういう人間かは推し量ることはできませんから。
一般常識が理解できません。それ、ヨーロッパでも一般常識なのでしょうか？
私が質問しているのは、エンコードの指定ができるからと言って、 utf-8 は使ってもいいのか、ヨーロッパや北米では、 utf-8 を使っているのか。メールに使う 7bit とはどうなっているのか、
など、意見を求めています。
teratail （会社）やら windows 10 (Microsoft) の質問をしているわけではありません。
はい。それが理解できないというのはわかりました。この回答をしたかいがあったというものです。
質問に対する回答になっていない。
同じ知識がないと、正しい議論はできない。これには賛同します。
しかし、そのまえに同じ知識の知識自体が異なっていると判断しました。
私も、あなたとは正しい議論が出来ないと判断しました
はい、それが確認できて私もさいわいです
0
経緯
このまま離脱するつもりだったのですが、まだ片付かないようなので回答として残しときますね。
修正依頼に書きましたが、teratailからのメールのヘッダエンコーディングがおかしいことについては過去にも質問があります。
ほかの回答は「運営に言えば」というもので関係ありません。これの私の回答とそれについているコメントを読んで下さい (当時は入会したてで回答に慣れていなかったもので、本題がコメントで展開されています)。
問題点は
- Q符号化での符号化対象の文字種が規約通りでない。結果として構造化ヘッダの中で使われたときに正しく構文解析できないときがある。
- ヘッダで、RFC5322およびMIMEで推奨されている長い行の折り返しがされていない。
というものです (仔細に見ればほかにも問題はでてくるのではないかと思います)。これは、teratailのメール配信システムが使っているPHPのライブラリであるCakeEmailの問題に起因するものと考えられました。
当時、運営にはメールで、根本的な解決策 (CakeEmailをやめることを含む) と当面の回避策 (直りはしないがましになる) とを提案しましたが、回避策のほうだけが採用されて今にいたっています。そういうわけで、teratailからくるメールのヘッダエンコーディングはおかしいままです。具体例は、お手元のメールソフトで該当するメールのソースを見てください (なお、teratailは内製(?)のシステムのほかにMailChimpも使っていて、こちらもおかしいのですが少しましです)。
回答
経緯説明が長くなりましたが、そういうことがあるので、メールソフトによってはヘッダを正しくデコードできない可能性があります (今回の質問者さんのケースが実際にそうなのかどうかは、実際の表示を見ないとわかりませんが)。
また上の質問で触れられているような仲介者システムによる変換 (想像ですが、アンチスパムやメール発信監査のアプライアンスかなにかを入れているのではないかと思われます) に影響する可能性もあります。
ちなみに、ISO-2022-JPのB符号化ではなくUTF-8のQ符号化を使っていることには特に問題はありません。どちらがいいかというのは状況により判断されることだと思います[1]。
余談
最後に、本題となんの関係もありませんが、一部の熟練ユーザのかたがたによる今回の質問への対応について懸念を表明しておきます。
修正依頼に数十個のコメントがあるのを見て、何事かと思いました。ちょっと読んでみましたが、質問者に「質問のしかたが悪い」と説教する類のものが多く、驚きました。技術者なら事実に基づいて問題を解明しようとするはずです。今回ならまず自分に届いているメールを分析するのではないですか (実例が提示されないと言う人もいましたが、目の前にあるじゃないですか)。何をやっているのやらと思いました。
「ご意見を」という文言から「広く意見を募る質問は禁止」だとか、しまいには「プログラミングに関係ない質問」だとか、こじつけにしか見えません。プログラミングに関係ありありじゃないですか。しかもteratail自身に (これにあおられてか、スコア最上位の回答者さんまで「正しいです」と言い切っちゃってます。正しくはないですよ)。
質問者が、こちらの思った通りの適切なしかたで質問してくれないなんて、よくあることです (プロの方なら、日常の業務でも、お客さんの意味不明な要求や質問にあうことはありますよね)。そういうものを読み取って、質問者もうまく表現できない課題を把握し、論理の通った回答として返すのも、多分に回答者の力量によるのではないですか。
数か月ぶりに来てみて、回答者側の問題発見能力が低下しているのではないと思わされた事例のひとつです。
あと、明らかにおかしい回答をしているのに評価がある回答者もいました。普段から一知半解にキーワードだけをならべたような回答 (それもよくピントがはずれている) をして、ドヤっているような方です。今回、私がひそかに専門分野と自負する電子メールの領域に踏み入ってきましたので、反撃させていただきました。コピペしかしてないって白状したね。
こういうひとでも回答を続けていればスコアが上がって「パワーユーザ」扱いになりますね。こういうことは技術的に解決できないです。質問者に質問のしかたを直させる前に (それが悪いとは言わないですが)、回答者の研鑽を考えるべきなのかもしれない、と思います。
teratailは当分ロゴも見たくない気分なので、これで立ち退きます。また気分が変わったら参加させていただくこともあるかと思いますが、当分はそんなことを考えたくもありません。
注
[1] 参考まで。私自身はここ10年ほど、いくつかのオープンソースプロジェクトに対し、言語の文脈が日本語のときに送出されるメールのヘッダがISO-2022-JPのB符号化になるようなパッチを作成して送ったり、仕様提案をしたりしてきました。受け入れられたものもありますが、たいていは「これからはみんなUTF-8になるんだから (最近は「もうみんななっているんだから」) 不要だ」という理由でリジェクトされました。ここ数年は自分でも、そろそろUTF-8決め打ちでいいかな……と思いはじめています。
投稿2019/04/07 23:28
編集2019/04/09 15:00総合スコア4333
> Q符号化での符号化対象の文字種が規約通りでない。
これって、
・「[」「]」がQ符号化されていない
・ASCIIのみでも「符号化」
を指してます？
私のコメントは質問者からの疑問に答えたものです。互いに言っていることがわからなければ長くなるのも詳細を要求するのも当然だと思います。
また、この回答を見て、質問に答えているようには見えませんが、どのような質問ととったのですか？
「teratail の回答者が気にくわないのでディスってください」という質問でしたか？ それならバッチリの回答ですが、質問者の意図とは違うと思います。
この回答は現在の teratail の他の回答に比べて質が特に高いとは思いません。
他の回答のメンテできました。
私の印象を言えば、「街を歩いていたら、肩にトゲトゲをつけた人たちがばらばらと現れて、口々に何か言ってくる」という感じ。その人たちが自分を助けに来たのか、自分の種籾を奪いに来たのかなんてわかりません (どっちかというと後者に見える) から、身構える人もいるでしょう。
そもそも私は、あの質問文が理解できないということ自体が理解できないんです。だから、「何の嫌がらせだ」と思いましたよ。
本当なら、修正依頼で「問題のメールのソースとスクリーンショットを提示してください」ですんだ話だと思います。しかし、あれだけ修正依頼が荒らされてたらもうそんなことは聞けませんよ。私の回答が「可能性があります」で済まされているのはそういうことです。
あと、運営をdisるつもりはないです。運営はそういう選択をしたという説明をしただけです。実際、PHPでRFC準拠のメールを出そうと思ったら製造でもそのための教育でもしばしばコストが見合わないですから、ある程度で諦めるしかないです (そこへ行くとPythonのemailパッケージはいいぞお)。私がdisったのはZuishinさんをはじめとする熟練ユーザの方々です。
マイナスをつけたければ好きにしてください。それも織り込み済みで書きました。じゃあね。
あなたの回答
tips
プレビュー
