パスワードを忘れた? アカウント作成
10284519 journal
日記

shibuyaの日記: 日本語メール送受信はutf-8? iso-2022-jp? 6

日記 by shibuya

わたしは長年 iso-2022-jp で送受信しなければいけないと心がけていていた。
時には範囲外の文字を使ったこともあったが大枠ではiso-2022-jpのままである。
そういう過去のヘリテージから自由な人たちはUnicode JIS X 0213な丸付数字ほかを含む文字種で送信してくるわけだが、返信時にその箇所をカッコ付数字に書き換えるかどうか悩んでいる。
前回はカッコ付にした。

(追記・補足: 2013-11-28 07:44 +0900)
そもそも今使っているPC環境でUTF-8のメッセージは送信できるのだろうか?
(追記・補足: 2013-11-28 08:25 +0900)
e-mobileで接続している環境であれば
受信メッセージボディ引用部のみであっても
UTF-8のメッセージは送信できないということが確認できた。
郷里の実家でメール送受信に利用しているInternetサービスプロバイダ経由であっても
メーラを別のものにしないと返信時に正しくエンコーディングできないことは既にわかっている。
手詰まりですね。。。
(追記・補足: 2013-11-28 08:45 +0900)
そもそも古い陳腐化した通信手段扱いされているインターネットメールによる情報交換を
主にするのか?という指摘があるかもしれないし、平文の送受信ということも気になるが。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2013年11月28日 9時16分 (#2502056)

    日本中の全ての人がPC、ないしはスマホでメールを読んでくれるのならUTF-8でもいい。
    だがガラケーとかいうクソ馬鹿端末が存在する以上、日本語のメールはISO-2020-JP、それも-1でも-2でも-3でも、ましてや2004でもなく無印一択。
    なぜならあのクソ馬鹿端末は、全てのメールはISO-2022-JPという仮定の元にデコードするから。
    UTF-8やEUC-JPが文字化けするのは勿論、ダメ文字が含まれればUS-ASCIIでさえ容易く文字化けする。

    ああわかってる。「ガラケーにメールを直接送ることなんてない。」そう言いたいんだろ?
    だが君が例えばGmail宛にメールを投げたとして、相手がGmailで読むとは限らない。
    相手はGmailに飛んできたメールは全てガラケーに転送してるかもしれない。
    そうしてある日突然言われるんだ。「君から送られてくるメールがさ、いつも文字化けしてるんだ。どうにかなんない?」などとね…

    どうして未だに「文字コードはISO-2022-JP決め打ち」「一回に遅れる文字数は○○文字まで」などという、わけのわからない制限のついたガラケーが持て囃されるのだろう?
    最低限スマホで読めよ。むしろPCで読め。俺はそう言いたい。上司だから言わんけど…

    • http://blog.layer8.sh/ja/2012/04/16/pc%E3%81%8B%E3%82%89%E6%90%BA%E5%B... [layer8.sh]
      http://d.hatena.ne.jp/NAOI/20120113/1326430732 [hatena.ne.jp]
      ここらへん見た限りではガラケー=ISO-2022-JPとは限らないような。

      #上記サイトの信憑性までは知りません。

      --
      ともあれ、ヤードポンド法は滅ぶべきであると考える次第である
      親コメント
    • コメントありがとうございます。

      ①や㈱を今まで通り無断で(1)や(株)に変換してISO-2022-JPで踏襲する踏ん切りがつきました。

      親コメント
    • 「どのガラケーが」ISO-2022-JP決め打ちなんだろう。そこらがないと、1機種でも残っている限りという条件にしてしまうと、いつまで経っても状況は変わらないと思うんだけど。

      一応ウィルコムだと京セラ系、SII系はUTF-8通るみたい。新規参入のシャープがあやしいけど不明。

      親コメント
    • 問題は、
      ・SMTPの仕様として問題が無いか
      ・相手の環境で表示できるか
      の2段階に分かれるので、まずそこを切り分けるべきかと。

      SMTPは、7bitまでしか使えないんだから、7bitに収まるようなデータを送るべき。
      っていう話であれば、
      ・7bitに収まるようになってるISO-2022-JPで送る
      ・しかるべきエンコーディングをして7bitに収めて送る
      のどちらか、ってことになるし。
      拡張SMTPじゃ8bitも使えるし、今の世の中、8bit通さないサーバなんて残ってないよ。
      っていうなら、そこは気にしなくていいと思います。

      相手の環境の話で言うと、
      今時の環境で今時のメーラであれば、
      utf8が読めないとか、一般的なエンコード形式に非対応とか、
      そんなことはないでしょうし。
      ほとんど気にしなくていいんじゃないですかね?

      まあ、それでも、結論としては、
      『ISO-2022-JPで送るのが一番無難で確実』
      ってことになるんでしょうけど、
      ISO-2022-JPだけではどうしようもない場合もあるので、
      一択とは言わずに、必要に応じてutf8も使う。ってくらいに考えておけばいいんじゃないかと思います。

      あと、いわゆる『ガラケー』は、インターネットメールを直接送受信できず、
      キャリア側が、コード変換等を含めた中継処理を行っています。
      なので、適当な文字コードで投げても、だいたい問題はないはずです。

      試しにezwebのガラケーに、
      Content-Type: text/plain; charset=utf-8
      でメール投げてみましたが、基本的にはちゃんと読めました。
      ただし、半角カナは、全角カナに置き換わっていたので、
      そのへんは考慮する必要があるかもしれませんが。

      親コメント
    • by Anonymous Coward

      まさにガラパゴス、害悪しか撒き散らさない

typodupeerror

物事のやり方は一つではない -- Perlな人

読み込み中...