アカウント名:
パスワード:
という話ではなかったんですね。
送る人が多くないと、受信側が対応してくれないような・・・
えっと、今回の Gmail の動きはまさにその鶏と卵の関係を断ち切るためなわけで。
国際化メールアドレス (US-ASCII 外の文字を含むメールアドレス) がこれまで普及してこなかった背景には、
1. 国際化メールアドレスを使いたくても、送受信の相手が対応していない (国際化メールアドレスにメールを送ったり国際化メールアドレスからのメールを受け取ったりできない) から無理。 2. 国際化メールアドレスにメールを送ったり国際化メールアドレスからのメールを受け取ったりできるようにしても、国際化メールアドレスを使っている人がいないから無意味。
という鶏と卵の関係がありました。今回、 Gmail では国際化メールアドレスにメールを送ったり国際化メールアドレスからのメールを受け取ったりできるようになったわけですが、現時点では 2. に書いたようにほぼ無意味です。でも、こんな風に国際化メールアドレスにメールを送ったり国際化メールアドレスからのメールを受け取ったりできるメールサーバー・メールクライアントが増えてくれば、 1. の理由で国際化メールアドレスを使うことを躊躇する人が減って、国際化メールアドレスが普及することが期待されます。今回の Gmail の動きは国際化メールアドレスの普及に向けての一歩ということでしょう。
メールヘッダは窮屈でいいんですよ。日本語を含むマイナー言語が使いたきゃサブジェクトと本文でやればいいのに…
国際化メールアドレスなんて管理者の悪夢でしかない。
昔はメールに日本語は使えなかった。その後、メールの本文に日本語が使えるようになった。その動きを見て、「メールは窮屈でいいんですよ。日本語が使いたきゃメール以外の手段でやればいいのに…」と言っている人もきっといただろう。
でも、本文には日本語が使えるようになってからも、サブジェクトには英語しか使えなかった。その後、サブジェクトにも日本語が使えるようになった。それを見て、「メールのサブジェクトは窮屈でいいんですよ。日本語が使いたきゃ本文でやればいいのに…」と言っている人もきっといただろう。そういうこと。
でもキミたち、変数名に日本語が使えるプログラミング環境とか嫌悪するよね。え、しない？ でも積極的に使ってる人みたことない。
ヘッダは窮屈でいいに賛成。つーかせめてMIMEは維持しないと。生UTF-8なんてとんでもない。理由。メール本文の文字コードはヘッダにContent-Type: text/plain; charset=UTF-8などと書いて指定できるが、じゃあ、ヘッダの文字コードを指定できる場所はあるのか？その妥協点がMIMEだったはず。今ですらたまに（spamに多いが）ヘッダのSubject:等に生のSHIFT_JISとかをつっこんでくる奴がいる。生SHIFT_JISと生UTF-8なんて、とくに短い文字列では機械的に区別（推測）できないことも多い。だいたい文字コードを指定せずにクライアントに推測させるなんて、原理主義者が一番嫌う動作じゃないのか？
このスレッドでは国際化メールアドレスの話をしていて、メッセージヘッダーに MIME エンコードしない UTF-8 を書くのを認めるかどうかなんて話はしていないつもりなんだけど、僕何か勘違いしてる?
リンク先見た？
指摘ありがとう。国際化メールアドレスの仕様で、メッセージヘッダー (とか SMTP コマンドとか) では UTF-8 を生で書くことになっているのか……。 (RFC 6530 7.2 節 [ietf.org]を見ると「移行期にはメッセージヘッダーは UTF-8 を MIME エンコードしてもいい」と書いてあるけれど。)
SMTP コマンドの方は MIME なんて使えないからどうせメールサーバーは拡張しないといけない、それならメッセージヘッダーも生 UTF-8 を許しちゃえってことかな。まあ、 SMTP が最初に作られた頃には Unicode なんてなかったから今みたいな形になったのであって、今ではもうあちこち Unicode が当たり前になっているんだからメールも全部 UTF-8 にしようぜというのは (その方が賢いかどうかは別として) 理解はできる。
理由。メール本文の文字コードはヘッダに Content-Type: text/plain; charset=UTF-8 などと書いて指定できるが、じゃあ、ヘッダの文字コードを指定できる場所はあるのか？
受信側のメールサーバーは「このメッセージは SMTPUTF8 拡張を有効にした SMTP で送られてきた」と知っているから、メッセージヘッダーが UTF-8 で書かれていることを知っているわけだけど、そのことがメッセージ自体には書かれていないので、 POP とか IMAP とかでほかから読むときに情報が失われるとしたら問題だよね。どうなっているんだろう。
むしろ、POP とか IMAP を使わせず Web ブラウザまたは Android MUA で読んでもらうためにこの仕様を積極的に進めているのじゃないかな。IMAP を改定して公式に UTF8 対応してくれるならそれはそれで嬉しい。
Webブラウザでメールってのはメールサーバがそういうふうに変換してhttpで読むんだからわかるとして、AndroidのMUAってPOPもIMAPも使わないの？じゃあどうやってるの？（実は内部でブラウザ呼び出してる？それならまあわからんでもない）
国際化メールアドレスの否定は管理者の都合でしかないんですね。
＞国際化メールアドレスの否定は管理者の都合でしかないんですね。そうです。
IDは認識されてこそなのですから、メールアドレスは発音は判らなくても、一字ずつ読める必要は確実にあるのです。
多くの人が綴りを読む事も出来ないメールアドレスのアイデアは、アイデア倒れだと思います。
アルファベットが読めるのは普及率が高いのに合わせて教育してるおかげでしょ。今回のメアドのように、もっと国際化が進めばその前提は変わる。
メールアドレスはUTF-8ビットストリームと一意に読めないといけないはしご高のたかはしさんにメールが送れないのでは困るし、かっぱ巻きとマグロ寿司さんとマグロ二貫さんは違うかもしれないでは困る
＞ 管理者の悪夢
cool.com に高値が付いた頃から延々とこの手の妙な錬金術で儲けようと企む連中がいますからねえ。進んでそういう尻馬に乗ってしまうあたりに 現在のGoogleの技術的なセンスの多寡が見えるような気がします。
仕事で使ってると、受け取れないほうが悪いという人の方をが多いんです。winmail.datとか
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
Gmailで日本語（非ラテン文字）アカウントが取れる。 (スコア:0)
という話ではなかったんですね。
送る人が多くないと、受信側が対応してくれないような・・・
Re:Gmailで日本語（非ラテン文字）アカウントが取れる。 (スコア:4)
えっと、今回の Gmail の動きはまさにその鶏と卵の関係を断ち切るためなわけで。
国際化メールアドレス (US-ASCII 外の文字を含むメールアドレス) がこれまで普及してこなかった背景には、
1. 国際化メールアドレスを使いたくても、送受信の相手が対応していない (国際化メールアドレスにメールを送ったり国際化メールアドレスからのメールを受け取ったりできない) から無理。
2. 国際化メールアドレスにメールを送ったり国際化メールアドレスからのメールを受け取ったりできるようにしても、国際化メールアドレスを使っている人がいないから無意味。
という鶏と卵の関係がありました。今回、 Gmail では国際化メールアドレスにメールを送ったり国際化メールアドレスからのメールを受け取ったりできるようになったわけですが、現時点では 2. に書いたようにほぼ無意味です。でも、こんな風に国際化メールアドレスにメールを送ったり国際化メールアドレスからのメールを受け取ったりできるメールサーバー・メールクライアントが増えてくれば、 1. の理由で国際化メールアドレスを使うことを躊躇する人が減って、国際化メールアドレスが普及することが期待されます。今回の Gmail の動きは国際化メールアドレスの普及に向けての一歩ということでしょう。
Re:Gmailで日本語（非ラテン文字）アカウントが取れる。 (スコア:1)
メールヘッダは窮屈でいいんですよ。日本語を含むマイナー言語が使いたきゃサブジェクトと本文でやればいいのに…
国際化メールアドレスなんて管理者の悪夢でしかない。
Re:Gmailで日本語（非ラテン文字）アカウントが取れる。 (スコア:2)
昔はメールに日本語は使えなかった。その後、メールの本文に日本語が使えるようになった。その動きを見て、「メールは窮屈でいいんですよ。日本語が使いたきゃメール以外の手段でやればいいのに…」と言っている人もきっといただろう。
でも、本文には日本語が使えるようになってからも、サブジェクトには英語しか使えなかった。その後、サブジェクトにも日本語が使えるようになった。それを見て、「メールのサブジェクトは窮屈でいいんですよ。日本語が使いたきゃ本文でやればいいのに…」と言っている人もきっといただろう。そういうこと。
Re: (スコア:0)
でもキミたち、変数名に日本語が使えるプログラミング環境とか嫌悪するよね。
え、しない？ でも積極的に使ってる人みたことない。
Re: (スコア:0)
ヘッダは窮屈でいいに賛成。
つーかせめてMIMEは維持しないと。生UTF-8なんてとんでもない。
理由。メール本文の文字コードはヘッダに
Content-Type: text/plain; charset=UTF-8
などと書いて指定できるが、じゃあ、ヘッダの文字コードを指定できる場所はあるのか？
その妥協点がMIMEだったはず。
今ですらたまに（spamに多いが）ヘッダのSubject:等に生のSHIFT_JISとかをつっこんでくる奴がいる。
生SHIFT_JISと生UTF-8なんて、とくに短い文字列では機械的に区別（推測）できないことも多い。
だいたい文字コードを指定せずにクライアントに推測させるなんて、原理主義者が一番嫌う動作じゃないのか？
Re:Gmailで日本語（非ラテン文字）アカウントが取れる。 (スコア:2)
このスレッドでは国際化メールアドレスの話をしていて、メッセージヘッダーに MIME エンコードしない UTF-8 を書くのを認めるかどうかなんて話はしていないつもりなんだけど、僕何か勘違いしてる?
Re: (スコア:0)
リンク先見た？
Re:Gmailで日本語（非ラテン文字）アカウントが取れる。 (スコア:2)
指摘ありがとう。国際化メールアドレスの仕様で、メッセージヘッダー (とか SMTP コマンドとか) では UTF-8 を生で書くことになっているのか……。 (RFC 6530 7.2 節 [ietf.org]を見ると「移行期にはメッセージヘッダーは UTF-8 を MIME エンコードしてもいい」と書いてあるけれど。)
SMTP コマンドの方は MIME なんて使えないからどうせメールサーバーは拡張しないといけない、それならメッセージヘッダーも生 UTF-8 を許しちゃえってことかな。まあ、 SMTP が最初に作られた頃には Unicode なんてなかったから今みたいな形になったのであって、今ではもうあちこち Unicode が当たり前になっているんだからメールも全部 UTF-8 にしようぜというのは (その方が賢いかどうかは別として) 理解はできる。
受信側のメールサーバーは「このメッセージは SMTPUTF8 拡張を有効にした SMTP で送られてきた」と知っているから、メッセージヘッダーが UTF-8 で書かれていることを知っているわけだけど、そのことがメッセージ自体には書かれていないので、 POP とか IMAP とかでほかから読むときに情報が失われるとしたら問題だよね。どうなっているんだろう。
Re: (スコア:0)
むしろ、POP とか IMAP を使わせず Web ブラウザまたは Android MUA で読んでもらうためにこの仕様を積極的に進めているのじゃないかな。
IMAP を改定して公式に UTF8 対応してくれるならそれはそれで嬉しい。
Re: (スコア:0)
Webブラウザでメールってのはメールサーバがそういうふうに変換してhttpで読むんだからわかるとして、
AndroidのMUAってPOPもIMAPも使わないの？じゃあどうやってるの？
（実は内部でブラウザ呼び出してる？それならまあわからんでもない）
Re: (スコア:0)
国際化メールアドレスの否定は管理者の都合でしかないんですね。
Re:Gmailで日本語（非ラテン文字）アカウントが取れる。 (スコア:1)
＞国際化メールアドレスの否定は管理者の都合でしかないんですね。
そうです。
IDは認識されてこそなのですから、メールアドレスは発音は判らなくても、一字ずつ
読める必要は確実にあるのです。
多くの人が綴りを読む事も出来ないメールアドレスのアイデアは、アイデア倒れだと
思います。
Re: (スコア:0)
アルファベットが読めるのは普及率が高いのに合わせて教育してるおかげでしょ。今回のメアドのように、もっと国際化が進めばその前提は変わる。
Re: (スコア:0)
メールアドレスはUTF-8ビットストリームと一意に読めないといけない
はしご高のたかはしさんにメールが送れないのでは困るし、かっぱ巻きとマグロ寿司さんとマグロ二貫さんは違うかもしれないでは困る
Re: (スコア:0)
＞ 管理者の悪夢
cool.com に高値が付いた頃から延々とこの手の妙な錬金術で儲けようと企む連中がいますからねえ。
進んでそういう尻馬に乗ってしまうあたりに 現在のGoogleの技術的なセンスの多寡が見えるような気がします。
Re: (スコア:0)
仕事で使ってると、受け取れないほうが悪いという人の方をが多いんです。
winmail.datとか