decodeURIComponentのもろもろについて - 枕を欹てて聴く
追記1 SpiderMonkeyのサロゲートエリアのbug issue は修正されました! (該当commit) 記事の一番下を御覧ください. 追記2 V8のサロゲートエリアのbug issue は修正されました!(該当commit) これで以下の記事のサロゲートエリアのbugはV8, SpiderMonkey, JSCで修正されました 普段1.5ヶ月に1記事しか書かないのに, 今日は3つも書いて正気の沙汰じゃないで... id:piro_or さんよりcommentで, id:nanto_vi さんの以下の記事の話を受けましたのでー. (commentついたの1年ぶりで感涙) 文字列と UTF-8 バイト列の相互変換: Days on the Moon リンク先の記事では, 以下の方法によるUTF-16 <=> UTF-8の変換が記載されています. function toUTF8Octe
文字列と UTF-8 バイト列の相互変換: Days on the Moon
やっていることは「高度な JavaScript 技集」の「UTF-8 <-> UTF16 変換」と同じ。 function toUTF8Octets(string) { return unescape(encodeURIComponent(string)); } function fromUTF8Octets(octets) { return decodeURIComponent(escape(octets)); } encodeURIComponent は encodeURI でもいい (むしろそのほうが処理する文字種が減って速くなりそう) が、decodeURIComponent は decodeURI にすると一部の文字 ("?"、"#" など) がデコードされなくなる。 使いどころ Base64 エンコードする関数 (「高度な JavaScript 技集」の base64encod
vs UTF-8, UTF-16, UCS4 - 枕を欹てて聴く
前置き おはミルキィ! ChromeFullFeedが公開停止になった話を前置きとして書いていたのですが, あまり関係がないのと, 長くなりそうになってきたので, 別の記事に分けました. http://d.hatena.ne.jp/Constellation/20110530/1306701693 概要 という前置きで. ECMAScriptと切っても切れない文字コード, UTF-16. iv / lv5はUnicode変換のためにICUに依存していたのですが, UTF-8 <=> UTF-16なら何とか自分でも書けるのではないかと思い, Unicode Converterを書きました. これでlv5の依存はlibboost, libgc (Boehm GC)に減りましたー. Unicodeの変換の教授, bugつぶしにおいて, id:masa141421356 さんに非常にお世話になりま
絵文字が開いてしまった「パンドラの箱」第5回--絵文字と日本マンガの親密な関係
絵文字の収録をめぐって、国際規格で大論争--「Google提案」を振り返る 皆さんこんにちは、面白くてタメになる（？）文字コード漫談の時間がやってまいりました。2月からとびとびで書いてきた絵文字の報告も、いよいよ今回が最終回。どうかよろしくお付き合いください。 さて、前回はどこまでお話ししたのでしたっけ。日本の絵文字をUnicodeに収録しようとするGoogleとAppleによる提案（以下、主導者の名をとりGoogle提案と略）ですが、去年の12月にパブリックレビューが開始されると、Unicode-MLで時ならぬ非難の嵐が吹き荒れたこと。そこでの反発を一言で言い表すなら、日本の文化に強く依存する絵文字を単純に国際規格に収録しようとした点にあったこと。 なぜなら国際規格の審議は参加各国の総意で成り立っており、特定の国しか便利に使えない文字を収録することは、当然強い反対をうけるからです。さらに
絵文字が開いてしまった「パンドラの箱」第4回--絵文字が引き起こしたUnicode-MLの“祭り”
普通では考えられない優遇策--「Google提案」を振り返る 皆さんこんにちは、毎度おなじみ（？）文字コード漫談の時間がやってまいりました。前回が3月の掲載ですから3カ月ぶりですか。今まで3回にわたって絵文字をUnicode及びISO/IEC 10646（国際符号化文字集合）に収録しようという提案の動きについてご説明してきましたが、今回から2回に分けて完結編をお届けします。どうぞよろしくお付き合いください。 ひさしぶりですから、ここまでのポイントを整理しておきましょう。前述した「提案」とは、もともとはUnicodeに収録するためにGoogleがAppleと共同で作成したものです。以下、主唱者の名前をとり「Google提案」と呼ぶことにします。これはこの2月に開かれた最高議決機関、UTC会議で承認されてUnicodeコンソーシアムの総意となりました。ついでGoogle提案はISO/IEC 1
絵文字が開いてしまった「パンドラの箱」第3回--Unicode提案の限界とメリット
前回までを振り返る--Unicodeコンソーシアムの影響力 前回はどこまでお話ししましたっけ。世界中の文字の収録を目的とした文字コード規格、Unicodeは、米国のIT企業を中心に結成されたUnicodeコンソーシアムが制定するデファクト規格に過ぎないこと。しかし公的な国際機関が定めるデジュール規格ISO/IEC 10646と同期することで、WTO/TBT協定にもとづき世界中の国々に普及させられるメリットを得たこと。 また、Unicodeコンソーシアム自体はオープンな組織だけれど、意志決定を行うUTC（Unicode Technical Committee/Unicode技術委員会）で一票を投じる権利を持つのは一握りの団体に限られること。そしてUTCはISO/IEC 10646のアメリカ・ナショナルボディであるL2委員会と合同でしか開催されておらず、同時にL2委員会とUnicodeコンソー
絵文字が開いてしまった「パンドラの箱」第2回--Googleの開けてしまった箱の中味
じつはコメントを送っていたNTTドコモ 最初に前回のおさらいをしておきましょう。スタート当初の携帯電話の絵文字には、キャリア間でメールのやり取りの中で文字化けしてしまう欠点があったこと、それを解決する仕組みをキャリア各社が作ったものの、その場しのぎの欠点の多いものであったこと、そして絵文字のUnicode符号化というのはそうした欠点を一挙に解決するはずであること。ついでにGoogleが絵文字のUnicode符号化を進めることで、キャリア各社は今まで自分たちが育ててきた絵文字の主導権を奪われてしまうということも。 それから前回の最後では、キャリア各社に対してGoogleの提案についてどう思うか、パブリックレビューに参加する意向があるかを聞いてみました。そこでの回答は、各社そろって消極的と受け取れるものでした。 ところが前回の掲載後に、NTTドコモがGoogleの絵文字メーリングリストに投稿し
絵文字が開いてしまった「パンドラの箱」第1回--日本の携帯電話キャリアが選んだ道
Unicodeが携帯電話の絵文字を収録へ 絵文字ってなに？そう聞かれても多くの人は、ああ、それはと答えられるはず。そう言えばちょっと前に『メールのハートマークにだまされるな！ 8割の女性は「恋人以外にも使う」』（RBB NAVI）なんていうニュースもありました。携帯電話の個人普及率が9割を上回る（平成20年内閣府消費動向調査）この国において、絵文字はごくありふれたものになっている現実があります。 2008年の11月27日、Googleが携帯電話で使われる絵文字を国際的な文字コード規格、Unicodeに収録しようというプロジェクト進行中であることを発表しました。では、このニュースは何を意味するのでしょう。そして私たちに何をもたらすのでしょう。今回から3回に分けて考えてみようと思います。 まず歴史を振り返ってみましょう。じつは絵文字を使ったのは携帯電話が最初というわけでありません。先行するもの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
tanimoto.to - a really cool domain parked on Park.io