『Eメールの文字化けについて』のクチコミ掲示板

[運命のヒト]

i.softbank.jp(Eメール)で他社携帯にメールをすると、文字化けが頻繁に起こります。
過去のクチコミなどを調べてみると、文字コードが他社携帯に対応してないと文字化けが起こることはわかりました。
メモやMMSで下書きしてから送信しても文字化けが起こります。
何か対処法はないものでしょうか？
MMSだと自宅が圏外なのでちょっと・・・

書込番号：10143553

[tac_tac]

「他社携帯」とはSoftbank以外どのキャリア同様ということですか？（PC宛でも？）
それとも「au携帯」についてですか？

前者だとすれば、iPhone側でソフト的不具合が発生しているかもしれません。復元などが必要だと思います。
後者だとすれば、相手の携帯がUTF-8に対応していない／設定になっていないのが原因だと思います。
絵文字を含めずに送ってみてはどうでしょう？

書込番号：10145695

[運命のヒト]

tac_tacさん、早速のお返事ありがとうございます。



＞「他社携帯」とはSoftbank以外どのキャリア同様ということですか？（PC宛でも？）
＞それとも「au携帯」についてですか？

ドコモとauです。
PC宛には送信したことがないのでわかりません。
過去のクチコミをみると、auはUTF-8に対応していないので文字化けが起こる事はわかりました。

疑問なのはドコモやauに送信した文字化けメールと同じ文章を新たに打ってもらい、iPhoneに送信してもらっても文字化けしないことです。
なぜでしょうか？
やはりiPhone側でソフト的不具合が発生しているのでしょうか？
外出先から書き込みしているので、帰宅後復元して文字化けしたメールをもう一度送信してみます。

書込番号：10145896

[tac_tac]

う〜ん、私にはちょっと分かりません。
こちらでは、文字化けして届いた・受けた経験が無いもので…。
やはり復元を試してもらうことしか思い浮かびません。

書込番号：10147567

[tatsukun_n]

文字化けは、対応していないものがいくつかあります。

auからドコモに送信する時も変換に対応していない文字化けの場合表示されません。

仕方がないのでは？

iPhoneに限らず、他のソフトバンク携帯でも他社に送れば同じと思いますが。

書込番号：10147873

[運命のヒト]

tac_tacさん、お返事ありがとうございます。



tac_tacさんは文字化け経験ありませんか。うらやましいです。

今復元して文字化けしていた文章をもう一度送信してみましたが、やはり同じ文字が文字化けしてしまいました。
ソフト的不具合ではないみたいです。
文字コードが対応していないからかもしれませんね。

しかしMMSから送信したとき、文字化けが起こらないのが疑問です。EメールとMMSの文字コードが違うということでしょうか？疑問です。





tatsukun_nさん、お返事ありがとうございます。



＞auからドコモに送信する時も変換に対応していない文字化けの場合表示されません。

auかたドコモでもあるんですか？知りませんでした。
前までドコモを使用していましたが、auやソフトバンクの人から文字化けしているということをきいたことはありませんでした。

復元しても文字化けは起こるので仕方ないのかもしれません。
割り切って使用すればいいのかもしれませんが・・・

書込番号：10148263

[nofunofu]

横スレで失礼いたします
私も文字化け経験者です
相手はauです
文字化けは突然襲ってきます
これまで普通に絵文字を化けずに
メール交換していた相手auでなんの前ぶれもなく
突然すべての絵文字が？マークに化けます
メール作成は返信でも新規でも突然化けます
そしてまた普通に絵文字メール可能になります
何が原因かさっぱりわかりません

書込番号：10148763

[Cogito ergo sum]

なぜ時々文字化けするメールとしないメールがあるのか、本当の所は（専門家ではないので）わかりませんが、Mac OS X の純正メーラーの Apple Mail と他のメーラーとのやりとりで発生する文字化けの例から類推した推測を述べてみます。

Apple Mail の iPhone 版である iPhone Mail は、当初は全ての送信メールを Unicode の文字コードで送信しておりました。これは極めて合理的な処理で、現在のほとんどのメーラーは Unicode に対応しており、Unicode ならばいわゆる“機種依存文字”の問題もほぼ解決し、文字化けが無くなるだけではなく、世界中の文字が同時に混在して使えるからです。ところが、これが iPhone 以外の国産携帯メールユーザからの「iPhone からのメールは文字化けする！」という非難に繋がりました。責任は実は JIS (ISO-2022-JP) にしか対応していない時代遅れの国産携帯のメールシステムにあったのですが、何しろ、日本では携帯メールのユーザの比率は非常に高いために、アップルは（恐らくはソフトバンクの懇願に応じて）JIS (ISO-2022-JP) で定義されている文字のみを使っているメールに関してはあえて JIS (ISO-2022-JP) のまま送信するように iPhone Mail の仕様を変更したのでした。

そこで国産携帯ユーザからの「iPhone のメールは文字化けする」という非難は減少したのですが、それでも時々文字化けするのはなぜでしょうか？ これは想像ですが、iPhone から送信するメールに JIS (ISO-2022-JP) では表記できない文字が含まれている場合に発生するのではないかと睨んでいます。つまり、これまでもパソコン間のメールで指摘されていた“機種依存文字”が使われているとアウトになるのではないでしょうか？ いわゆる丸付き数字やローマ数字、括弧に入った「株式会社」等の略称はマイクロソフト社が外字エリアに独自に追加した文字であって、JIS (ISO-2022-JP) の規格の文字ではありません。JIS (ISO-2022-JP) ではないのですが、マイクロソフトのメーラーなどは勝手に JIS (ISO-2022-JP) だという情報をメールに埋め込んでメールを送信してしまうようです。（そして日本の携帯メールもマイクロソフトの規格に準じています。）ところがアップルのメーラーは厳密に規格に従っているので、JIS (ISO-2022-JP) で定義されていない文字が使われているメールには JIS (ISO-2022-JP) という情報を打ち込みません。ウソになるからです。以前はそういう文字が含まれているとパソコンの方の Apple Mail も自動的に Unicode (UTF-8) の文字コードで送信していました。なぜなら Unicode (UTF-8) ならば、そういった機種依存文字の違いも吸収できるからです。（マイクロソフトが勝手に外字エリアに登録した私的な文字も Unicode では文字コードが割り当てられています。）ところが、JIS (ISO-2022-JP) のつもりのメールが Unicode で送受信されてしまうのも、また問題が発生したようです。（専ら、文字コード管理がルーズな Windows 側の問題です。）そこで、アップルは Apple Mail から送信する「JIS (ISO-2022-JP) を意図した」メールの場合で（iPhone Mail も恐らく同じことをしています）、JIS (ISO-2022-JP) に定義されている文字以外も含んでいるメールは、その文字コードを「CP932」として送信するのです。「CP932」は JIS (ISO-2022-JP) にマイクロソフトの外字も加えた文字コードです。ところが、これまた「CP932」には対応していないメーラーが多いのです。（例えばパソコンの世界でも、有力なメーラーである Thunderbird は「CP932」のメールを受信すると文字化けしてしまいます。受信したメールを手動で「JIS (ISO-2022-JP)」に変更してやる必要があります。）「CP932」は本来公式に定義された規格ではないためにそのような問題が発生するようです。恐らく国産携帯に文字化けして届いた日本語のメールは（例えば実験で同じメールをパソコン宛にも送ってみれば確認できると思いますが）「CP932」になってしまっているのだと思います。それを回避するには、いわゆる“機種依存文字”を避けることになるのかなと想像しています。

書込番号：10150516

[Cogito ergo sum]

　＞運命のヒトさん

> 疑問なのはドコモやauに送信した文字化けメールと同じ文章を新たに
> 打ってもらい、iPhoneに送信してもらっても文字化けしないことです。

恐らく理由は簡単です。iPhone は Unicode (UTF-8) を始めありとあらゆる文字コードに対応しています。だから国産携帯から JIS (ISO-2022-JP) ないし CP932 で送信されたメールを受信してもきちんと解読できるので iPhone 側では文字化けは発生しないのです。

しかし、国産携帯の方では JIS (ISO-2022-JP)、むしろ CP932 にしか対応していないので（実はこれは英語ですらきちんと表示できない！）文字化けを起こしてしまうのだと思います。

携帯ユーザが文字化けしたメールを受信して不便なのも理解できますし、iPhone ユーザがしょっちゅう携帯ユーザから「文字化けした！」と苦情を受けるので困っているのも理解できますが、はっきり言って、これは iPhone の責任ではなく、時代遅れの JIS (ISO-2022-JP) に固執し、世界標準の Unicode に対応しない国産携帯側のみの責任です。iPhone 側がわざわざ Unicode を使えなくするようなダウングレードをするはずはありえませんから、日本の国産携帯が Unicode に対応するまでは我慢するしかないのだと思います。それまでは相手の携帯電話にメールを送りたい iPhone ユーザは敬大メールとして文字化けしない文字のみを使うように気配りをするしかないでしょうね。

書込番号：10150525

[tac_tac]

多かれ少なかれ文字化けに困っている人は居るようですね。私は経験ありませんが、知人は何度か経験あるそうです。
各キャリア間である程度の互換性は保たれているにしても、発現するケースがある以上、解決策が出るまでは他の方法で回避した方が時間と労力を省けると思います。

Gmailで送れば文字化けしない（しにくい？）と思いますがいかがでしょう？（未確認）
iPhoneのメールアプリでGmailを使うのと、SafariでGmailを使うのでは挙動が違うかも知れませんが。
※ただし、絵文字入りメールを受けられますが送れません。（PCのブラウザからは送れます）

書込番号：10151051

[Reflex0922]

少し情報です。
（1）iPhone→ドコモ（F-09A）
［頬］は単独一文字で文字化けします。
［口］も文字の組み合わせで文字化けします。（こちらは、私がたまたま送ったメールが文字化けしてると連絡を受けました）

（2）ドコモ（F-09A）→iPhone
正しく［頬］が表示されます。iPhoneからドコモ宛の［頬］の引用返信は正しくドコモで表示されます。

上記から、
・iPhoneのメーラ上で［頬］を打った時に内部に設定される文字コードに誤りがある
・［頬］以外にも同じような単純な誤りがある（複数文字の実験で発生したので他にも誤りがあるだろう、との推測）
だと思います。

スレ主さんの事象原因と同じかどうか分かりませんが、少なくとも文字変換回りにバグがありそうです。
アップルに文字コードの見直しをお願いしたいのですが、どこにお願いすればいいのでしょうか。

書込番号：10151053

[tac_tac]

Reflex0922さん

なるほど、そういうことがあるんですね。
フィードバックを利用されてはいかがでしょう。
https://regist.apple.co.jp/feedback/iphone/

書込番号：10151079

[hitc]

>（1）iPhone→ドコモ（F-09A）
>［頬］は単独一文字で文字化けします。

iPhone 3GS (OS3.1, i.softbank.jp) → docomo (m702iS) ですが、タイトル「頬」、本文「頬」で文字化けはしません。
m702iSはdocomoの中でも異色(世界標準を意識しているモトローラ製)ということがあるかもしれませんが、少なくとも受信する機種に依存しているように思います(つまりiPhone側の問題ではないのではないかと)。

書込番号：10151115

[Reflex0922]

hitcさんの書き込みを見て回りの人の携帯に[頬]単独一文字を送り、結果を確認しました。F-09AとM702iSの結果も並べてみました。なおiPhoneの環境はOS3.0,i.softbank.jpです。
　機種　　　　　　　　　結果（×：文字化け）
　F-09A　　　　　　　　　　×
　M702iS　　　　　　　　 　○　　※これだけOS3.1
　NM706i　　　　　　　　 　×
　P-09A　　　　　　　　　　×
　WindowsPC（Becky!）　 ○
上記から、hitcさんの言う通り受信側の問題のようです。
AU、SOFTBANKは試していませんが、ドコモの純国産携帯（F-09A,P-09A）及びノキアは文字化けします。
文字コード変換に詳しくないので、機種依存文字ではない[頬]が文字化けする原因が想像できません。（ドコモの文字変換がおかしいのでしょうか？？もしかしたらAUも？）

書込番号：10151604

[Cogito ergo sum]

　＞hitcさん＋Reflex0922さん

hitc> Reflex0922>（1）iPhone→ドコモ（F-09A）
hitc> Reflex0922>［頬］は単独一文字で文字化けします。
hitc>
hitc> iPhone 3GS (OS3.1, i.softbank.jp) → docomo (m702iS) ですが、
hitc> タイトル「頬」、本文「頬」で文字化けはしません。

　私も iPhone 3GS (iPhone OS 3.1 (7C144)) から FOMA F904i に同様のメールを送信してみましたが、全く文字化けは発生しませんでした。

　これまた想像なのですが、iPhone では文字入力自体が Unicode なので、普通に日本語を変換して入力していても JIS (ISO-2022-JP) には収録されていないほとんどの漢字などが全く意識することなく入力できてしまいます。「その文字は JIS (ISO-2022-JP) にはないよ！」等と言う警告は一切出ません。そのために普通に変換・入力しているつもりでも、変換候補を選択確定するときに JIS (ISO-2022-JP) オンリーの文字と、JIS (ISO-2022-JP) でのみ定義されている文字の異体字ないし正字の微妙な違いに気付かず、そのまま確定してしまっているのではないででしょうか？

　このサイトは Shift JIS を使っているようなので、恐らく文字化けしてしまうと思いますが、「頬」には少なくとも以下のような３種類の文字があります。[U+] に Unicode の文字コードを、その後の [] に Shift JIS の文字コードを入れておきました。[-] は Shift JIS では定義されていない（＝収録されていない）文字だと言う意味です（文字化けした場合には文字コードの方からその文字を検索して確認してください）：

「頬」[U+982C] [966A]
「頬」[U+9830] [-]
「颊」[U+988A] [-]

　３つ目の「颊」[U+988A] は簡体字で、日本語では通常使われませんが、2つ目の 16画の「頬」[U+9830] は旧字（正字？）で Shift JIS には存在しません。新字（略字？）の「頬」[U+982C] [966A] のみが Shift JIS で表示できる文字です。この２つはほとんど違いが分からないほど似ている文字です。（元々同じ意味の異体字同士ですから。）

「口」に関しても、漢字の「口」（くち）[U+53E3] [8CFB] と部首の「⼝」（くちへん）[U+2F1D] [-] と「⼞」（くにがまえ）[U+2F1E] [-] は非常によく似ています。恐らく入力画面では区別が付かないでしょう。それで間違って入力されてしまった可能性も否定し切れませんが、ただ、iPhone の場合、どういう入力方法を取ったら部首が入力されてしまうのかはわかりませんが (^^;)。Reflex0922さんのご報告では

Reflex0922>［口］も文字の組み合わせで文字化けします。

とあります。「文字の組み合わせ」とは「熟語」のことでしょうか？ その場合考えられるのは、「口」と組み合わせられたもう一方の漢字が（一見して気付きにくくとも）Shift JIS では表示できない文字だったという可能性があるかもしれません。あと、携帯ユーザはやたらと半角片仮名を使いたがりますが（それなのに、算用数字やラテン文字は全角を使いたがるのは謎...。本来は逆であるべきでしょう）、半角片仮名の文字を使うと、文字コードで誤認エラーを出させる恐れがあります（＝「半角片仮名＋別の文字」と認識できず、両方の文字コードを合成した「１文字」と解釈してしまう）。

書込番号：10151709

[運命のヒト]

nofunofu、お返事ありがとうございます。



nofunofuさんも文字化けで悩んだおられるんですね。
私も前の携帯ではなかった文字化けという現象に本当に困ってます。
何かいい策があればと思い書き込みしましたが、今のところいい策はなさそうです。
とても残念です。





Cogito ergo sumさん、お返事ありがとうございます。
推測とはいえ、納得させられました。ありがとうございます。



文字化けの問題はCogito ergo sumさんがおっしゃるとおり、JIS規格や文字コード等色々なことが原因で起こっているのかもしれませんね。



＞iPhone は Unicode (UTF-8) を始めありとあらゆる文字コードに対応しています。
＞だから国産携帯から JIS (ISO-2022-JP) ないし CP932 で送信されたメールを受信してもきちんと解読できるので iPhone 側では文字化けは発生しないのです。

Cogito ergo sumさんの推測が正しいとすれば、国産携帯では文字化けするのに、iPhoneでは文字化けしないのは納得出来ます。

しかし、ここで疑問なのは
1.文章(絵文字付き)では文字化けするのに、単語だけでは文字化けしないときがあります。
同じ文字全てが文字化けするなら納得出来ますが、文章だと文字化けするが単語一文字だけだと文字化けしないという現象は納得出来ないんですよね。
なぜなんでしょうか？疑問です。

2.文字化け文章をMMSで送信すると文字化けしないのはなぜでしょう？
EメールとMMSでは文字コードが違うということでしょうか？

わかる範囲で構いませんので教えて頂ければ幸いです。



＞iPhone 側がわざわざ Unicode を使えなくするようなダウングレードをするはずはありえませんから、日本の国産携帯が Unicode に対応するまでは我慢するしかないのだと思います。

そうですよね。国産メーカーが対応するまで待つしかないですね。





tac_tacさん、お返事ありがとうございます。



＞Gmailで送れば文字化けしない（しにくい？）と思いますがいかがでしょう？（未確認）
＞iPhoneのメールアプリでGmailを使うのと、SafariでGmailを使うのでは挙動が違うかも知れませんが。
＞ただし、絵文字入りメールを受けられますが送れません。（PCのブラウザからは送れます）

GmailのSMTPを経由して送信すると、確かに文字化けせずに送信は出来ました。
が、tac_tacさんがおっしゃるとおり絵文字が使えません。私にとってそれはかなりイタイです。
やはり文字化け覚悟でメールのやり取りをしなければいけませんね。





Reflex0922さん、お返事ありがとうございます。

私もドコモ(SH903i)に送信して試してみました。
「頬」は正しく表示されますが、
「頬」は「・」で表示されました。





hitcさん、お返事ありがとうございます。



＞少なくとも受信する機種に依存しているように思います(つまりiPhone側の問題ではないのではないかと)。

Cogito ergo sumさんがおっしゃるとおり、国産携帯の問題かもしれませんね。

書込番号：10151732

[Cogito ergo sum]

　＞Reflex0922さん

　機種　　　　　　　　　結果（×：文字化け）
　F-09A　　　　　　　　　　×
　M702iS　　　　　　　　 　○　　※これだけOS3.1
　NM706i　　　　　　　　 　×
　P-09A　　　　　　　　　　×
　WindowsPC（Becky!）　 ○

　これを見ると、パソコンで文字化けせず、米国製の携帯でも文字化けせず、国産携帯と（フィンランド製の）Nokia だけ文字化けしています。やはり送信したメールに Unicode の文字が含まれており、Unicode に対応した機器ないしソフトでは文字化けが発生しないのに、Shift JIS のみに対応した（外国製の場合は Shift JIS のみにダウングレードした）携帯でのみ文字化けが発生するのではないでしょうか？

念のため、「頬頬」と２つの異体字を並べたメールを作成してみて送信して実験してみてはいかがでしょうか？ もし２つの文字の入力のし方がわからないというのであれば、パソコン上のメーラーから自分の iPhone 宛に「頬頬」をコピペして送信すればよろしいでしょう。

...とここまで書いて投稿しようとしたら、このサイトでは２つの異体字の違いを無くして登録・表示してしまうことに気付きました...。（やはり画面ではこの２つの文字が違っているのか、同じなのか、なかなか気付きにくいです。）困りました...。であるならば、 http://slashdot.jp/~yasuoka/journal/459892 辺りのページを表示して、そこからコピペさせていただくという方法もありますね。

書込番号：10151774

[運命のヒト]

あれ？
＞「頬」は「・」で表示されました。

違う漢字の「ほほ」を入力したのに、「頬」に変換されて表示されますね。
勝手に同じ意味の漢字に変換して表示してしまってますね・・・

ここに書き込みされてるみなさんもiPhoneをお持ちだと思いますので、「ほほ」と打って変換してみてください。「頬」の他にもう一文字でてきますので。

書込番号：10151821

[運命のヒト]

内容がCogito ergo sumさんとかぶってしまいました。
申し訳ありません

書込番号：10151866

[Reflex0922]

Cogito ergo sumさん、運命のヒトさん、ご指摘ありがとうございます。
[頬]の件は、
＞「頬」[U+982C] [966A]
＞「頬」[U+9830] [-]
の違いによるものでした。
私のこれまでの文字化けは「・」と”表示される”、とメール受信者か
ら指摘がありましたので、これに遭遇していたものと思います。
よく漢字を確認するようにします。（しかし判別が難しいですね・・）
”ほお”⇒ドコモで正しく表示されないUTF-8の漢字が先に表示
”ほほ”⇒ドコモで正しく表示されるISO-2022-JPの漢字が先に表示
ですね・・。ISO-2022-JPの漢字を先に表示して欲しいですね・・。

＞［口］も文字の組み合わせで文字化けします。
＞とあります。「文字の組み合わせ」とは「熟語」のことでしょうか？
口べた（+絵文字　※顔絵文字１段目左から２つめ）をドコモに送ると
[戟ャラた]（+絵文字）
に文字化けします。絵文字は正しく変換されました。
PCメーラだとISO-2022-JPで正しく表示します。
多分、この事象がスレ主さんの事象かと思います。


推測すると、各キャリアサーバでiPhoneの絵文字をサポートしましたが、
そのサポート（SOFTBANKが各キャリアに出した変換仕様か各キャリアのサポート方法？）に問題があるのではないでしょうか。
tac_tacさんに教えて頂いたフィードバックに連絡してみようかと思います。

書込番号：10151868

[運命のヒト]

Reflex0922さん、お返事ありがとうございます。

＞ISO-2022-JPの漢字を先に表示して欲しいですね・・。

本当にその通りだと思います。





私の文字化け現象は、
文字 ＋ 絵文字
で多いような気がします。(たまに文字だけでも文字化けしますが)

例)
1.食・・・文字化けしない
2.飲食禁止・・・文字化けしない
3.飲食禁止 ＋ ビックリマークの絵文字 ＋ 食事マークの絵文字・・・飲FH禁止 ＋ ビックリマークの絵文字 ＋ 食事マークの絵文字

このような感じです。
MMSから送信すると1・2・3全て文字化けせずに表示されます。
やはり疑問です。

書込番号：10151991

[Cogito ergo sum]

　＞運命のヒトさん

> 1.文章(絵文字付き)では文字化けするのに、
> 単語だけでは文字化けしないときがあります。
> 同じ文字全てが文字化けするなら納得出来ますが、
> 文章だと文字化けするが単語一文字だけだと
> 文字化けしないという現象は納得出来ないんですよね。
> なぜなんでしょうか？疑問です。

　運命のヒトさんが実際にどのような文章を送信されているのかわかりませんので、これまた推測になってしまいますが、私の経験では基本的に携帯メールしか使われない方々は、インターネットの本来のメールでは“禁じ手”のルール違反の文字入力をされています。これは当初国産携帯のメールシステムが自己完結型として作られたために見逃されてきていたのでした。ところが、携帯メールがインターネットと相互接続されるようになってから、国産携帯の当初のいい加減な（「どうせ〜なんだから、まっ、いいか...」的な）規格が問題を起こすようになってしまったわけです。（多少弁護すれば 、携帯メールが登場した時期には Unicode を使ったメールのやりとりはまだ一般的ではありませんでした。しかし、そうは言っても数年後には Unicode 時代がすぐ来るというのは予見できていたはずです。「でも、日本人だから、日本語だけでしかやりとりしないし。Unicode なんて必要ないよね。登録しなければならない文字だって何万文字にもなり、携帯のメモリー容量を圧迫するし...」と日本の開発者は考えたのでしょう。）で、携帯ユーザは、「半角の片仮名」を多用します（パケット数節約のため？）。このサイトでも携帯から書き込みされる方々は普通に半角片仮名を用いて、しばしば他の方々から注意されていますが、だいたいそういう注意は無視されます。（「なぜいけないのか理解できない」→「理解できないことは気にならない」→「気にならなければ無視する」）

　「半角片仮名」の他にも「半角の日本語独自の記号」も多用されます。例えば「三点」の「…」や代用に３つの半角のピリオドを並べた「...」ではなく、中黒「・」を半角にしたものを３つ並べたり、句点「。」を半角にしたものを３つ並べたりしているのを頻繁に見かけます。半角の鉤括弧も使われていますね。これらは先ほども書いたように、隣接する文字の文字コードと組み合わさって別の文字コードとして語認識されてしまう恐れがあります。さらに、丸付き数字やローマ数字のような機種依存文字も場合によっては問題を引き起こす場合もありえます。

　先ほども書きましたように、このようなイレギュラーな文字を混在させると、メールの送信時にメーラーが混乱して受信側との間でトラブルを起こすのではないでしょうか？ 例えば、iPhone Mail や Apple Mail のように（もちろん、Thunderbird や Windows Mail、Outlook Express、Entourage も然り）多様な文字コードに対応しているメーラーの場合は、逆にそれが災いして、識別不能な文字コードのメール（＝一見複数の文字コード規格の文字列が混在しているありえないメール）を送信しようとしたときに、間違った文字コードと誤認して、それで送信してしまうと、受信した側のソフトでは「読めない！」メールとして認識されてしまうのではないでしょうか？ ところが、国産携帯電話同士ではメールは１つの文字コードに固定してありますから、文字コードの解釈自体をしていないので、お互いの間では文字化けがほとんど発生しないのだと思います。


> 2.文字化け文章をMMSで送信すると文字化けしないのはなぜでしょう？
> EメールとMMSでは文字コードが違うということでしょうか？

　私は、iPhone Mail では通常のインターネットメールしか使っておらず、SMS や MMS は使わない主義なので、それらのことはさっぱりわかりません。（＠i.softbank.jp のメールすら、中途半端で不便なので使っていません。職場のメールと MobileMe のメールのみを登録しています。これらはパソコンと平行受信です。）

書込番号：10152018

[Cogito ergo sum]

　＞運命のヒトさん

> GmailのSMTPを経由して送信すると、確かに文字化けせずに送信は出来ました。
> が、tac_tacさんがおっしゃるとおり絵文字が使えません。私にとってそれはかなりイタイです。

　まぁ、iPhone も日本の国産携帯ユーザからの強い要望に押される形で、最近、やっと絵文字などに対応するようになってきたようですが、まだまだ電子メールでの利用は色々問題があると思います。ある種の裏技を使わない限り、パソコンでメールを受信している人には文字化けして届いてしまいますし...。現在、Google 等が中心となり、絵文字も Unicode で定義しようと言う動きがありますが、これが策定されても、国産携帯が Unicode に対応しないことにはどうしようもありません。また、対応したら、対応したで、これまでの古いメールとの整合性の問題なども頭が痛い問題になると思います。

　とりあえずは、iPhone で携帯ユーザーとメールのやり取りをしたいのであれば、「文字化け」と「絵文字」のどちらを優先させたいのかで、どのように使うかを決めなければならないでしょう。さらに言えば、もしもそこまで国産携帯メール的な機能にこだわるのであれば、やはり iPhone を捨てて、通常の国産携帯に戻るということも一考に値するのではないでしょうか？（で、国産携帯が Unicode にも対応した段階で iPhone に戻ってくると (^^)。）

　使い方、価値観は人それぞれです。私の場合は、携帯メールも、絵文字も基本的には使わない主義ですので、iPhone はまさに私にぴったりの携帯でした。場合によっては、それができる方は、これまでの「携帯中心」の利用から「パソコン中心」の利用に生活を変えることができれば、iPhone は今のままで最強のツールとなりえると思います。

　メールだけではなく、メモや文書入力も、「連絡先」（アドレスブック」も、「カレンダー」（スケジュール）も、全部 Unicode で統一されていると言うことは、その便利さ、快適さに慣れてしまうと、もう元には戻れなくなります。「連絡先」では外国人の姓名や住所も正しい綴りで入力できますし、スケジュールでも正しい地名や人名が入力できます。さらにそれらの正しい綴りの固有名詞や単語をメールや他のソフトとの間でコピペもできるわけです。（それに Unicode を使えば、外国語だけではなく、日本語だって、難しかったり、珍しかったりする異体字や正字、旧字の漢字が使えるようになるのです！）iPhone の Unicode を積極的に評価できるようになれば、国産携帯とのやりとりで発生するトラブルは差し引きでそれほど苦にならなくなるかも知れません。（...と、国産敬体とのメールのやりとりをしない私が言っても説得力はありませんが (^◇^;)。）

書込番号：10152023

[tac_tac]

一部訂正します。

＞※ただし、絵文字入りメールを受けられますが送れません。（PCのブラウザからは送れます）

あらかじめ i.softbank.jp アカウント（SMS/MMS上でも可）で絵文字込みのメールを作成・コピーして、
それをGmailアカウントでのメール作成時にペーストすれば、iPhone＋Gmailでも絵文字が送れることを
確認しました。メールアプリでもSafariでも問題無しです。
（上記方法で他社携帯に文字化けせずに送れるかどうかは別の話ですが）

書込番号：10152029

[Cogito ergo sum]

　＞運命のヒトさん＋Reflex0922さん

運命のヒト> Reflex0922> ISO-2022-JPの漢字を先に表示して欲しいですね・・。
運命のヒト>
運命のヒト> 本当にその通りだと思います。

　これは、パソコンの日本語入力ソフトや携帯のソフトでも同じだと思いますが、使用頻度によって優先度が高く評価されますし、最後に使った文字が最優先されて表示されますので、JIS (ISO-2022-JP) の文字を最優先にして固定しておくということ、つまり日本語変換ソフトを学習しないように、わざと“お馬鹿”にするというのは現実的ではないでしょう。恐らく、最初に「頬」という文字を入力したときに、文字化けしない一般的な方の「頬」の候補をうっかり見過ごし（とにかく見づらいですものねぇ...）、旧字の方を選んでしまったのだと思います。iPhone の画面では正直区別付きませんから。iPhone 用の漢和辞典等にコピペして見ると拡大表示で違いがわかる程度です。従いまして、対処法は、適切な候補の方を（よく確認して）何度か確定させておくことだと思いますし、それで回避できる問題でもあります。（よく使う熟語ならば、「連絡先」の氏名欄にダミーでその熟語を登録しておけば良いでしょう。「グループ分け」は「ダミーの単語登録」とかしておけば良いかも (^^)？ そうすれば、iPhone の日本語変換の候補に一発で表示されるようになります。）

　実は、JIS (ISO-2022-JP) を優先させるという仕組みには（仮に何らかの特殊な方法で学習機能をお馬鹿にせずとも済む方法が見つかったとして）別の根本的な（倫理的な？）問題があります。それは、iPhone は元々、Unicode 対応でパソコンとの完全互換性を謳った機器です。基本的には「連絡先」や「カレンダー」等を母艦であるパソコンの同様のソフトと同期させて使うのが前提です。さらに iPhone のメールは、特殊な携帯メールではなく、通常のインターネット・メールであることも“ウリ”の１つです。当然、それを目的に iPhone を導入した方々も多いでしょう。Unicode の利用を前提としたユーザにとっては、例えば、自分の「高橋」という名字の「高」の文字が「ハシゴダカ」[U+9AD9] [-] の「��橋」さんは、常に自分の名字は正しい「ハシゴダカ」で変換して欲しいはずです。ところが、JIS (ISO-2022-JP) 優先を固定してしまうと、常に「クチダカ？」の方の「高橋」[U+9AD8] [8D82] が先に候補に挙がることになり、非常に不便なことになります。つまり、「日本語変換の単語候補は JIS (ISO-2022-JP) を優先させて表示して欲しい」という主張は、言い換えれば（もちろん、そういうご提案をされた方々がそういう意図でいたと言うことではありません！）「iPhone を iPhone として使いたがっている本来のユーザよりも、携帯ユーザーの都合を優先させて欲しい！」という、ある意味、自分勝手な要求だと捉えられかねません。


運命のヒト> 私の文字化け現象は、
運命のヒト> 文字 ＋ 絵文字
運命のヒト> で多いような気がします。(たまに文字だけでも文字化けしますが)

　私はまたまた専門ではないのでわからないのですが、想像するに、恐らく、これの問題はやはり“絵文字”の処理なんではないでしょうか？ やはり相当無理して異質な要素を埋め込んでいるわけですから。私は絵文字は使わないので実験できないのですが、試しに以下のような具合に文字を入力してみたらいかがでしょうか？

1) 「文字列」「半角スペース」「絵文字」

2) 「文字列」「半角スペース」「絵文字」「半角スペース」

　余分な半角スペースが入ってしまいますが、もしかすると、これで絵文字混在文書における文字化け問題が回避できるかも知れません...。（半角スペースを挿入するのは、文字コードの区切りを明確に伝えるためです。）

　これでダメだとしても、色々試せば、その内に、最適の（＝次善の）方法が見つかるかも知れませんね (^^)。

書込番号：10152119

[Cogito ergo sum]

　＞tac_tacさん

> Gmailで送れば文字化けしない（しにくい？）と思いますがいかがでしょう？

　今回の流れでは、どうやら Unicode (UTF-8) でしか定義されていない文字と、絵文字との組み合わせによるトラブルということに落ち着きつつあるように見えますが、もしも文字コードの問題だとすると、Gmail 等を使っても、やはり JIS (ISO-2022-JP) 以外の文字を使ってしまえば、文字化けは発生すると思われます。絵文字との混在による文字化けは、もしかすると、利用するメーラーやサーバによって違いが出るかも知れませんね。

　ちなみに、パソコンから携帯にメールを送った場合にも、マックから送信したメールは文字化けする確率が高いようです。これは恐らく、iPhone Mail とほぼ同じメカニズムだからだと思われます。ところが、Windows から携帯宛に送信したメールではあまりそういう文字化けは起こっていないようです。これは、恐らく、Windows からのメールは「CP932」の文字コードであっても（例えばメールのヘッダ部分には「Content-Type: text/plain; charset=CP932」という情報が埋め込まれなければなりません）、「JIS (ISO-2022-JP)」というヘッダ情報を埋め込んで（例えば「Content-Type: text/plain; charset=iso-2022-jp」のように）送信するので、携帯メール側をうまく騙せているのだと思います。

書込番号：10152185

[運命のヒト]

Cogito ergo sumさん、お返事ありがとうございます。

＞私の経験では基本的に携帯メールしか使われない方々は、インターネットの本来のメールでは“禁じ手”のルール違反の文字入力をされています。

Cogito ergo sumさんのおっしゃるとおり、ルール違反の文字入力をしているのかもしれません。
そんなルールがあることも知りませんでした。(恥ずかしいです)



＞例えば「三点」の「…」や代用に３つの半角のピリオドを並べた「...」ではなく、中黒「・」を半角にしたものを３つ並べたり、句点「。」を半角にしたものを３つ並べたりしているのを頻繁に見かけます。

上の書き込みで「・・・」使ってしまってます。
申し訳ありません。



＞例えば、iPhone Mail や Apple Mail のように多様な文字コードに対応しているメーラーの場合は、逆にそれが災いして、識別不能な文字コードのメール（＝一見複数の文字コード規格の文字列が混在しているありえないメール）を送信しようとしたときに、間違った文字コードと誤認して、それで送信してしまうと、受信した側のソフトでは「読めない！」メールとして認識されてしまうのではないでしょうか？

そうだと思います。
Eメールは多様な文字コードに対応していて、MMSは国産携帯と一緒で1つの文字コードに固定されてる。
そう考えるとEメールで文字化けするメールが、MMSでは文字化けしない現象も納得出来ます。



＞iPhone で携帯ユーザーとメールのやり取りをしたいのであれば、「文字化け」と「絵文字」のどちらを優先させたいのかで、どのように使うかを決めなければならないでしょう。

おっしゃるとおりです。
携帯メールに戻るのは出来れば避けたいですね。
電波状況が良ければ携帯メールにはMMSで対応したいですが、自宅での電波状況が最悪なのでMMSは厳しいかと．．．

文字コードの問題であれば素人にはどうしようもないので、携帯メールの相手には申し訳ないですが、文字化け覚悟でEメールでやり取りするのが今の私にはベストかもしれません。



Cogito ergo sumさん、毎回詳しくお答え頂きましてありがとうございます。
本当に感謝致します。





tac_tacさん、お返事ありがとうございます。

確かにEメールやSMS/MMSで作成した文章をGmailで受信したら、問題なく表示されました。

が、携帯(SH903i)では文字化けはありませんが、絵文字が「・」で表示されてしまいました。

やはりEメールで携帯メールに送信する場合は、文字化け覚悟でやり取りするしかないみたいですね。

書込番号：10152332

[tac_tac]

やはり、受信側の対応／非対応が原因ってことで落ち着きそうですね。
（私がやり取りしている人々は、文字化けを起こす機種を持っていなかっただけなのかな…）

スクロールせずに収まる程度の内容なら、キャプチャして画像添付するって安直な手もありますね（笑）
これならレイアウト・文字・絵文字も意図したまま届きますので ^^

書込番号：10152365

[Reflex0922]

Cogito ergo sumさん
　日本語変換ソフトを学習の件、ご指摘ありがとうございます。
　UTF-8を選んだ状態（学習した状態）が残っていたのかもしれません。
　以後注意します！

このスレで文字+絵文字の文字化けするパターンとして挙がっているのは、
　”口べた”（+絵文字）
　”飲食禁止”（+絵文字）
ですね。両方で再度試しましたが、”口べた”も”飲食禁止”もJIS (ISO-2022-JP) で発生しています。根拠はPCメーラ上の表示がISO-2022-JPになっているからです。（前述の文字化けした際の”頬”はPCメーラ上、UNICODEになっていました）
なので、各キャリアのiPhone絵文字サポート時の変換処理の問題かなと思いました）
　

書込番号：10152422

[Reflex0922]

あとCogito ergo sumさんにご提案頂いた下記を試してみましたが、残念ながら事象は解決しませんでした。　
1) 「文字列」「半角スペース」「絵文字」
2) 「文字列」「半角スペース」「絵文字」「半角スペース」

書込番号：10152431

[Cogito ergo sum]

　＞Reflex0922さん＋運命のヒトさん

Reflex0922> 口べた（+絵文字　※顔絵文字１段目左から２つめ）をドコモに送ると
Reflex0922> [戟ャラた]（+絵文字）
Reflex0922> に文字化けします。絵文字は正しく変換されました。
Reflex0922> PCメーラだとISO-2022-JPで正しく表示します。

運命のヒト> 1.食・・・文字化けしない
運命のヒト> 2.飲食禁止・・・文字化けしない
運命のヒト> 3.飲食禁止 ＋ ビックリマークの絵文字 ＋ 食事マークの絵文字
運命のヒト> ・・・飲FH禁止 ＋ ビックリマークの絵文字 ＋ 食事マークの絵文字

　これまで絵文字を使ってメールを送ったことがなかったのですが、これを機会に実験してみました。すると、Reflex0922さんと運命のヒトさんの実験と全く同じ結果が出ました。試しに文字列と絵文字の間に半角のスペースを挿入したものも送信してみましたが、単に半角のスペースが半角のスペースになっただけで、文字化け自体は変わりませんでした。

　Mac OS X 上の Apple Mail で受信したものは、MobileMe のアカウントに届いたものは、絵文字の部分が全て「〓」（ゲタ）[U+3013] [81AC] に置換されていました。（＝元々の絵文字は当然別々の文字コードが割り当てられていたはずですが、Apple Mail はそれを全て「〓」という１つの文字コードに置き換えてしまいました。ちなみに、「〓」は印刷所で適切な活字が見つからない場合に、活字ができてくるまで臨時にその場に埋め込んでおく記号です。）

同じ Apple Mail の Gmail のアカウントに届いたものは絵文字の部分は縦の長方形に斜線で×のようなものが描かれている記号で表示されていましたが、外見は同じでも、全て別々の文字コードが割り当てられていました。

例えば、

「ニコニコ」　[U+E6F2]
「びっくり」　[U+E821]
「食事」　　　[U+E6DF]

となっています。これらは全て Unicode の「私的領域」（外字）エリアの文字です。Gmail の場合は、システム的に表示できずともオリジナルの文字コードを（不適切であったとしても）残す仕組みになっており、MobileMe の方は不適切と思われる文字は排除する仕組みになっているようです。MobileMe に届いたメールも、Gmail に届いたメールも同じ Apple Mail で受信していますので、メーラーの設計の問題ではないようです。

　Apple Mail に届いたメールのヘッダには「Content-Type: text/plain; charset=iso-2022-jp; format=flowed」という情報が埋め込まれていましたので、iPhone の iPhone Mail からは JIS (ISO-2022-JP) の文字コードで送信されたようです。

　さらに実験してみました。今度は、MobileMe と Gmail で受信したメールを ＠i.softbank.jp のアカウントとドコモの携帯に送り直してみたのです。

　その結果は、ドコモでは MobileMe から送り直したものは MobileMe に届いたメールと全く同じ文面で、「文字化け無し」＋「絵文字の部分は〓のまま」の状態で受信されました。Gmail からドコモに送り直したものは「文字化け無し」で、かつ、絵文字も表示されましたが、絵文字自体が全く別の絵文字に文字化けしていました。最初の「ニコニコ」は「悲しい顔」に、「びっくり」は「・」に、「食事」も別の絵に化けていました。どちらから送信されたメールもドコモの携帯上では文字化けは解消されていました。

　iPhone の iPhone Mail の ＠i.softbank.jp のアカウントで受信したメールに関しては、マックの MobileMe のアカウントから送り返されてきたメールは「〓」が「〓」のままで、MobileMe に届いたメールと全く同じ文面でした。Gmail から送り直したものも絵文字の部分は「□」で表示されており、Apple Mail の Gmail 上で見た文面と全く同じでした。さらに、この「□」の部分の文字コードを確認したところ、文字コードも正しく送られてきていたことが分かりました。

　以上のことから分かることは、ソフトバンクが提供する iPhone の絵文字の仕組みは単なる文字コードだけの問題ではないようです。（もしもそうならば、ソフトバンクのアカウント以外でも絵文字が使えるはずですからね。）絵文字を送信するときに（素人の私には分からない）何らかの信号を絵文字の直前に独自に挿入しているのでしょうか？ そのために、日本の国産携帯では逆に文字化けが発生してしまうのかも知れません。

　試しに、

「飲食禁止」「ビックリマークの絵文字」「食事マークの絵文字」

を1行ではなく、それぞれ改行して３行にして

「飲食禁止」
「ビックリマークの絵文字」
「食事マークの絵文字」

のようにして実験してみましたが、ドコモの FOMA F904i で受信した限りでは、行が違うのに、「飲FH禁止」のように文字化けしてしまっていました。こりゃ、お手上げですな (^"^;)。

　顔文字が使えなくて困っている方は、やはりアップルのフィードバックに連絡して圧力を加えるしかないのでしょうね...。（同時に国産キャリアには「Unicode (UTF-8) に対応せよ！」との圧力を掛ける必要があるでしょう。）

書込番号：10152446

[Cogito ergo sum]

　＞運命のヒトさん

> おっしゃるとおり、ルール違反の文字入力をしているのかもしれません。
> そんなルールがあることも知りませんでした。

例えば以下のようなサイトが参考になるかも知れません：

「機種依存文字 - Wikipedia」　http://ja.wikipedia.org/wiki/機種依存文字

「文字化け - Wikipedia」　http://ja.wikipedia.org/wiki/文字化け

「メールアドレス - Wikipedia」　http://ja.wikipedia.org/wiki/メールアドレス

「電子メールで使ってはいけない文字 - パソコントラブルＱ＆Ａ」　http://www.724685.com/weekly/type/table08.htm

「www.dell-faq.com -Q&A検索- FAQ詳細」　http://www.dell-faq.com/detail.asp?baID=1&FAQID=197071

「メールに使ってはいけない文字 ― sango.lab.tkikuchi.net」　http://sango.lab.tkikuchi.net/Members/tkikuchi/courses/se2007/x

「インターネット上で使ってはいけない文字・記号」　http://www.takibi.org/rider/bbs/attention.htm

「機種依存文字劇場」　http://apex.wind.co.jp/tetsuro/izonmoji/

「送ってはいけないメール」　http://www.powerhouse.ne.jp/labo/pieces/index114.html

「メールには使えない文字がある――メールとウェブのお役立ちメモ」　http://homepage1.nifty.com/akshiba/mail_web/tukaenaimozi.html

　上の参照ページに「メールアドレス」という項目も入れてありますが、実は、携帯メールのメルアドのほとんどがメールアドレスのルールに違反しているからです。（これも「一事が万事」でメールの文字化け問題と繋がっていると言えるでしょう。）パソコン側から携帯のメルアドにメールを送ろうとすると、セキュリティの厳しいメーラーでは「不正な宛先です」という警告がでて、送信自体ができなくなるということもありえます。携帯メールユーザの方々はスパムメールを避けようと複雑なメルアドを選択しがちですが、複雑なのは良いのですが、メールアドレスの付け方の“文法”は守ってもらわないと他人に迷惑を掛けることになってしまいます。

　なお、iPhone は Unicode で、現在の Windows や Macintosh 等のパソコンの最新の OS も Unicode 対応になっているのだが、国産携帯は Unicode に対応していないと書いてきましたが、さらに問題をややこしくしているのが、日本で一番ユーザの多い Windows が、OS 自体の内部処理は Unicode なのに、表面のアプリケーション等ではわざわざ Shift JIS に変換して動作するようになっている場合が多いのです。Mac OS X の場合は、基本的にはアプリケーションは文字コードにタッチせず、OS レベルで文字コードを決定していますので（例外はあります）、ソフトの設計者が文字コードを意識せずとも、彼が作ったアプリケーションは勝手に Unicode で動いてくれます（＝日本語を知らない外国人の開発者が日本人や日本人のことなど全く意識せず作ったアプリケーション上でも普通に日本語やアラビア語、中国語などが使えてしまうということです！）。ところが、Windows の場合、アプリケーション上で Unicode を扱うには、OS レベルで Unicode だったものを、あえて Shift JIS でアプリを動かしているので（なぜ??????!!）、Unicode 対応のアプリは、さらに特殊な方法で Unicode が必要な場合には対応するという目の回るような仕組みを（屋上屋？）作っているようなので、さらに文字化け等の問題は深刻、かつ解明が難しくなっているようです。

　これらの問題はいずれ、世界中のメールや文書ファイル、ホームページでの標準文字コードが Unicode になることで解決するはずです。（最近、欧米のホームページは大多数が Unicode になっていますが、日本のサイトはいまだにほとんどが頑なに JIS (ISO-2022-JP) や Shift JIS、EUC しか通さないものが多いです。単にページのソースの先頭に「<meta http-equiv="content-type" content="text/html;charset=utf-8"」という1行を入れておけば済む話なんですけどね。不思議です。）まぁ、Unicode になったらなったで、今度は UTF-8 や UTF-16、その他のバリエーションがあり、またまた問題が発生はするのですが、現在のようなトラブルは発生しなくなると思われます。Unicode が標準になるまではじっと我慢するしかないでしょうね。しかし、少しでも早く Unicode 時代を迎えるためには、ユーザも積極的に Unicode のメリットを理解し、活用するようにすることだと思います。ちょっと考えてみれば、たった１つの共通の文字コードシステムが普及すれば、それからは何も考えずとも世界中で世界中の文字を混ぜても使えるし、誰から誰に渡したファイルやメールでも文字化けしたり、読めないという問題がなくなるのです。素晴らしいではありませんか！ 確かに現在国産携帯メールのユーザとの間のやりとりでは不便があります。しかし、要求すべきは、明らかに iPhone に対して後ろ向きに「もっと不便になれ！」ではなく、国産携帯に対して前向きに「もっと便利になれ！」ということなのではないでしょうか？

書込番号：10152614

[うみのねこ]

Cogito ergo sumさん
話しが冗長。
長すぎて読めない。
熱い思いがあるのはわかるけど、もっと短く端的に説明できないかな？
（なんか前にも言われてたような気がするけど）

書込番号：10152657

[運命のヒト]

Cogito ergo sumさん、お返事ありがとうございます。

＞パソコンの日本語入力ソフトや携帯のソフトでも同じだと思いますが、使用頻度によって優先度が高く評価されますし、最後に使った文字が最優先されて表示されますので、JIS (ISO-2022-JP) の文字を最優先にして固定しておくということ、つまり日本語変換ソフトを学習しないように、わざと“お馬鹿”にするというのは現実的ではないでしょう。

なるほど、言われればそうかもしれませんね。
JIS (ISO-2022-JP) の文字を最優先にしておけば、文字化け解消につながると安易に考えてしまいました。



＞対処法は、適切な候補の方を（よく確認して）何度か確定させておくことだと思いますし、それで回避できる問題でもあります。
＞（よく使う熟語ならば、「連絡先」の氏名欄にダミーでその熟語を登録しておけば良いでしょう。「グループ分け」は「ダミーの単語登録」とかしておけば良いかも (^^)？ そうすれば、iPhone の日本語変換の候補に一発で表示されるようになります。）

連絡先に登録もいいですが、登録単語が大量になってしまいそうですね。
こういうとき携帯にある様な「単語登録」機能が備わってればなぁと思ってしまいます。



＞1) 「文字列」「半角スペース」「絵文字」
＞2) 「文字列」「半角スペース」「絵文字」「半角スペース」

Cogito ergo sumさんやReflex0922さんも試して頂いたみたいですがダメですよね。この方法は私も以前試してみました。文字化けしないと思ったんですが...



＞試しに、
＞「飲食禁止」「ビックリマークの絵文字」「食事マークの絵文字」
＞を1行ではなく、それぞれ改行して３行にして
＞「飲食禁止」
＞「ビックリマークの絵文字」
＞「食事マークの絵文字」
＞のようにして実験してみましたが、ドコモの FOMA F904i で受信した限りでは、行が違うのに、「飲FH禁止」のように文字化けしてしまっていました。こりゃ、お手上げですな (^"^;)。

色々試して頂きありがとうございます。
改行して３行にする方法は思いつきませんでした。が、ダメでしたか...
本当にお手上げですね。



色々なサイトを教えて頂きありがとうございます。
まだ全て拝見していませんが、あとで拝見させて頂きます。

Windowsの場合、アプリケーション上でUnicodeを扱うには、OSレベルでUnicodeだったものを、あえてShift JISでアプリを動かしていることは知りませんでした。何故Windowsはこんな面倒なことをするのでしょうか？疑問です。



＞世界中のメールや文書ファイル、ホームページでの標準文字コードが Unicode になることで解決するはずです。

そうなればいいですね。でも難しいでしょうね。
標準文字コードがUnicodeになれば、国産携帯も嫌でもUnicodeにするでしょうね。





tac_tacさん、お返事ありがとうございます。

＞やはり、受信側の対応／非対応が原因ってことで落ち着きそうですね。

携帯の文字コードがUnicodeにならないかぎり、この先も文字化けに悩まされそうですね。



＞スクロールせずに収まる程度の内容なら、キャプチャして画像添付するって安直な手もありますね（笑）
＞これならレイアウト・文字・絵文字も意図したまま届きますので ^^

おもしろ発想です！ちょっと試してみたいですね（笑）





Reflex0922さん、お返事ありがとございます。

Reflex0922さんも色々試して頂いてありがとうございます。
結局iPhoneから携帯にメールをするには、どの文字・どのような入力で文字化けが起こるか把握しなければならないかもしれませんね。
文字化けが嫌ならMMSから送信か、国産携帯を持ってメールするかしかないですね。

書込番号：10152778