CJK統合漢字拡張Fがヤバイ - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
日本がCJK統合漢字拡張F1/F2に提案している文字には、すでにUCSに入っている漢字と見分けがつかない例がいくつもある。これらは、提案書*1に「Similar and Variation」として既存の文字の符号位置が記載されているものの一部であり、つまり、似ている漢字の存在は百も承知で提案しているわけだ。 以下、そのような例を拾ってみた。左右に並べた文字のうち「UCS」欄に符号位置が入っているほうが、既存のもの。個々の文字について述べることはしないが、要するに「別字の衝突であれば、形が同じでも別の符号を与える」ということだろう。 だが、ちょっと待ってほしい。それって実はものすごく根本的な方針転換じゃないですか？ 「機」の簡体字の「机」も「つくえ」の「机」も、形が同じである以上、同じ符号位置（U+673A）に包摂・統合するというのがCJK統合漢字の大原則であったはず*2。ここでいきなりそれ
perl - 最速のUTF-8処理法 : 404 Blog Not Found
2013年03月04日14:45 カテゴリTipsLightweight Languages perl - 最速のUTF-8処理法 Perl Cookbook (English, Kindle Ed.) Christiansen / Torkington [邦訳: Perlクックブック] というわけで解説。 2013/03/04:Unicode::UTF8 がガチ爆速すぎる - bayashi.net encode より decode のが差が大きい感じ。encode だけだと、文字列長くなると Encode の方が速いっぽい。 まずは改めて検証してみましょう。 https://gist.github.com/dankogai/5079930 確かにその通りになっています。Unicode::UTF8はEncodeはおろかPerl組み込みのutf8::decodeより高速なのか(文字列をコピ
絵文字のユニコード符号化: 符号化提案用のオープンソースデータ
メディア関係者向けお問い合わせ先 メールでのお問い合わせ: pr-jp@google.com メディア関係者以外からのお問い合わせにはお答えいたしかねます。 その他すべてのお問い合わせにつきましては、ヘルプセンターをご覧ください。
グーグル、絵文字を世界共通化へ--オープンソースプロジェクト開始
グーグルは日本の携帯電話の絵文字を、世界に広める存在になりたいようだ。 11月27日にGoogle Japan Blogに投稿されたエントリによると、グーグルは日本の携帯電話の絵文字の全てを、ユニコードの文字として共通符号化する考えだという。 絵文字はもともと日本の携帯電話会社が固有のものを使っており、異なる通信会社同士で絵文字を送り合うことはできなかった。現在では各キャリアが協力して、お互い似たような絵文字がある場合には、変換して表示している。 グーグルはこれを拡大し、絵文字をユニコードとして標準化することで、どの通信事業者間で送った絵文字も同じように表示される世界を実現したいという。さらに、「検索エンジンで絵文字を探せば、結果が返ってくる」（グーグル ユニコードソフトウェアエンジニアのMarkus Scherer氏)ようにもしたいとのことだ。 このグーグルの野望を実現するためには、現在
perl, python & ruby - chr() vs. Unicode : 404 Blog Not Found
2006年11月23日22:00 カテゴリLightweight Languages perl, python & ruby - chr() vs. Unicode というわけで、404 Blog Not Found:There's more than one language to cook your problemsでPython & Ruby Cookbooksを一気読みしたので、気になる点を少しずつ書いて行くことにする。 まずは、文字の扱い。文字列でない点に注意。 少なくとも、文字列をバイト列と見なして相互変換することは、LLに限らずたいていの言語で出来るようになったのだけど、文字を文字として扱うという点に関しては各言語ともまちまちで、多言語派の私としては結構頭のいたいところ。 ここでは、私が一番流暢なPerlを軸に、RubyとPythonではどうなっているのかを調べてみた。 数値
シフトJISを捨てられるか? - 記者のつぶやき：ITpro
これまで，Windows Vistaの文字の扱いに関する事柄を何度か取り上げてきた。同じキャラクタ・コードで，Windows XPのときと文字の形が変わったり，Unicodeでしか扱えない文字があったりするという話題だ。今回は，エンコーディングについて考えてみたい。 これまでの記事でも書いてきたが，文字処理とエンコーディングに関する問題は，何もWindows Vistaに始まったわけではない。Windows XPやWindows 2000など，既存のWindowsでも同様だ。例えば，「鴎」の旧字である「シナカモメ」は，Unicodeでしか扱えない文字だが，Windows XP以前のMS-IMEでも入力できる。石鹸の「鹸」の旧字もそうである。これらの文字を扱うには，アプリケーション・ソフトが，文字列をUnicodeで処理しなればならない。シフトJISに変換した瞬間に，文字情報が無くなってしま
Unicodeは文字集合か符号化方式か : 404 Blog Not Found
2006年11月24日12:30 カテゴリLightweight Languages Unicodeは文字集合か符号化方式か 以下は、電脳で文字を扱う場合の基礎中の基礎なのだが、肝心の記事に重大な誤りがいくつもある。 文字コード規格の基礎：ITpro そろそろ具体的な説明に入ろう。最初にはっきりさせておく必要があるのは次の点だ。一般に「文字コード」と言う場合， 文字の集合 エンコード方法 という要素がある。この二つを区別して考えることが重要だ。もちろん大きな関連はあるのだが，ごちゃごちゃのままでは「わからなく」なる大きな要因となる。ここだ。 これによると、Unicodeは明らかに「エンコード方法」であるが、これは間違い。ここで書かれているものはUCS-2という名前のUnicodeが定めるいくつかの「エンコード方法」の一つであり、しかもUTF-16によって陳腐化した方式である。 まずUnic
文字コード規格の基礎：ITpro
この記事は，日経ソフトウエア 1999年10月号に掲載したものです。それ以降の情報が盛り込まれていませんので，現在とは異なる場合があります。 文字コード規格の基礎を手早く理解したい場合などにお役立てください。 文字コードは間違いなく情報を交換するための「決まりごと」なので，正確を期すため厳密な仕様が規定されている。だが，その仕様そのものを実装するプログラムを作る場合を除けば，プログラマが仕様の詳細を隅々まで理解している必要はない。六法全書を読んでいなくても問題なく普段の生活ができるようなものだ。 ここでは，通常のプログラミングをするうえで必要と思われる範囲のことを，なるべく簡潔に説明したい。「半角カナ」のような呼び名は正確さを欠くものだが，多くの人に伝わりやすいので説明の中でも使っていく。説明を簡略化するため「正確な仕様を知りたいときは規格書そのものを必ず参照してほしい」と書きたいところだ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
