Unicode の雪だるま Unicode Snowman for You というサイトを知りました。Unicode の雪だるま (U+2603 SNOWMAN ☃) が表示されるだけのサイトです。が、ソースを見ると font-face で EOT 形式のウェブフォントが使われていることに気づきました。 この EOT (Embedded Open Type) 形式のウェブフォントは IE しか対応していないようです。IE で表示するとこのような雪だるまが表示されました。これはおそらく Arial Unicode MS の雪だるまです。ちょっとこわいような。。 一方、他のブラウザで表示すると、このような雪だるまが表示されました。これは私がデフォルトのフォントに設定しているメイリオの雪だるまです。これはかわいい。意外なところにも力が入っています。

この日の私の心無い投稿により、関係者の皆様にたいへん不愉快な思いをさせました事、深くお詫びします。 今日のネタは工学の話でも文学の話もない。 今日のネタを私がどのカテゴリに分類したのかを意識して読んで欲しい。 私は、JIS2004日本語文字セットの規格（JIS X 0213:2004）は廃棄すべきであり、JIS2004で追加・変更された文字は、既存の文字コードに割り当てられた文字の字形を変えるべきではなく、Unicodeに追加するだけでお茶を濁すべきだと進言します。 サロゲートペアの問題を取り沙汰す人もいるが、これだけＩＴの処理能力・情報量・伝達速度が伸びている中で、文字長が長くなる事に何を抵抗してるんだか。 ややこしいと思ったら全ての文字をサロゲートペアにしろよ、バカ（笑） 人の名前は人格を表します。 なので、その真名を勝手に変更するような規格の改悪は人格を否定する

UTF-8 には文字の幅が文脈依存 (ambiguous) となる文字があって、 矢印や記号 (■▲)、罫線などの文字は状況に応じて文字幅が変化します。 下の 2 つの画像は Emacs で同じファイルの内容を narrow character として判定させた場合と、 wide character として判定させた場合のスクリーンショットです。 narrow wide 現状、 Emacs22 はこれらの文字をデフォルトで narrow character として判定します (※のように化けてしまう文字もあります)。 文字によって幅を変えるプロポーショナルフォントを前提としたテキストであれば あまり問題にはならないと思いますが、等幅フォントに向けて書いたテキストでは 表示がガタガタになってしまい問題になります。 これらの文字を wide character として判別させるには以下の設定を

Unicode Character Search Query: include Han codepoints? Cancel A-Z index | Search options

Unicode の文字列をソースコードに埋め込む方法 Unicode の文字列をソースコードに埋め込む場合、直接 UTF-8 などで文字列を書く方法と、\uXXXX などのようにエスケープして表記する方法があります。後者の方法についてまとめてみました。 \uXXXX 形式の場合 Java, JavaScript, Python, C++, C (C99から) などの多くの言語では \uXXXX という表記 (universal character names) でUnicode の文字を文字列の中に埋め込めます。たとえば、「あいう」は "\u3042\u3044\u3046" となります。 \uXXXX で埋め込んだ文字がどのように解釈されるかは言語や処理系によって異なります。 gcc/g++ の場合、 -fexec-charset オプションで、実際に使う文字セット・エンコーディングを指

Firefoxは内部的に変換処理を行うようになっているようです。 問題はSafariとOperaですね。 選択されたファイルのパスからJavaScriptで ファイル名を抜き出してタイトルに設定する部分で、 正しく扱えるような文字コードに変換することにしたいと思います。 基本的な流れとしては、UTF-8-MAC特有の「U+3099」（COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK）、 「U+309A」（COMBINING KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK）がファイル名に含まれている場合は、 その前の文字と結合して濁音・半濁音の文字にしてあげればいいでしょう （ひらがな・カタカナのみの暫定的な対処に過ぎませんが）。 変換用の文字テーブルを用意して、逐一変換していくかたちにしたいと思います。 というわけ

Posted by nene2001 at 14:02 / Tag(Edit): ainu language google technology / 0 Comments: Post / View / 0 TrackBack / Google Maps Googleさんの技術でアイヌ語訳ができないだろうか みたいな記事書きましたが、その後追ってみるとどう考えたって無理ですねこれ。 金成マツノート -Gymnopedies- ザッと調べたところで解ったことは、アイヌ語の翻訳作業自体が困難であるということかな。 上記リンクのブログにあるように、アイヌ語は文字として残っていないので、同一語でも地域差があった場合にそれを同定することのが非常に難しいのだそうだ。 となると、やはり現地採集による広域使用言語の推移を体系化することと特定地域の平準化作業をせねばならなくなる。 わけだが

基本的に、まともな国際化ライブラリを使っていれば、上記のような不正な文字コードはきちんと処理してくれるはずです。実際、 Opera, Firefox, IE ともに適切にエスケープしてくれました。また、 UCS に変換した後にエスケープ処理を行うことでも対処できるかもしれません。しかし、複数のモジュールで構成されるような規模の大きいアプリケーションでは、そのすべてが適切な処理を行っていると保証するのも、なかなか難しいかと思います。ここはやはり、すべての外部入力に含まれる不正なシーケンスを、水際で正規化するという処理を徹底するのが一番かと思います。 例えば Ruby の場合、不正な UTF-8 コードを検出する最も簡単な方法は、 String#unpack を使って UCS へ変換してみることです（昨日の記事への kazutanaka さんからのはてぶコメントにて、 iconv でも同様なこ

http://www.nutsecurity.com/?date=20061209ここに載ってましたが・・・・凄すぎる、というか感動すら覚えましたよ、よくこんな事考え付くなぁ。 こうして・・・で名前の変更でUnicode制御文字の挿入でRLOを選択して「cod.emdaeR.EXE」とか入力するとですね・・・んでこうすると・・・ 　　　　/＼＿＿_／ヽ　 　ヽ 　　 ／　　　　::::::::::::::::＼　つ 　 . | 　,,-‐‐　 　‐‐-､ .:::|　わ 　　|　 ､_(o)_,:　 _(o)_,　:::|ぁぁ . 　 |　　　　:: 追記：　もっと偽装してみましたブクマコメントに書いてあったのでやってみました、右→左書きの後に左→右書きと続けると拡張子を中央に持ってくる事が可能です・・・アイコン表示だと一目瞭然ですが一覧表示していると騙されるかもしれません。　1.Scre