エンジニアなら誰もが憧れる「美しいソースコード」、またエンジニアなら誰でも怒りと不安を覚える『プログラマ35歳定年説』。この技術とキャリアをめぐる2つの大テーマについて、初の国産メジャープログラミング言語「Ruby」の開発者として名高い、まつもとゆきひろ氏が独特の視点でじっくりと語ります。 また、講演終了後、ベテラン転職エージェントが、エンジニア向け無料キャリアカウンセリングを実施しますので、ご希望の方は是非、お立ちよりください。
Sennaでは、UTF-8の文字列を正規化しています。 たとえば、「?」は「ミリバール」に、「AbRACADAbra」は「abracadabra」に、「ハラヘッタZO」は「ハラヘッタZO」に変換されます。 これで、文字のゆれに対応した検索ができるわけです。 さて、某サービスでWAVE DASH(〜)とFULLWIDTH TILDE(〜)を同一視してほしい、 という要望が届きました。 そういうときはlib/nfkc.cをいじるとよいです。 lib/nfkc.cのいじり方について説明します。このソースコードは自動生成されていますので、直にいじるのはちょっと大変です。 lib/nfkc.c自動生成のためのプログラムは、util/unicode/以下に入っています。 util/unicode/icudump.cに以下のようなパッチを当てれば、FULLWIDTH TILDEを全てWAVE DASHに
はじめに 与えられた文字列を含む文書を返す検索機能を実装しているところを想像してください。 検索語として「ページ」が与えられれば、「ページ」という文字列を含む文書を返します。これは特に難しいことではありません。 半角の「ページ」が与えられたらどうでしょう。「ページ」と「ページ」を区別する必要がないような、一般的な文書検索においては、「ページ」という文字列を含む文書を返すのが望ましいはずです(もちろん、この2つは常に同一視できるわけではありません。同一視できない例として本稿があります)。 もしかしたら、「㌻」で検索しようとする人がいるかもしれませんし、日本語を母国語としない人が、「ぺ」(「ヘ」と半角の半濁点「゚」)や「ヘ゜」(半角カナ「ヘ」と半濁点「゜」)を使うかもしれません。 人間なら簡単に対応できることですが、コンピュータで対応するには特別な処理が必要になります。例えばUnic
正しい並び替えでは、表示は(A)のままですが、間違った並び替えでは、正規結合クラスが互いに等しいMACRONとACUTEを並び替えたため、表示は(B)のように、eの上のアクセント記号の位置が入れ替わってしまいます。 正規分解・互換分解 ある文字列の正規分解 (Canonical Decomposition) を得るには、まず、それぞれの文字を正規マッピングによって再帰的に、可能な限り、分解します。すなわち、1回分解した後に現れた文字がなおも分解可能であればさらに分解します。分解マッピングがその文字自身である場合は、分解不可能なので、そのままです。 しかし、分解しただけでは必ずしも正しい結果が得られません。つまり、結合文字の順序の一意性を保証するため、分解後の文字列に対して正規順序アルゴリズムを適用しなければなりません。このように、正規マッピングによる再帰的分解と、正規順序アルゴリズムによ
The Ideographic Variation Database provides a registry for collections of unique variation sequences containing ideographs, allowing for standardized interchange according to UTS #37, Unicode Ideographic Variation Database. This page records the successive versions of the IVD, the registered IVD collections, includes a note about the length of the review period, and lists the submissions under rev
UTF8 フラグについてわかってるつもりだったんですが,utf8::is_utf8 considered harmful - Bulknews::Subtech - subtech を読んで混乱したので,自分なりにまとめてみました。間違いがありましたらご指摘よろしく。 まとめ スカラー変数の内部表象の状態を示すものとして UTF8 フラグというものがある スカラー変数は(リファレンス等は別として)下記のものを格納できる (A) 文字列(内部表象: UTF-8) (B) 文字列(内部表象: ISO-8859-1) (C) バイナリ列 純粋なバイナリストリーム(画像ファイル等)かもしれないし, UTF-8 octet stream かもしれないし, CP932 octet stream かもしれないし,etc, etc ... Perl は(後方互換性確保などの理由から)ISO-8859-1
Firefoxは内部的に変換処理を行うようになっているようです。 問題はSafariとOperaですね。 選択されたファイルのパスからJavaScriptで ファイル名を抜き出してタイトルに設定する部分で、 正しく扱えるような文字コードに変換することにしたいと思います。 基本的な流れとしては、UTF-8-MAC特有の「U+3099」(COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK)、 「U+309A」(COMBINING KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK)がファイル名に含まれている場合は、 その前の文字と結合して濁音・半濁音の文字にしてあげればいいでしょう (ひらがな・カタカナのみの暫定的な対処に過ぎませんが)。 変換用の文字テーブルを用意して、逐一変換していくかたちにしたいと思います。 というわけ
この文字は何? 2007-08-31T14:53:00+09:00 追記 某ブックマークサイトからお越しの皆様へ。おかげで、色々な情報を知ることができました。ありがとうございます! 下の「種明かし?」に追記しました。何となく種明かしになったのでは、と。まぁ、ムダ知識程度にお楽しみください。トラックバック先に有益な情報があるので、そちらもどうぞ。 ҉ はてなブックマーク経由で、上の不思議な記号のことを知りました。──フォントによっては見えなかったり、?や□になっていると思いますが、実際は「, で丸を描いたような記号」です。 どう不思議かは、下のフォームに文字を入力してみると、すぐわかるかと。この記号を消さないように、何か入力してみてください。 環境によると思いますが、入力した文字の流れが左右反対になります。とくに、日本語入力中でも反対になるのにビックリ(Windows XP
Seiji Masugata s.masugata @ digicom.dnp.co.jp 2007年 8月 9日 (木) 13:54:44 JST 前の記事 [PHP-dev 1379] Re: mbstring.cのtypo 次の記事 [PHP-dev 1381] Re: mb_strwidth関数とmb_strimwidth関数の挙動について 記事の並び順: [ 日付 ] [ スレッド ] [ 件名 ] [ 著者 ] こんにちわ、桝形です。 http://ml.php.gr.jp/pipermail/php-users/2007-August/thread.html#33032 PHP-usersのMLで少し盛り上がっていた件ですが、その後、さわださんと 個人的にメールでやりとりしているうちに、なんとなく掴めてきました。 内容の報告と今後の方向性について議論できれば、と思います。 さ
* Numbers of characters do not necessarily represent the total number of encoded characters used for the script (and are not necessarily the same as the number of characters in the same-named block), but are the number of characters that are uniquely assigned to that script by Unicode (i.e. excluding characters that have the Unicode script property of "common" or "inherited"). Some differences in
<< 2007/03/ 1 1. [Ruby] Rubyist Magazine - Rubyist Magazine 0018 号 2. ストレートタイプのスマートフォン「NOKIA E61」レポート 3. ITmedia エンタープライズ:TopCoderで世界と渡り合う日本IBMの異才 - 夷藤勇人 4. My Sleepless Nights in the Big Apple: Apple、サブノート市場へ再参入へ 5. ITmedia Biz.ID:失敗しないプロジェクトマネジメント -- Appleやはてな、Googleに学ぶ3つのヒント 6. 平成19年度「情報大航海プロジェクト(モデルサービスの開発と実証)」に係る委託先の公募について 7. [言語] PyCon 2007 Review 8. [Ruby] deep_science:Re:バザール「オープンソース、そして「R
新しい文字符号化方式 戻る リンク 文字符号について ユニコード UTFCP UTFCP2 UTFCP-TABLE 文字符号化方式比較 文字コード用語 UTFCPとUTF-JP 新しいUNICODE符号の必要性 UTF8では、日本語に対応する文字(ひらがな、カタカナ、全ての漢字)の符号長が3バイトです。一方、Shift_JISやEUCでは、2バイトで表せます。この意味で、UTF8は、今までの文字コードよりもある意味において改悪されています。この事情は、他国の文字に置いても同様で、例えば、中国語の文字(漢字)においても、今まで2バイトで表せていた物が、UTF8では、3バイト必要になります。これは、欧米/中東圏以外の世界のあらゆる国や言語の文字において言えます。今まで2バイトで余裕を持って扱えていたものを、突然3バイトで扱わなければならないと言われれば、誰でも納得しがたいものでしょ
これまで,Windows Vistaの文字の扱いに関する事柄を何度か取り上げてきた。同じキャラクタ・コードで,Windows XPのときと文字の形が変わったり,Unicodeでしか扱えない文字があったりするという話題だ。今回は,エンコーディングについて考えてみたい。 これまでの記事でも書いてきたが,文字処理とエンコーディングに関する問題は,何もWindows Vistaに始まったわけではない。Windows XPやWindows 2000など,既存のWindowsでも同様だ。例えば,「鴎」の旧字である「シナカモメ」は,Unicodeでしか扱えない文字だが,Windows XP以前のMS-IMEでも入力できる。石鹸の「鹸」の旧字もそうである。これらの文字を扱うには,アプリケーション・ソフトが,文字列をUnicodeで処理しなればならない。シフトJISに変換した瞬間に,文字情報が無くなってしま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く