アカウント名:
パスワード:
>Content-Transfer-Encoding: base64 ↑はあんまり筋のいい実装とは思えませんね。
別ＡＣです。
本当にこういうメールを正しく受け取れない携帯電話が存在するのかどうか確認していないが、 もし存在するならば、技術者たる者が使うべき代物ではないだろう。
読める読めないのはなしではなくて、
「受け取るときは先進的に、送るときは保守的に」
ということを元ＡＣさんのコメントは言っているんだろうと思いますよ。
今でも、もしかしたら最上位ビットを落としてしまう経路があるかも知れないし、 それを警戒して途中で base64 に変換してしまう経路は確かにありそうだ。途中で変形される ことを回避するために最初から base64 にしておくことは別に珍しくも何ともない。
日本語をUTF-8とBase64で安直にエンコードする設計が、壊れたMTAに配慮したせい? まともな神経ならおかしいと疑うべきです。 Appleは日本市場で製品を売ってきた長い実績があります、ISO-2022-JPを知らないはずがない。 手抜きと傲慢を感じます。
技術的な裏付けがある発言とは思えない。 これのどこが「すばらしい洞察」か。
しかし特に標準に違反している訳でもない物を「極端に相性が悪い」などとアップルの落ち度であるかのように表現するのは如何な物か。
Appleは日本市場で製品を売ってきた長い実績があります、ISO-2022-JPを知らないはずがない。 手抜きと傲慢を感じます。
UI を日本語にしたときだけそれが出来なくなるというのは、まったく不合理な設計だ。
いやまったく。 それと、あなたがAppleのソフトに無知であることはよく分かりました。
Mac OS Xで使われているApple Mailを例にあげて少し詳しく説明しましょう。 日本語環境でメールを作成すると、使われている文字の範囲によってcharsetが決定されます。 ASCIIだけならUS-ASCII, 日本語だけならISO-2022-JP, 多言語混在ならUTF-8 「日本語UIで多言語メールを作成すること」と、「なるべく敷衍した形式を用いること」は適切なバランスで以前から両立していました。
ですが、iPod
Apple Mailを例にあげて少し詳しく説明しましょう。[中略] ASCIIだけならUS-ASCII, 日本語だけならISO-2022-JP, 多言語混在ならUTF-8
iPod touchはそれまでの流れを考慮していない。
最終的にUTF-8を使わなければならない状況があることは認めます。
「なるべく敷衍した形式を用いること」
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
正直な話 (スコア:1)
日本語メールとの相性が極端に悪いという実用性の問題もあるし、
あれを「Apple上納金込みの割高プランでわざわざ契約したい」
というアレゲな利用者がどれほどいるか……。
それにどうせSIMロック解除方法だって出回（略
即解されまくって海外含む転売まみれってのだけは勘弁してほしいものです。
Re: (スコア:2, 興味深い)
あいにく、このようなことを聞いたことがないのですが、どういうことでしょう？
興味があります。
日本語のIMがなかった、ということでしょうか？
よろしければご教示ください。
Re:正直な話 (スコア:2)
iPod touchから送信したメールが、ウィルコムやauで文字化けする。ということでしょう。
UTF-8でエンコードされたメールを、ウィルコムやauがShift-JISとして処理するのが原因だそうです。
Re:正直な話 (スコア:2, 参考になる)
ファームウェアは最新です。本文は載せていませんが、当業者がヘッダから想像できる
エンコード方式であり、とくにおかしな形式ではありませんでした。
Content-Type: text/plain;
charset=UTF-8;
format=flowed
X-Mailer: iPod Mail (4A102)
Mime-Version: 1.0 (iPod Mail 4A102)
Subject: =?UTF-8?B?44OG44K544OI?=
Content-Transfer-Encoding: base64
Re: (スコア:0)
>>Subject: =?UTF-8?B?44OG44K544OI?=
↑はともかく
>>Content-Transfer-Encoding: base64
↑はあんまり筋のいい実装とは思えませんね。
「受け取るときは先進的に、送るときは保守的に」
Re:正直な話 (スコア:2, すばらしい洞察)
それを警戒して途中で base64 に変換してしまう経路は確かにありそうだ。途中で変形される
ことを回避するために最初から base64 にしておくことは別に珍しくも何ともない。
本当にこういうメールを正しく受け取れない携帯電話が存在するのかどうか確認していないが、
もし存在するならば、技術者たる者が使うべき代物ではないだろう。
Re:正直な話 (スコア:1, 参考になる)
別ＡＣです。
読める読めないのはなしではなくて、
ということを元ＡＣさんのコメントは言っているんだろうと思いますよ。
Re: (スコア:0)
Re: (スコア:0)
日本語をUTF-8とBase64で安直にエンコードする設計が、壊れたMTAに配慮したせい?
まともな神経ならおかしいと疑うべきです。
Appleは日本市場で製品を売ってきた長い実績があります、ISO-2022-JPを知らないはずがない。
手抜きと傲慢を感じます。
技術的な裏付けがある発言とは思えない。
これのどこが「すばらしい洞察」か。
Re:正直な話 (スコア:1, 興味深い)
どっちかと言えば「先進的に受け取って」ない相手の電話の落ち度じゃね？
Re: (スコア:0)
「相性が悪い」という批判は甘受しなきゃならんでしょう。
Re: (スコア:0)
Re: (スコア:0)
>亀なみ知能の技術者でなければこういうときはQuated-Printableにする。
日本語のメールをQPにしたってほとんどの部分は読めないし
サイズが膨らむだけでBase64より悪いだろ。
Re: (スコア:0)
Re:正直な話 (スコア:1)
UI が国際化されていて、スイッチひとつで日本語表示に切り替わるのは結構なことだ。
しかし日本語 UI を好むユーザが、必ずしも日本語と英語だけでメールを書くとは限らん。
例えば気まぐれに Doppelgänger とか、배용준とか、そういう単語を使いたくなるかも知れん。
UI を日本語にしたときだけそれが出来なくなるというのは、まったく不合理な設計だ。
かといって、日本語モードのときだけ妙に膨れ上がったソフトウェアを使うというのは、
限られたリソースの使い方としてまずいし、テスターは拒否するだろうし、話にならない。
UTF-8 と base64 に対応できないサイドにこそ "手抜きと傲慢" を感じない訳には行かない。
Re: (スコア:0)
いやまったく。
それと、あなたがAppleのソフトに無知であることはよく分かりました。
Mac OS Xで使われているApple Mailを例にあげて少し詳しく説明しましょう。
日本語環境でメールを作成すると、使われている文字の範囲によってcharsetが決定されます。
ASCIIだけならUS-ASCII, 日本語だけならISO-2022-JP, 多言語混在ならUTF-8
「日本語UIで多言語メールを作成すること」と、「なるべく敷衍した形式を用いること」は適切なバランスで以前から両立していました。
ですが、iPod
Re:正直な話 (スコア:1)
そうすると約束したわけでもない。iPod Mail は違う環境制約の中で、タッチパネルに
適応した Apple Mail にも出来ない機能を実現している。当然トレードオフがある。 過去の流れということで言えば、1998年という大昔に Internet Mail Consortium が
UTF-8 に対応しましょうという勧告 [imc.org]を出している。このことから考えても、
2008年の御世に UTF-8 が読めないなどという怠惰と傲慢が、罷り通るはずがない。 じゃあ、現時点で UTF-8 を読めない携帯電話を売っている会社は、(もし存在するならば)
どうしなきゃいけないだろうか? UTF-8 の使用を最小限に絞ってください、と他社にお願いすれば、
UTF-8 を全然読めない MUA を平然と販売し続けても構わないのか? そんなわけあるまい。
さいわい携帯メールはなんらかのゲートウェーを使って集中管理されている。たとえ市中に
出回っている端末がアホでも、ゲートウェーで UTF-8 ⇔ Shift_JIS の変換を担えるはずだ。
("Doppelgänger" が "Doppelg〓nger" になるのは仕方ない。)
余談だが、あなたの敷衍という言葉の使い方は、なにかが違う。hogehoge を敷衍する、
というときの hogehoge とは、学説、原則、主義主張、あるいは「思いのたけ」などであるらしい。
Re: (スコア:0)
一応OSXでの解決策 [apple.com]はありますが。