> 別に文字化けとかはしないのですが、メールクライアントがthunderbirdだと、UTF8のメールと、ISO-2022-JPのメールは明らかに表示されるフォントが異なり、見ていて結構違和感があります。
これ、わかります。なんでフォントが変わるのかそちらの方が不思議です。
> 例えば、日本語メールのデフォルトエンコードを設定できるとか、返信に関しては受信メールと同じエンコードができるとか、そういう事は大変でしょうか?
以前、ISO-2022-JPにする実装はしたことありますし、エンコーディングを設定できるようにしたいなとは考えてます。
絵文字との相性が微妙ですが、一旦無視してみようと思います。次のタスクとしてとりかかりましょう。
> 不躾な質問お許しください。。。
いえいえ。場にあった礼儀は必要でしょうけれど
基本、利用者は言いたいことを言えばいいと思います。
どちらにしろ、実現できるかどうかはこちらの裁量にかかっているので。
別に文字化けとかはしないのですが、メールクライアントがthunderbirdだと、UTF8のメールと、ISO-2022-JPのメールは明らかに表示されるフォントが異なり、見ていて結構違和感があります。
> これ、わかります。なんでフォントが変わるのかそちらの方が不思議です。
同じ方がいらっしゃって嬉しいです(^^)
前田さんの仰るとおり日本語用のフォントとUnicode用フォントの違い、という
のはわかるのですが、Thunderbirdでその設定って私には見つけられないのです。。。
Gmail主体の方であれば、Gmailは文字コードがUTF-8なので違和感はもしかすると
無いのかも知れませんが、今までの経験上、UTF-8で送ってくるのはGmail/Notes
メールだけだったので、、、
ちなみに、Androidの標準Gmailアプリからで送られてきたメールと、2022で送ら
れてきたメールは、表示される文字のサイズも異なって見えます。
あ…それはmultipartのhtmlメールだから、でしょうか。。。(^^;
って事はそれは表示をテキストで、という設定があればいいんですかね。
すいません、脱線してしまいました(^^;
> 以前、ISO-2022-JPにする実装はしたことありますし、エンコーディングを設定できるようにしたいなとは考えてます。
> 絵文字との相性が微妙ですが、一旦無視してみようと思います。次のタスクとしてとりかかりましょう。
そうですね、絵文字を考えると微妙だと思いますし、絵文字を多用している方で
あれば迷惑な話ではないかとは思いますので、オプション的な扱いになるといい
のかな、と思います。
>> 不躾な質問お許しください。。。
>
> いえいえ。場にあった礼儀は必要でしょうけれど
> 基本、利用者は言いたいことを言えばいいと思います。
> どちらにしろ、実現できるかどうかはこちらの裁量にかかっているので。
ありがとうございます。
かなり楽しみにしています♪
名越
ちゃんと確認してないのですが
アカウント設定→メール受信→サーバで削除したときにローカルも消す
みたいなオプションでPOPでもローカルに残し続けられるのではなかったかと思います
もし、そうであれば足りないのは
ローカルフォルダと振り分けとメールのエクスポートの機能ですかね
どれも簡単ではないので時間はかかりますが次の次の次(いつ?)くらいには考えてみましょうか。
一度挫折したんですけどね
えっと、調べてみたところ、Thunderbirdの
オプション>表示>書式>フォント>詳細
の『対象言語』の部分で、
・ISO-2022-JPの場合・・・『日本語』の設定を使用して表示
・UTF-8の場合・・・『その他の言語』の設定を使用して表示
という事みたいです。
なので、UTF-8のメールを、ISO-2022-JPと違和感なく使いたい場
合は、その設定をしてあげなければいけないみたいです。
そうか、、、UTF-8だと言語判定できないんですね・・・
この設定、今日まで知らなかったです…(^^;
名越
2011年12月8日10:04 前田 淳 <ju...@juner.net>:
> > 例えば、日本語メールのデフォルトエンコードを設定できるとか、返信に関しては受信メールと同じエンコードができるとか、そういう事は大変でしょうか?
>
> 以前、ISO-2022-JPにする実装はしたことありますし、エンコーディングを設定できるようにしたいなとは考えてます。
> 絵文字との相性が微妙ですが、一旦無視してみようと思います。次のタスクとしてとりかかりましょう。
>
とりあえず、実装してみました。日本語版のサイトで以下をダウンロードしてみてください。
k9mail_ja_4102_20111204-9a5cf33.apk
設定は、
アカウント設定→メール送信→Message Encoding
ただし、かなりやっつけなのでバグはあると思います。
バグに会いたくない人はUTF-8のままで使ってください。
HTMLメールもやめたほうがいいです。
評価してくださる方は、いろいろ検証してみて報告いただけるとうれしいです。
このメールはISO-2022-JPで送信されているはず
早速ありがとうございます。
取り急ぎ試してみました。
えっと、ISO-2022-JPはいいのですが、
>Content-Transfer-Encoding: 8bit
ISO-2022-JPにするなら、ここは7bitでは?
あと、
>Content-Type: text/plain;
> charset=ISO-2022-JP
改行が入るのはいいんですかね。
色々見たのですが、
>Content-Type: text/plain; charset=iso-2022-jp
>Content-Transfer-Encoding: 7bit
が多いのですが、
>Content-Type: text/plain;
> charset="ISO-2022-JP"
となっているのもあるので、何が正解なんだかよくわかりません(^^;
とりあえず、7bitにしないと、じゃないかなとか思います。
いかがでしょうか。
名越
>>Content-Transfer-Encoding: 8bit
>
> ISO-2022-JPにするなら、ここは7bitでは?
> あと、
ああ、たしかに。簡単にバグが見つかりましたね orz
報告ありがとうございます。
>>Content-Type: text/plain;
>> charset=ISO-2022-JP
>
> 改行が入るのはいいんですかね。
> 色々見たのですが、
これは、問題無いと思います。
>> ISO-2022-JPにするなら、ここは7bitでは?
>> あと、
>
>ああ、たしかに。簡単にバグが見つかりましたね orz
>報告ありがとうございます。
直せたと思います。
設定項目を微妙に変えたので再設定が必要ですので注意してください。
申し訳ありません。また出直します。
早速の修正ありがとうございます。
私の環境では、PCはThunderbird、スマホはK-9ですが、
K-9から試しに自分のアドレスに送信してみました。
K-9より受信したメールを、Thunderbirdで見ると、
Content-Type: text/plain;
charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
となっているので、ここはOKだと思います。
で、K-9から送った同じメールを、K-9で見ると、
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
となっています。
これは問題ありませんか?
他のメールでもそうなのですが、Thunderbirdでは
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
と見えるメールも、K-9では一律で
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
となっているように思えるのですが、、、
K-9のヘッダー表示ではそうなっちゃうけど、K-9からISO-2022-JPで
送ったメールはその通りPCでは表示されているので問題ない、という
のであればいいのですが。。。
#細かくてすいません・・・m(_ _)m
名越
2011年12月12日22:10 Koji Arai <jca0...@gmail.com>:
k9では、受信したMIMEメッセージを解析したあとその内容を保存するときにMIMEを再構築します。
ローカルフォルダの格納形式はこの再構築した結果です。
メール表示時はこのローカルフォルダの内容を見るため、ご指摘の結果となります。
と、思ってたのですがもしかするとちゃんと調べれば修正できるかもしれません。ちょっと見てみようと思います
新井です
>と、思ってたのですがもしかするとちゃんと調べれば修正できるかもしれません。ちょっと見てみようと思います
やはり、CTヘッダやCTEヘッダ(長いので省略)はデフォルトでutf-8やや8bitが設定されるだけで、ローカルフォルダのヘッダとしてはほとんど役割を果たしてないようです。
ただし、デフォルト設定をなくせばいいかというとある条件でそうもいかないようで、
影響範囲を考えるともう少し時間とテストが必要そうです。
さて、どうしようかな
また、調査します。
--
Koji Arai
>ISO-2022-JP対応で携帯宛に送ると、化けているようですね。
>DoCoMo宛メールで確認
>
>また、調査します。
名越です、お世話になります。
本文に『送信テスト』と入れて送ったら、『送信テス』になってました。
その他のパターンがわかったらまた報告します、、、
直せたと思います。
https://github.com/jca02266/k-9/k9mail_ja_4103_20111218-3cc3a27.apk/qr_code
ひっそり、shift_jisメールに対して、quoted-printableを使ってた部分をbase64に変えたのですが、
最後に明示的に(flush()でなく)close()しないといけなかったために、末尾がおかしくなる場合が
あったようです。(k9は絵文字対応の関係で、宛先に携帯が含まれているとshift_jisで送ります。)
2011年12月18日14:04 Nagoshi Tomohiro <t.na...@gmail.com>:
> Koji Arai <jca0...@gmail.com> wrote:
>
>>ISO-2022-JP対応で携帯宛に送ると、化けているようですね。
>>DoCoMo宛メールで確認
--
Koji Arai
docomoでの文字化けが直ったのは確認しました。
ヘッダーを観ていて今気がついたのですが、ISO-2022-JP選択時に、
Subject: =?ISO-2022-JP?
で送信されますが、FROM/TOに含まれる文字列は、
TO: =?UTF-8?
となっているので、この部分はUTF-8のままになっています。
Thunderbirdとかその他のメールソフトでもきちんとエンコードはさ
れて表示されてはおりますので、このままでも問題ないと言えばまぁ
問題は無いとは思いますが、混在しているのはどうでしょうか?
名越
なるほどですね。ご指摘ありがとうございます。
今、受信メールのContent-TypeヘッダとともにMIMEメッセージの構築箇所を見直してます。
今後も踏まえてテストを作りつつやっているので多少時間がかかりそうですが、
ご指摘の件もそのときに一緒に対応を考えます。