サロゲートペアをJavaScriptで検出する方法

ちょっと調べる機会があったので。


まずサロゲートペアの性質について

・Unicode と UTF
http://www.parof.jp/Programing/Unicode/

Unicode で「D800〜DFFF」の範囲（これがサロゲート領域）にあるビット列がでてきたら、次の2バイトと合わせて1文字と認識しなさい、と定められています（逆に言うと、「D800〜DFFF」はそれだけで表現される文字というのが定められていません)。そしてこの領域のうち「D800〜DBFF」は4バイトのうち上位2バイトで使い、「DC00〜DFFF」は下位2バイトで使われます。

JavaScriptのcharCodeAtメソッドでサロゲートペアの文字
一文字を調べると、charCodeAt(0)で上位サロゲートのコード、
charCodeAt(1)で下位サロゲートのコードが返ってきます。
（ちなみにlengthは2です）

ここまで分かっていれば普通はコードをすらすら
書けるのでしょうけど、どうも最近コーディングしてないせいか
サボリ癖が。
そこで、それらしいサンプルをネットで探したのですが
なかなか見つかりませんでした。
ふとGoogle Code Search思い出して
「surrogate charCodeAt」で検索したら、それらしいのを発見。

blogs/rsc/js/md5.js - Google Code Search
「/* Decode utf-16 surrogate pairs */」というコメントの付近。

x = input.charCodeAt(i);
y = i + 1 < input.length ? input.charCodeAt(i + 1) : 0;
if(0xD800 <= x && x <= 0xDBFF && 0xDC00 <= y && y <= 0xDFFF)
{
〜略〜
}

これを参考にして、サロゲートペアの有無をチェックするものを
作ってみました。

こちら

自分用に作ったものなので、参考程度にとどめておいてください。

個別に取得した上位サロゲートと下位サロゲートのコード
再度組み合わせて一文字として表示させるには
String.fromCharCode(上位サロゲート,下位サロゲート);
とやるようなのですが、これがわかるのに苦労しました。

C10K問題ねぇ。。。（続き）

・Web2.0の先にあるC10K問題
http://www.atmarkit.co.jp/news/analysis/200701/09/c10k.html

先日のエントリでも取り上げました。

「○○問題」という日本語のインパクトや、@ITの記事がちょっと「？」な
内容だったためか、いろいろ記事へのつっこみがあるようですね。



識者の間で細かい論議がされているようですが、私としては
はてなブックマークのid:NOV1975さんのコメントにある

問題の本質は「スケールにあったアーキテクチャとハード構成を考えて設計しているか」だと思うけど。

にグっときました。

C10K問題ねぇ。。。

・Web2.0の先にあるC10K問題
http://www.atmarkit.co.jp/news/analysis/200701/09/c10k.html

Ajaxの実装として最近注目されている技術に“Comet”（コメット）と呼ばれるものがある。HTTPのセッションをあえて切断せずに、サーバとクライアント間でつなぎっぱなしにするテクニックだ。

同時接続ユーザー数が万のオーダーに達したとき、現在のOSやサーバのプログラミングモデルが現実に合わなくなってくることだ。

このように、1万クライアントには対応できても10万クライアントには対応できないという状況が「C10K問題」だ。Cはクライアント、10Kは1万を示す。

そりゃそうですよね。かなり無理やりな感じでしますのもね。cometって。
ちなみにcometのことは下記サイトで知りました。
・DWR2.0でのReverse Ajax(Commet)
http://www.noridon.net/weblogs/archives/2006/04/dwr20reverse_aj.html


一方、現adobeのRTMPのほうは、こういう問題はないのかな？


【関連エントリ】
・Web系雑記: Webアプリにリアルタイム性は必要か
http://webdev.seesaa.net/article/18882926.html

・Web系雑記: Reverse Ajax = comet ?
http://webdev.seesaa.net/article/23710772.html

NTTデータのAjaxアプリ開発ツール

・Ajaxアプリのビジュアル開発ツール，デファクトを狙いNTTデータがオープンソースとして公開へ
http://itpro.nikkeibp.co.jp/article/NEWS/20060915/248264/

ボタンやタブ，ツリーなどの画面オブジェクトをマウスで配置してアプリケーションを開発できる。

VBライクってこと？

まず用件定義担当者がWebブラウザ上の「マスカットWebブラウザ版IDE」で，Web画面をマウス操作でデザインすると，画面定義XMLが生成される。これを開発担当者が「マスカット Eclipse版IDE」にインポートして，画面オブジェクトと既存の業務ロジック・オブジェクトを対応付ける設定などを行い，レイアウト定義XMLとイベント定義XMLを生成する。マスカットの実行モジュールは生成されたXMLを読み込み，既存の業務ロジックと連携するAjaxアプリケーションを動作させる。

どうやら実装工程にとどまらないようですね。

マスカットでは，テキスト・ボックスに検索したい単語を入力し，それをグリッド（表）に表示するといった一連の処理を，プログラムを書かずに作成できる

すこしとっつきにくい感じがします。

Reverse Ajax = comet ?

・Ajaxの“彗星”とともに現われたチャットサービス“Lingr”を使ってみた
http://ascii24.com/news/i/serv/article/2006/09/11/664477-000.html

Cometというのは何か特定の新しいプログラムやプロトコルを指す技術というよりも、サーバー・クライアント通信方式でリアルタイム性を重視した「HTTPコネクションの管理作法」という実装スタイルを指す。

Ajaxでウェブアプリケーションのレスポンスが良くなると、“クライアントからのリクエスト→サーバーのレスポンス”という一方通行だけの通信より一歩進んで、逆方向の通信も行ないたい、というニーズが生まれた。それが、HTTPコネクションをあえて切断せずに“つなぎっぱなし”にしてしまう実装スタイル、通称Cometというわけだ。

つまり、Ajaxでは難しいといわれていたサーバープッシュ配信のような
ものでしょうかね、

comet?


なにか聞いたことあるぞ…。


と思ったら「Webアプリにリアルタイム性は必要か」ですこし触れていました。

JSON と JSONP と JSPON

JSON関連、なんかいろいろでてくるなぁ。


・JSONP
　

・JSPON
　まだはてなキーワードになってないや。

JavaScriptで3桁区切りのカンマ

会社で話題になったらしいのですが、JavaScriptで3桁区切りのカンマ表示
は自作の関数がいるようですね。

個人的に好きなのは正規表現による置換でやっちゃうやつ。すっきりしてますし。

function addFigure(str) {
var num = new String(str).replace(/,/g, "");
while(num != (num = num.replace(/^(-?\d+)(\d{3})/, "$1,$2")));
return num;
}

引用元：http://www.gac.jp/article/index.php?stats=question&category=9&id=4207&command=msg
(レス008)

IE5でも配列にpush（擬似的）

JavaScriptで

var names = new Array();
names.push("taro");
names.push("hanako");

のようなコードがエラーになってしまってハマっていました。
IE6では正常に動作しました。

で、ちょっと調べてみるとWin + IE5やMac IE 5.2でpush()が使えませんでした。

なんかうまいことできないかなと思ってたどり着いたのが以下の方法。

var names = new Array();
names[names.length] = "taro";
names[names.length] = "hanako";

けっこうスマートだと思います。

・EZ-NET： JavaScript プログラミング - 配列
http://program.station.ez-net.jp/special/handbook/javascript/page/array.asp#Mac_%82%C5%83X%83^%83b%83N%82%E7%82%B5%82%A2%8F%88%97%9D%82%F0%82%B7%82%E9%82%C9%82%CD

getElementsByTagName の注意

IEとそれ以外ではのような名前空間つきのタグを
getElementsByTagNameで拾うときの指定方法が違うようです。

JavaScript でDOMる際に引っかかったのでメモ。 aiueo のように名前空間を指定したタグを getElementsByTagName で引っ掛けるとき、IEでは

getElementsByTagName('dc:subject')

とするけど、それ以外だと

getElementsByTagName('subject')

とする。

だそうで。

http://matatabi.homeip.net/blog/setomits/629

JavaScriptでz-indexを操作するときの注意

いえ、別にたいしたことでないのですけどね。
今日たまたま知ったのでメモです。

通常JavaScriptからCSSのプロパティを操作するときは

オブジェクト名.style.CSSプロパティ名 = "値"

のようにします。

例：　document.getElementById("main").style.display = "none";
(mainというIDが振られている要素の表示を消す)

ただし、z-index(重なりの順序)を操作するときは注意が必要です。

オブジェクト名.style.z-index = 0;

ではなく

オブジェクト名.style.zIndex = 0;

とやります。

「style.z-index」でやるとエラーになっちゃいます。

「window.onload=function(){}」ってそういうことだったんだ

最近のJavaScriptのコードをみていると、よく

window.onload=function(){
// 処理
}

や

window.onload=hoge;

function hoge(){
// 処理
}

のようなスタイルを見かけます。

なんでbodyタグのonload属性で書かないんだろうと思ってました。


上記2例のようなスタイルだとHTMLとロジックを分離できるという
メリットがあるのですね。タグにJavaScriptの関数名を書かなくてよいし。
なるほど。

慣れていない私は、処理を追っかけるが少し手間になっちゃいますが。
（外部jsにかいてあるかもしれませんしね。）

もちろんこれだけが理由じゃないと思いますけどね。

・イベントハンドラを外部スクリプトファイルに書く
http://web.paulownia.jp/script/tips/handler.html

イベントハンドラを外部スクリプトファイルに書く
onloadやonchange等のイベントハンドラをHTML中に書く必要は無く、JavaScript外部ファイルに記述できる。これによって文書とJavaScriptロジックを完全に分離できる。

Ajaxでクロスドメイン処理

当ブログのアクセス解析をしていると、googleで「クロスドメイン　ajax」で
検索してこられる方がいらっしゃいました。
たぶん、そういう方の思っている記事を今まで書いてなかったので紹介程度
に書いておきます。ご存知の方も多いと思いますが。

本題。
Ajaxの弱点のひとつは、別ドメインのコンテンツ（XML）などを直接取得
できないことにある、といいます。

その弱点に対する解は「JSON」。（他にも方法あります）
JSONは「軽量なデータ交換フォーマット」であり、JSON経由で
データを取得する分には別ドメインとか関係ないわけです。

で、XMLをJSONに変えてくれるサービスなんかもあるので、この
サービスを間に挟めば別ドメインのXMLデータをJSON経由で
取得できるようです。

試してませんが。何かのヒントに。


・XML を JSON に変換するサービス - ベータ版を公開 :: Drk7jp
http://www.drk7.jp/MT/archives/001011.html

JSON は JavaScript 上でそのまま使えるデータ形式でクロスドメイン制限がないという特徴を持ちます。したがって、別ドメインで配布されている JSON を自ドメイン内から JavaScript レベルでデータを利用することができます。

・Collection & Copy - JSON入門
http://d.hatena.ne.jp/brazil/20050915/1126709945

JSON(JavaScript Object Notation)は、軽量のデータ交換フォーマットです。人間にとって読み書きが容易で、マシンにとっても簡単にパースや生成を行なえる形式です。

ついでにメモ
・ベイエリア情報局: Javascriptでxmlhttprequestをする時のアクセスできるドメイン
http://blog.bz2.jp/archives/2005/06/javascriptxmlht.html

xmlHttpRequestのクロスドメインの問題は、「呼び出し元のJavascriptファイルが置いてあるドメインと、呼び出し先のウェブサーバのドメインが同じじゃないといけない」わけではなく、「Javascriptを呼び出しているページのドメインと、呼び出し先のウェブサーバのドメインが同じじゃないといけない」わけで、Javascriptファイルがどこにあっても関係ないようです。