targzの日記： [4月1日ネタ]「吉野家HDと高島屋が日本語UTF-8メール普及コンソーシアムを設立」 66
(ネタバレ防止改行)
|
|
|
|
|
|
|
|
|
|
|
|
部門名: 一方、村井純は「.junet」ドメインを計画した
株式会社吉野家ホールディングスと株式会社高島屋は、日本語メールでの UTF-8 使用を推進する団体として「日本語UTF-8メール普及コンソーシアム」の設立に合意した。
両社の正式名表記は「吉」や「高」ではなく、「つちよし」と呼ばれる吉や「はしごだか」と呼ばれる高の字を用いる。しかし、これらの文字は Unicode では表示が可能であるものの、現在の日本語メールで主流となっている ISO-2022-JP では表示させることができない。したがって、発行しているメールマガジンでは一般的な「吉」や「高」の文字を使わざるを得ない状況となっている。
現在のパソコンや携帯端末は UTF-8 を扱える OS を採用していることが多く、搭載している MUA も UTF-8 対応であることが多い。もはや、UTF-8 エンコーディングのメールを送信しても閲覧できる環境が整っていると言える。両社は、日本語 UTF-8 メールならば、吉野家の吉や高島屋の高を本来の字体で使うことができるため、可能ならば UTF-8 エンコーディングを使用したい意向だ。
しかし、これらの文字は Unicode のサロゲートペアの文字であり、UTF-8 では4バイトになってしまう。このため、これらの文字を使うためには、単なる Unicode 対応ではなく、サロゲートペアおよび4バイトUTF-8への対応が必要となる。そこで、「日本語UTF-8メール普及コンソーシアム」の設立によって、サロゲートペアの Unicode 文字および4バイトUTF-8を扱える環境を普及することとした。
- UTF-8 エンコーディングの日本語メールを「日本語UTF-8メール」と名付けて普及を図る。
- 両社が発行するメールマガジンにおける UTF-8 化する。
- MySQL や PHP, Perl など LAMP 環境における4バイト UTF-8 対応設定を啓発する。
- 日本語インターネットメールに UTF-8 を使用すべきと規定した RFC を策定する。(RFC1468 の obsolute 化)
なお、東京都葛飾区、奈良県葛城市と同県北葛城郡も本コンソーシアムへの加盟を検討している模様である。
四月莫迦ネタにマジレスカコワルイが、あえて言う (スコア:3, 興味深い)
UTF8を普及させようという目的ならば賛成する。だが、単に「」（つちよし）や「髙」が使いたいだけならお引き取り願う。
「」（つちよし）の上部「土」になっていたり「髙」が存在するのは手書きの話であって、活字と手書きは歴史そのものが違う。これは「木」の縦棒がはねている字形を異体字として認めないのと同じ理屈。意味上の差異がないにもかかわらず字形に拘泥する輩はまず書道を学べ。
# 海外でこれに似た例ってあるの？
# 例えば、印刷された自分の名前を見たGeorgeさんが、"George"のgは double-story [mac.com] のgだ。わしゃ昔からそう書いたきた
# と抗議した例とか。
※つちよしはプレビュー時に表示されなかったので括弧書きで補足した。
Re:四月莫迦ネタにマジレスカコワルイが、あえて言う (スコア:1)
# 海外でこれに似た例ってあるの？
CJKVの字形問題なんてまさに海外の例じゃないか。
Re:四月莫迦ネタにマジレスカコワルイが、あえて言う (スコア:1)
書道に詳しそうなあなたに早速学ぼうと思うのだけど、高と髙って同じ筆順で書けるの？
木の縦棒がはねているのとはだいぶ話が違う気がする。
Re: (スコア:0)
書道の上で同じ筆順で書ける文字は同じ文字だ、ということを言いたいんじゃなくて、
書道を学べば文字の由来や歴史が分かるから「高」と「髙」を区別する意味なんてないことが分かる
と言いたいんじゃないの？
そういう意味じゃ、筆順なんてあとからとってつけたものだし、それほど重要とは思えない。
ISO-2022-JPの「高」 (スコア:2, 参考になる)
ISO-2022-JPの「高」はくち高・はしご高の区別（異体字の区別）はありませんよね。
いろんな異体字を含む同一の文字としての「高」に対してコードが割り振られてるわけで。
現在主流のOSやフォントが「高」に対してくち高を割り当てているのは、たまたまそうなってるだけ。
そんなこと言い出したら「うちは変体仮名でないとだめ」とか「絵文字でないとだめ」とか
きりがない。（「かまわぬ」とか？）
Re:ISO-2022-JPの「高」 (スコア:1)
口高、はしご高を同一文字としてしまっている、言語学的に不備があり、実用上も不便のあるコード体系ですよね、ISO-2022-JP。
そんなこと言い出したら、日本語はすべて英語アルファベットを用いてローマ字書きでいいとか
きりがない。（「かまわぬ」とか？）
Re: (スコア:0)
いえいえ、くち高とはしご高は同一の文字です。
Re: (スコア:0)
同一じゃないでしょ．異体字の話をしてるんですよ？
Re:ISO-2022-JPの「高」 (スコア:1)
同じ文字に属する別の異体字です。
活字でよくある、丸の上に横棒が伸びてきている「a」と、
手書きでよくある、丸の上に横棒が伸びてきていない「a」は、
別の異体字ですが、同じ文字です。
Re: (スコア:0)
> 誰もアルファベットの話はしていません。馬鹿じゃねえの。
はい。馬鹿です。あなたが例を例として受け取る能力を欠いた人だということを見抜けなかった私が馬鹿です。
その例にこだわるつもりはないのでその部分はとりさげてもいいですが
（「言」の例とか「木」の例とかが別のコメントにあるのでそれを見て頂いてもいいですし、
例はよりわかりやすくるためのものですから、なくてもいいです）、
「同じ文字に属する別の異体字」という点については、いかがでしょうか。
Re: (スコア:0)
日本語で、何をもってひとつの文字とするのかを定義している物、場所、規格ってあるんでしょうか？
常用漢字？国語審議会みたいのが決めてる？
本気で知らないので、教えてください。
Re: (スコア:0)
規格はいろいろあるようですが1978年に制定されて1997年に「何をもってひとつの文字とするのかを定義」するための基準（包摂という）が明確化された
JIS X 0208という日本工業規格を紹介します。
JIS X 0208
http://ja.wikipedia.org/wiki/JIS_X_0208 [wikipedia.org]
JIS X 0208の1997年改定でどのような字体差を含み包むかが明示され、公開されています。
http://www.aozora.gr.jp/hosetsu_kijyun/0208-6.6.3 [aozora.gr.jp]
Re: (スコア:0)
たまたまじゃねぇよ。常用漢字表の字体に合わせてあるんだよ。
Re: (スコア:0)
> たまたまじゃねぇよ。常用漢字表の字体に合わせてあるんだよ。
合わせたのはフォント作者の自由意志によるものでしょう？
はしご高で作っても規格に違反しない。
Re: (スコア:0)
ガラパゴス規格ではそうだね。
国産の規格なのに常用漢字表の通用字体とそうじゃない字体も区別できないんだね。
Re: (スコア:0)
文字としては同一なのだから区別できなくて当然、というのが日本の立場。
たとえば、「言」の第1画は、手書きではふつう縦に書くけど活字だと
横に書きますね。第1画が縦か横かというのはけっこう大きな違いですが、
別々の文字と見なすべきでしょうか？日本の立場は、これを同一の文字の
書き方が違うだけ（異体字）だとみなすものです。だからそれを受けて
作られたJIS規格も、それを元に作られたコンピュータやOSも、第1画が
縦と横の「言」を区別することはできません。
ところでUnicode (ISO10646) は各国の規格の寄せ
Re: (スコア:0)
ひらがなの「そ」のゆれみたいなもんだと思えばいいのでは。
Re: (スコア:0)
でも、同一の文字であるはずの「斉」「斎」「齋」「齊」とかはISO-2022-JP（というかJISX0208とかJISX0213）に含まれてたり、
がちがちの原則一辺倒でもなく実用性重視なところもあるので、「くち高」「はしご高」「つち吉」「さむらい吉」についても
実用性重視で別々のコードポイントを割り振ってしまってもいいのにと思う。
でも、過去との互換性を考えると、やりにくいのだろうね。たとえばくち高とはしご高を区別できるJISX0213の改訂規格を作るとして、
従来の「高」のコードポイントの扱いはどうするのか（従来と同じく、くち高とはしご高の両方を包摂する文字という解釈なのか、
それともくち高だけを表すというふうに変更するのか。もし前者の場合、「包摂文字」「くち高」「はしご高」の3種類のコードポイントを
作るのか）、いろいろと面倒なことになりそう。
そういえばUnicodeでは「骨」の字がおかしくなるって言ってた人たちは、今どうしてるのだろう。
ネタにマジレス (スコア:2)
Unicode の UTF-16 のことを「Unicode」って呼ぶの嫌い。
葛城市 (スコア:1)
あの葛城市がこんなことに関心を持っているようなら、そもそも初めからあの字体を選ぶわけがないでしょう、と思ってしまいました。
Re:葛城市 (スコア:2)
江戸川区の葛西地域からも参加表明が…あるかなぁ?
Re: (スコア:0)
芦屋の芦田さん [unicode.org]もぜひ。
私も参加いたします (スコア:1)
立つ崎ですし、旧姓ははしご高なのでいろいろからんでおります。
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:私も参加いたします (スコア:1)
今の/.jはUTF-8ベースだから、はしご高は髙、立つ崎は﨑とそのまま書けばいいんじゃないかな。
でまあ、私の場合も、自分の姓がはしご高、母の旧姓が立つ崎ということで、それなりに興味がある話題なんですが、
以前ちょっとハマッたのが、お中元/お歳暮用のネットの通販サービス。
WebベースでサイトがUTF-8ベースだったのでおそるおそる使ってみたら、
注文管理の見かけ上問題なかったのに、届けられた送り状では化けてました…
#それでもやっぱり、メールはISO-2022-JP派。
Re: (スコア:0)
配達がネコで手打ちでゲタに変換 [togetter.com]してくれたのかもしれません
で、 (スコア:1)
Re: (スコア:0)
そこに颯爽と全国の「サイトウ」さんが加わって、もはやカオスと化します。
えーと、今日は…… (スコア:1)
Re:えーと、今日は…… (スコア:2)
まぁ、勝手にすればいいんじゃないかな～というのと utf-16 でメール出せば?
と書こうと思ったけど、今日の日付を見て気づいた(^^ゞ
Re: (スコア:0)
以下、レス禁止
Re:えーと、今日は…… (スコア:1)
こういうのなら真面目な話題にも持っていけるしうまいね。
Re: (スコア:0)
今年はネタと解っていてもなんか実際にあってもおかしくないような話題なんで､ちょっと混乱しました
Re: (スコア:0)
次のトピはちゃんとそれ用のアイコンになっているのに、
こっちもそうすればいい。
つちよしと一緒にしないでくれ (スコア:1)
まず、漢字字体規範データベースでの検索結果を見てもらいたい。
高の検索結果 [joao-roiz.jp]
吉の検索結果 [joao-roiz.jp]
はしごだかとつちよしは同じように康煕字典にのらなかったが、「くちだか」が1例だけしかなくてほぼ「はしごだか」なのに比べて、「つちよし」と「さむらいよし」は同じ程度に出現している。
この検索結果と今日という日を考えれば、はしごだかのほうがつちよしより正しい。はしごだかのほうが偉いことは確定的に明らか。
こんなことをいうと、つちよしのやつは「昔の草書ではくちだかが出る」とかいいやがる。先に言っておこう。ステマ乙。
Re:つちよしと一緒にしないでくれ (スコア:3, 興味深い)
「高」についていえば、
…という状況があった。現代では康煕字典の形が標準となり、手書き文字もそれにあわせたため、「くち高」が学校で教えられることになった。
「吉」についていえば、そもそも、横棒のどれが長いか短いかというのは、長短によって意味に違いが出る場合（「未」と「末」、「土」と「士」など）を除いて、どれを長く書いてもよかった。「吉」については、上半分が「土」だろうが「士」だろうが、意味は変わらない。だから、どう書いてもよかった。
ただし、最近の小中学校の無能な国語教師どもが、横棒の長短や縦棒の終わりの「はね」にグダグダ文句をつけて、教科書の活字の通りに書いてないと減点するようになったので、それにあわせてこだわる人が増えただけ。
Re: (スコア:0)
つまりこんなくだらないことにグダグダ文句を言った果てにUnicodeをゴミで埋め尽くそうとしてる連中は掛け算の順序を「間違えた」ら減点する連中と同類なわけだが自覚してるのかね。
Re: (スコア:0)
ごみ処理場にごみを搬入してるだけでしょ。
怒るのはピュアなUnicode信者くらい。
gmailが日本語ローカライズした日 (スコア:1)
Re: (スコア:0)
メールは相手のあることなので、メジャーなものから対応を求められます。
ISO-2022-JP のサポートがだめだったら、Gmail サービスでは日本語が使えないからと言われておしまいです。
ケータイキャリアや、他のメールクライアントは様子見で相手にしなかったような気がします。
確か… (スコア:0)
UTF-8さんは確か亡くなられていた [bogusne.ws]ような
Content-Transfer-Encoding (スコア:0)
いまどきのメールサーバほぼ 8bit データを通すので 大抵は UTF-8 でもかまわないのですが、すべてが通すわけではないというところに問題があります。
海外のサーバに多い印象ですが、経路のどこかに 8BITMIME を返してくれない SMTP サーバがいると、そこで quoted-printable や base64 でエンコードされて配送されるわけです。
そうすると ３バイトどころか４バイト６バイトとデータ量が膨れ上がるのでいろいろ残念な思いです。
あと、古いケータイには ISO-2022-JP か Shift_JIS エンコードのメールしか受け付けないようなものがあるらしいと聞いたのですが、具体的にどの世代が該当するのかわかりませんでした。
そんなわけでサーバ内部では UTF-8 であるにもかかわらず、メールを送るときだけは ISO-2022-JP もどきに変換して送ってる私をお許しください。
# ①や～を送ってるところが「もどき」。
Re:Content-Transfer-Encoding (スコア:2)
あと、古いケータイには ISO-2022-JP か Shift_JIS エンコードのメールしか受け付けないようなものがあるらしいと聞いたのですが、具体的にどの世代が該当するのかわかりませんでした。
古い「ケータイ」ではなく「PHS」ですが，WX310KのメーラーでUTFなメールを受信すると化け化けになりますね。
（何に対応していて，何に対応していないのかはよく分かりませんが・・・）
Re:Content-Transfer-Encoding (スコア:1)
IMAPとかで変換機能があるといいんだけど、どうだろ?
# サービスとデータ構造もそれなりに切り離しがないとあとあと大変だなと思う今日このごろ
M-FalconSky (暑いか寒い)
RFC1468 の obsolute 化 (スコア:0)
そういや真面目な話として、なんかバグがあるんじゃなかったでしたっけ？ BNF で空行の定義が抜けてるとか何とか、すごくトリビアルなものだったと思いますが。歴史的に過去のものにするにしても修正だけできないものかと。
Re: (スコア:0)
obsol"u"teって時点で既にバグが・・・
異体字セレクタのことだな (スコア:0)
Windows7でも標準フォントのメイリオが対応していないのが痛いな
Re: (スコア:0)
Windows 8では対応してるよ(JIS2004で字形変更された文字だけ)
異字体と似たような字との区別で思うのだが (スコア:0)
英語のP（ぴー）とギリシャ文字のP（ろー）にも同一コードを割り当てないと不公平だ。
＃明日が誕生日。毎年、全世界で前夜祭だよ。
Re: (スコア:0)
じゃあついでにひらがなの「り」とカタカナの「リ」とか、
カタカナの「カ」と漢字の「力」とかも同一コードにしちゃいましょう。
Re:異字体と似たような字との区別で思うのだが (スコア:1)
工業の「工」とエッチの「エ」も同一コードでいいよ。