はじめに 2008年11月27日、Googleは日本の携帯電話の絵文字をUnicodeに収録する計画を公表した。これまで7回にわたってお伝えしてきた連載「絵文字が開いてしまったパンドラの箱」は、この公表から後の動きを追ったものだ。 では、それ以前の同社は何をしていたのか? つまり、Googleはどんなプロセスを経て絵文字をUnicodeに提案すると決めたのだろう。今回ご報告するのはこのことだ。 インタビューに答えてくれたのは桃井勝彦氏。氏は大学時代にスカラシップ(奨学金)で渡って以来米国に暮しつづけている。言語学・日本語学を専攻する大学院生、大学教員などの経歴も持ち、1996年に学術界からNetscape国際化部門に入社。2004年にMozilla Japanの設立にかかわった後、2005年にGoogleに移った経験豊かな国際化エンジニアだ。マウンテンビューにある米本社にあって、今回の符号
2009年06月15日07:00 カテゴリLightweight Languages perl - use utf8; #って何だ? id:otsuneに建設予定フラグがたてられていたので。 冬通りに消え行く制服ガールは、夢物語にリアルを求めない。 - subtech Perl の utf8 関係が未だ全く理解できない。わからないことがわからないので整理 use utf8はいつフラグをたてるか use utf8 しててもフラグたたないことがある…… これは、以下の実例を見ていただくのが一番よいだろう。 #!/usr/bin/perl use strict; use warnings; use utf8 (); sub check_flag{ my $str = shift; print qq("$str" ), utf8::is_utf8($str) ? 'is' : 'IS NOT',
普通では考えられない優遇策--「Google提案」を振り返る 皆さんこんにちは、毎度おなじみ(?)文字コード漫談の時間がやってまいりました。前回が3月の掲載ですから3カ月ぶりですか。今まで3回にわたって絵文字をUnicode及びISO/IEC 10646(国際符号化文字集合)に収録しようという提案の動きについてご説明してきましたが、今回から2回に分けて完結編をお届けします。どうぞよろしくお付き合いください。 ひさしぶりですから、ここまでのポイントを整理しておきましょう。前述した「提案」とは、もともとはUnicodeに収録するためにGoogleがAppleと共同で作成したものです。以下、主唱者の名前をとり「Google提案」と呼ぶことにします。これはこの2月に開かれた最高議決機関、UTC会議で承認されてUnicodeコンソーシアムの総意となりました。ついでGoogle提案はISO/IEC 1
今回は、文字コードに関連するセキュリティの話題では古参ともいえるUTF-8の冗長なエンコードというテーマについて紹介します。 UTF-8とは UTF-8は、各文字を1~4バイトの可変長で表現するUnicodeの符号化方式のひとつです。 U+0000からU+007Fの範囲の文字を0x00から0x7Fの1バイトで表現しているため、US-ASCIIと互換性がある、バイト列の途中からでも文字の先頭バイトを簡単に検出できる、多バイト文字の途中に0x00や0x5C(\)、0x2F(/)などが現れない、などの特徴があります。 UTF-8での文字のビットパターンは表1のようになります。 表1 UTF-8でのビットパターン
_U+00A5を用いたXSSの可能性 前回の日記では、昨年のBlack Hat Japanにおける長谷川陽介氏の講演に「趣味と実益の文字コード攻撃(講演資料)」に刺激される形で、Unicodeの円記号U+00A5によるSQLインジェクションの可能性について指摘した。 はせがわ氏の元資料ではパストラバーサルの可能性を指摘しておられるので、残る脆弱性パターンとしてクロスサイト・スクリプティング(XSS)の可能性があるかどうかがずっと気になっていた。独自の調査により、XSS攻撃の起点となる「<」や「"」、「'」などについて「多対一の変換」がされる文字を探してきたが、現実的なWebアプリケーションで出現しそうな組み合わせは見つけられていない。 一方、U+00A5が処理系によっては0x5C「\」に変換されることに起因してXSSが発生する可能性はある。JavaScriptがからむ場合がそれだ。しかし、
じつはコメントを送っていたNTTドコモ 最初に前回のおさらいをしておきましょう。スタート当初の携帯電話の絵文字には、キャリア間でメールのやり取りの中で文字化けしてしまう欠点があったこと、それを解決する仕組みをキャリア各社が作ったものの、その場しのぎの欠点の多いものであったこと、そして絵文字のUnicode符号化というのはそうした欠点を一挙に解決するはずであること。ついでにGoogleが絵文字のUnicode符号化を進めることで、キャリア各社は今まで自分たちが育ててきた絵文字の主導権を奪われてしまうということも。 それから前回の最後では、キャリア各社に対してGoogleの提案についてどう思うか、パブリックレビューに参加する意向があるかを聞いてみました。そこでの回答は、各社そろって消極的と受け取れるものでした。 ところが前回の掲載後に、NTTドコモがGoogleの絵文字メーリングリストに投稿し
Unicodeが携帯電話の絵文字を収録へ 絵文字ってなに?そう聞かれても多くの人は、ああ、それはと答えられるはず。そう言えばちょっと前に『メールのハートマークにだまされるな! 8割の女性は「恋人以外にも使う」』(RBB NAVI)なんていうニュースもありました。携帯電話の個人普及率が9割を上回る(平成20年内閣府消費動向調査)この国において、絵文字はごくありふれたものになっている現実があります。 2008年の11月27日、Googleが携帯電話で使われる絵文字を国際的な文字コード規格、Unicodeに収録しようというプロジェクト進行中であることを発表しました。では、このニュースは何を意味するのでしょう。そして私たちに何をもたらすのでしょう。今回から3回に分けて考えてみようと思います。 まず歴史を振り返ってみましょう。じつは絵文字を使ったのは携帯電話が最初というわけでありません。先行するもの
■ PHP スクリプトは BOM 付き UTF-8 で書いてはいけない ここのところ、ずっと悩んでいたバグがあったのですが、 ようやく原因が分かったので、その顛末を。 header() を使ってレスポンスヘッダを出力するコードを書いていたのですが、 Live HTTP headers なんかを使って見てみても、 なぜか指定したレスポンスヘッダが出力されていません。 よくある話として、header() の前になにかゴミを出力してしまっているのでは? と疑ったのですが、 チェックしてみてもその気配は無し。 原因が分からず、しばらく放置していたのですが、 ふとひらめいて、バイナリエディタを使ってスクリプトのファイルを見てみました。 あれ? なに、この先頭の EF BB BF って? いつのまにか BOM が付いているけど、もしかしてこれがまずいのか? (…考え中…) そうか! BOM 付き U
といった感じ。ちなみにjava.util.regexとPerlのUnicodeブロックは接頭子Inを使うが、.NETの場合は接頭子Isを使う、という差異があります。 Unicodeスクリプトとブロックの違いがビミョーに見えるけど、ブロックがコードブロックをゴリッと指定したものに対して、スクリプトは特定言語に関係する文字の種類を直接指定するものなのでブロックよりも断定的、って感じで見れば良かなと。ちなみにUnicode関連のドキュメントによるとUnicodeプロパティとスクリプトで日本語の文章を表そうとすると m/(?:(?:\p{Hiragana}|\p{Katakana}|\p{Han}|\p{Latin}|\p{Common}) (?:\p{Inherited}|\p{Me}|\p{Mn})?)+/x; こんな感じになるそうな。実際流通している文章はこれより多様なので現実とは微妙に乖離
絵文字とは、顔の表情やその他のシンボルなどを絵で表現した文字で、日本の携帯電話ユーザーの間で特に人気があり、広く使用されているものです。先月、Gmail でも絵文字が使用可能になりました。詳しくはGmail チームのブログポスト「Gmail で絵文字が使えるようになりました 」をご覧ください。 これらの絵文字は携帯電話会社が各々独自に創作したもので、メールやウェブなどで使われています。絵文字は元々各携帯会社のユーザー同士で使用されることを前提に作られたものですが、現在では各社間である程度の互換性を保つための絵文字変換表も利用されています。 ユーザーは携帯会社や機種の違いに関わらず、見慣れている絵文字が表示されることを期待しています。自分がメールで送った絵文字が、受信側でも同じか同等の絵文字で表示されること、ウェブで見る絵文字が他の携帯ユーザーにも同じに見えること、また検索エンジンで絵文字を
Googleによる絵文字標準化検討の話自体は大歓迎。 私も苦労してきたので。 けど、 News - 絵文字標準化 by Google -404 Blog Not Found- 「絵文字をどうするか」なんて、Unicode Consortium ではずっと前から議論してた。 ケータイ各社からのプロポーザルを待っていてさえいた。 で、やるのは結局 Google だ、と。 ドコモよ、AUよ、ソフトバンクよ。 貴様ら一体どこで油売ってたんだよ。あ、油じゃなくてケータイか。 ついこないだまで、「ガラパゴス特有の絵文字機能等、iPhoneに必要ない」という論調がまかり通っていたかと思えば(弾さんが言ってた、じゃないですよ)、状況が変わった途端こういう話が注目が集める。 なんだかなあ、と思う。 メタブクマでも誰かが書いてたけど、どれだけ自虐的なんだ。 別に見方を変えれば、日本独自の絵文字文化
2008年11月30日02:00 カテゴリNewsiTech News - 絵文字標準化 by Google 悲しい知らせだ。 Google Japan Blog: 絵文字のユニコード符号化: 符号化提案用のオープンソースデータ 現在、日本の携帯絵文字の全てをユニコードの文字として共通符号化しようという提案が進行しています。そのためには、現在使用されている絵文字のうちどれが既にユニコード符号化されているか、新しく符号化しなければならない絵文字はどれかなどを調査する作業が必要です。この提案を支援する目的で、私たちが提案している絵文字のマッピングや変換表、更に絵文字データからHTMLの表などを作成するのに役立つツールなどを 「emoji4unicode 」という名前でオープンソースプロジェクトとして公開します。 日本の絵文字が“世界進出”へ グーグルが標準化提案 (1/2ページ) - MSN産
はじめに 与えられた文字列を含む文書を返す検索機能を実装しているところを想像してください。 検索語として「ページ」が与えられれば、「ページ」という文字列を含む文書を返します。これは特に難しいことではありません。 半角の「ページ」が与えられたらどうでしょう。「ページ」と「ページ」を区別する必要がないような、一般的な文書検索においては、「ページ」という文字列を含む文書を返すのが望ましいはずです(もちろん、この2つは常に同一視できるわけではありません。同一視できない例として本稿があります)。 もしかしたら、「㌻」で検索しようとする人がいるかもしれませんし、日本語を母国語としない人が、「ぺ」(「ヘ」と半角の半濁点「゚」)や「ヘ゜」(半角カナ「ヘ」と半濁点「゜」)を使うかもしれません。 人間なら簡単に対応できることですが、コンピュータで対応するには特別な処理が必要になります。例えばUnic
2008年05月02日04:00 カテゴリLightweight Languages Unicode - 似た文字同士にご用心 後者はハイフンでなくてマイナス記号でんがな。 [を] UTF-8 の全角ハイフンが Perl の正規表現にマッチしなくて悩んだ で、元のテキストファイルの全角ハイフンを「od -t x1」 で見てみると「ef bc 8d」と「e2 88 92」の2種類が混じっていました。 前者は「\p{Hyphen}」にマッチするのですが後者はダメ。 まあ原因は分かったので、前処理でバイナリ置換して解決しました。 で、紛らわしそうなのを名前のHYPHENとMINUS SIGNでgrepするとこんな感じになる。 egrep '(HYPHEN|MINUS SIGN)' /usr/local/lib/perl5/5.10.0/unicore/Name.pl -002DHYPHEN-MI
2008年04月09日01:00 カテゴリLightweight Languages perl - Encode 入門 すでにOSCONでもYAPCでも、あちこちそちこちでこの基本方針に関しては話したのですが、ここ 404 Blog Not Found でも改めて。 Perl で utf8 化けしたときにどうしたらいいか - TokuLog 改め だまってコードを書けよハゲ 入り口で decode して、内部ではすべて flagged utf8 で扱い、出口で encode する。これがすべてです!とにかくこの基本方針をまもっていれば幸せになれます。ここでは、EUC-JPでエンコードされたファイル中の「小飼弾」「こがいだん」「コガイダン」「Kogai Dan」を正規表現で書き換えて標準出力にEUC-JPで出力するプログラムを例にとって説明します。 decode() then encode(
UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。
2006年11月24日12:30 カテゴリLightweight Languages Unicodeは文字集合か符号化方式か 以下は、電脳で文字を扱う場合の基礎中の基礎なのだが、肝心の記事に重大な誤りがいくつもある。 文字コード規格の基礎:ITpro そろそろ具体的な説明に入ろう。最初にはっきりさせておく必要があるのは次の点だ。一般に「文字コード」と言う場合, 文字の集合 エンコード方法 という要素がある。この二つを区別して考えることが重要だ。もちろん大きな関連はあるのだが,ごちゃごちゃのままでは「わからなく」なる大きな要因となる。ここだ。 これによると、Unicodeは明らかに「エンコード方法」であるが、これは間違い。ここで書かれているものはUCS-2という名前のUnicodeが定めるいくつかの「エンコード方法」の一つであり、しかもUTF-16によって陳腐化した方式である。 まずUnic
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く