雨林

2009년 12월 19일 토요일

IE tester

http://www.my-debugbar.com/wiki/IETester/HomePage

ブラウザ　各バージョン毎にテストできるような便利なツール

2009년 12월 16일 수요일

Javaアプリをマルチプラットフォームに対応して開発する場合はSJIS、EUCが混在するとトラブルの元なので文字コードはすべてUTF-8に統一しています。

WEB アプリの場合、たとえばtomcatだと起動シェルに JAVA_OPTS="-Dfile.encoding=utf-8" を定義するとtomcatは日本語の文字コードをすべてUTF-8になります。が、このままwindows XP上のeclipseのなかから起動するとコンソール文字列が化けてしまいます。

これはEclipseがデフォルトエンコードをMS932と判断しているからで、明示的にUTF-8にすれば解決します。

明示的にEclipseのエンコーディングをUTF-8にするにはeclise.exe と同じフォルダにあるeclipse.ini ファイルに"-Dfile.encoding=utf-8" を追加します。


-vmargs
-Xms40m
-Xmx256m
-Dfile.encoding=utf-8

2009년 12월 3일 목요일

jxl jxl.biff.formula.NameRange.read error

SQL生成ツールを作るところ、JEXCEL　api にてエクセルファイルを読み取る処理の中で、下記と同様なエラーが

たまたま出た。

おかしいのは記述内容が同じであるファイルなのに、正常に読み取れるファイルがあるつつ、ためなものがあｔったのだ。

原因を探ってみたら、

09/12/02 17:02:34:968,[main ],[jp.co.hitachi.twx21.framework.gen.task.FwAbstractTask],DEBUG,common.AssertionFailed

at common.Assert.verify(Assert.java:37)

at jxl.read.biff.WorkbookParser.getName(WorkbookParser.java:1117)

at jxl.biff.formula.NameRange.read(NameRange.java:88)

at jxl.biff.formula.TokenFormulaParser.parseSubExpression(TokenFormulaParser.java:214)

at jxl.biff.formula.TokenFormulaParser.parse(TokenFormulaParser.java:111)

at jxl.biff.formula.FormulaParser.parse(FormulaParser.java:110)

at jxl.biff.DVParser.<init>(DVParser.java:428)

at jxl.biff.DataValiditySettingsRecord.initialize(DataValiditySettingsRecord.java:140)

at jxl.biff.DataValiditySettingsRecord.getFirstColumn(DataValiditySettingsRecord.java:234)

at jxl.read.biff.SheetReader.read(SheetReader.java:994)

at jxl.read.biff.SheetImpl.readSheet(SheetImpl.java:676)

at jxl.read.biff.SheetImpl.getColumns(SheetImpl.java:448)

at net.java.amateras.xlsbeans.Utils.getCell(Utils.java:73)

at net.java.amateras.xlsbeans.Utils.getCell(Utils.java:69)

at net.java.amateras.xlsbeans.processor.LabelledCellProcessor.doProcess(LabelledCellProcessor.java:44)

データ入力規則で定義した名前とかプリント領域（どういう経路ではいったのか不明）の中で、

ようすると、リンクがこわれた名前定義があるとこういうエラーがでる。

改善策は

メニュー＞数式＞名前の管理（エクセル2007）で

壊れた名前とか要らない名前を削除すれば、正常になる。

2009년 11월 28일 토요일

s2Fisshplate

009-10-09

■[Seasar2]S2Fisshplateを使ってみる 17:08

今の案件では，Excelを帳票として出力する機能があるんですが，POIでポイポイするのは結構大変･･･。しかも，何だかズイブンと複雑なExcel帳票を依頼されたので，何とか工数を削減出来ないものかと，id:gokingさんにヘルプを頼んでみました。

そこで候補として上がったのがFisshplateで，S2Fisshplateなんてものまであったんで，導入してみようと思いホゲホゲしてみた（実際にホゲホゲしたのはgokingさんなんですけどねｗ）

そもそもFisshplateって何じゃらホイ？

Fisshplate公式ページ

Fisshplateとは，Excelにテンプレート式を記述して，テンプレート式を元に動的にデータを出力しちゃおうというライブラリです。

埋め込みデータ

動的に値をテンプレートに出力するには，

${hoge}
${foo.hoge}

プログラム側からは，Mapで渡してキー文字列がテンプレートのバインド変数となり，値を参照する事が出来ます。JavaBeansの場合はプロパティを参照（ネストもOKっぽい）出来るようです。（getterが必要）

テンプレート式

文法（テンプレート式）には，以下のようなものがあります。

foreach
hforeach
while
if
pageBreak
pageHeaderStart
pageFooterStart
スクリプト実行
変数の評価の遅延
ハイパーリンク埋め込み
コメント

独自タグ（テンプレート式）

独自にタグも作成できるらしく，「要素クラス」と「パースクラス」のペアを作成して，「FPTemplate」クラスにaddしてあげればOKみたい。

S2Fisshplate

S2Fisshplateは，S2とFisshplateを連携させて，インタフェースを定義するだけでFisshplateの機能を使う事が出来ます。S2FisshplateはS2Containerに非依存との事。

基本的には，Fisshplateと利用方法は一緒なんですが，規約に沿った形で作らないと処理されません。（インターフェースとExcel テンプレートのファイル名とか）

テンプレートに埋め込むDtoのプロパティは，「プロパティのsetter、getterを必ず作って下さい。publicフィールドの動作は確認していません。」との事でしたが，サンプルで動かしたDtoはpublicフィールドでも動作しました。ただ，確認していないとの事なので，setter/getterは用意した方が良いかも。

何となく思った事

Fisshplateは決まりきったテンプレートに対して，値を動的に出力する場合には威力を発揮すると思います。ただ，複雑怪奇なテンプレートに対して適用すると返って大変になりそうなので，複雑なテンプレートに対しては，Fisshplateを部分的に利用して，後は素のPOIでポイポイした方が良いような気がします。

また，縦方向の繰り返しには強いんですが，横方向の繰り返しはちょっと弱いようなので，そういった部分でも利用には注意が必要かもです。

2009년 11월 27일 금요일

既存の日本語文字コードと Unicode の間のマッピングルール

はじめに

Qt 2.0 に既存の日本語文字コードと Unicode の間の変換クラスを突っ込もうと思って調べはじめたら想像以上にややこしいことになっていてはっきり言ってお手上げ状態なんですが、とりあえず調べたところまではまとめておくかな、ということでページを作ってみました。こんなものでも何かの参考になれば幸いです。

ここでは ASCII, JIS, EUC, ShiftJIS, Unicode について知っていることを前提としています。

このページでは 0x1234 のように書いてあるものは既存の文字コードを 16 進数で表したもの、 U1234 のように書いてあるものは Unicode を 16 進数で表したものです。通常は Unicode は U+1234 のように書くんですが、最初に図を書く時に U1234 って書いちゃって修正するのが面倒なのでこれで行きます(^^;。

抜けや間違い等を発見した場合は hc3j-tkg at asahi-net.or.jp までご一報下さいm(_ _)m。

参考文献

Unicode-1.1 : ASCII <-> Unicode

まずは ASCII コードについてですが、これはなんてことはなくて、 0x20～0x7e まで (制御コードも含めると 0x00～0x7f まで) がそのまま U0020～U007e (U0000～U007f) にマップされます。

Unicode-1.1 : JISX0201, JISX0208, JISX0212 <-> Unicode

次は Unicode 1.1 の仕様に従った場合の JISX0201, JISX0208, JISX0212 のマッピングですが、JISX0208, JISX0212 については順不同で Unicode にマップされるので詳細については省略します。ここでのポイントは以下の点です。

JISX0201 の 0x20～0x7e まで (制御コードも含めると 0x00～0x7f まで) は、二つの例外を除いて、ASCII と同じく U0020～U007e (U0000～U007f) にマップされます。
JISX0201 の 0x5c は ASCII の 0x5c と違って U00a5 (Yen Sign) にマップされます。
JISX0208 の 0x2140 ('＼') は U005c (Reverse Solidus) にマップされます。
JISX0201 の 0x7e は ASCII の 0x7e と違って U203e (Overline) にマップされます。
JISX0212 の 0x2237 ('・') は U007e (Tilde) にマップされます。

日本語 EUC の問題

さて、Unicode-1.1 のマッピングルールに従った場合、JISX0201 + JISX0208 である ShiftJIS を Unicode に変換するのには特に問題はありません。しかし、ASCII + JISX0201 Kana + JISX0208 + JISX0212 である日本語 EUC を Unicode に変換しようとすると下の図のように U005c と U007e で衝突が起こってしまします。この時点で既に Unicode-1.1 の規格では問題があって、既存の日本語文字コードを扱うには不十分だと言えます。そこで、この問題をどうやって回避するか、なんですが…これが困ったことにプラットフォームによって様々なのです。

オープングループの日本ベンダ協議会の CDE/Motif 技術検討 WG が Unicode とユーザ定義文字・ベンダ定義文字に関する問題点と解決策を公開しています。そのコード変換規則について見てみます。

JISX0221-JISX0201

JISX0221 で 0x20～07e を JISX0201 とみなす場合のマッピングルールで、事実上、ShiftJIS <-> Unicode 用のマッピングルールでしょう。 Unicode-1.1 とは 0x213d ('―') が U2015 (Horizontal Bar) ではなくてU2014 (Em Dash) にマップされる点だけが異なっています。私にはどちらが好ましいのかは分かりません。というか、どっちでも良いから一つに決めてくれ、というか。

JISX0208	Unicode-1.1	JISX0221-JISX0201
0x213d ('―')	U2015 (Horizontal Bar)	U2014 (Em Dash)

JISX0221-ASCII

JISX0221 で 0x20～07e を ASCII とみなす場合のマッピングルールで、事実上、日本語 EUC <-> Unicode 用のマッピングルールでしょう。 U005c, U007e での衝突を避けるために JISX0208 の 0x2140 ('＼') が Uff3c (Fullwidth Reverse Solidus) に、 JISX0212 の 0x2237 ('・') が Uff5e (Fullwidth Tilde) にマップされます。それ以外に、JISX0221-JISX0201 と同様に JISX0208 の 0x213d ('―') が U2015 (Horizontal Bar) ではなくてU2014 (Em Dash) にマップされるのに加えて、 JISX0208 の 0x2131 ('￣') が U203e (Overline) に、0x216f ('￥')が U00a5 (Yen Sign) にマップされる点が Unicode-1.1 と異なっています。

JISX0201 の代わりに ASCII を採用することで U00a5 と U203e が空きになるのですが、なぜわざわざそこを埋めなければならないのでしょう…? SJIS -> Unicode -> EUC あるいは EUC -> Unicode -> SJIS と変換した時のことを考えているのかと思ったんですが、例えば SJIS JISX0201 0x5c -> U00a5 -> EUC JISX0208 0x216f とすると半角円記号が全角円記号になっちゃいますし、あるいは SJIS JISX0208 0x216f -> Uffe5 -> EUC × とすると全角円記号がどこにもマップされないということになっちゃいますし…。

その後考えたのですが、Unicode がまずあってそれを既存の文字コードにマッピングする場合に U00a5 (Yen Sign) をマップする先がないというのが問題なのではないでしょうか。でも、そうだとしたら Uffe5 (Fullwidth Yen Sign) にもマップする先がないとまずいですよね…う～ん、そうすると今度は1対1対応でなくなっちゃうか。その辺はユーザの側で適宜対応してね、ということになるのでしょうか。

JISX0208	Unicode-1.1	JISX0221-ASCII
0x2131 ('￣')	Uffe3 (Fullwidth Macron)	U203e (Overline)
0x213d ('―')	U2015 (Horizontal Bar)	U2014 (EM Dash)
0x2140 ('＼')	U005c (Reverse Solidus)	Uff3c (Fullwidth Reverse Solidus)
0x216f ('￥')	Uffe5 (Fullwidth Yen Sign)	U00a5 (Yen Sign)
JISX0212	Unicode-1.1	JISX0221-ASCII
0x2237 ('・')	U007e (Tilde)	Uff5e (Fullwidth Tilde)

Windows における変換

従来の文字コードに ShiftJIS を使っているということで JISX0201 + JISX0208 ( + 外字) <-> Unicode というマッピングルールです。が、いろいろ変です。 JISX0201 の 0x5c が ASCII の 0x5c と明確に区別されることなくパス名の区切り記号として使われている & バイナリレベルでアプリケーションの互換性を保たなければならないために JISX0201 0x5c を U005c にマップするということをやっています。 JISX0208 の 0x2140 ('＼') が Uff3c (FULLWIDTH REVERSE SOLIDUS) に、JISX0212 の 0x2237 ('・') が Uff5e (FULLWIDTH TILDE) にマップされるのはいいのですが、それ以外に、どういうわけか JISX0208 の '～', '∥', '－', '￠', '￡', '￢' と JISX0212 の '・' が Unicode-1.1 と違うマッピングとなっています。これらの文字が化けるという経験をしたことがある方は結構いるのではないでしょうか?

このあたりは XKP でも認識していて Microsoft に要望として出しているようですが、いまさら変更するようなことは恐らくしないでしょうねぇ。

JISX0201	Unicode-1.1	Windows
0x5c	U00a5 (Yen Sign)	U005c (Reverse Solidus)
0x7e	U203e (Overline)	U007e (Tilde)
JISX0208	Unicode-1.1	JISX0221-ASCII
0x2140 ('＼')	U005c (Reverse Solidus)	Uff3c (Fullwidth Reverse Solidus)
0x2141 ('～')	U301c (Wave Dash)	Uff5e (Fullwidth Tilde)
0x2142 ('∥')	U2016 (Double Vertical Line)	U2225 (Parallel To)
0x215d ('－')	U2212 (Minus Sign)	Uff0d (Fullwidth Hyphenminus)
0x2171 ('￠')	U00a2 (Cent Sign)	Uffe0 (Fullwidth Cent Sign)
0x2172 ('￡')	U00a3 (Pound Sign)	Uffe1 (Fullwidth Pound Sign)
0x224c ('￢')	U00ac (Not Sign)	Uffe2 (Fullwidth Not Sign)
JISX0212	Unicode-1.1	JISX0221-ASCII
0x2237 ('・')	U007e (Tilde)	Uff5e (Fullwidth Tilde)
0x2243 ('・')	U00a6 (Broken Bar)	Uffe4 (Fullwidth Broken Bar)

Sun の JDK における変換

Java では char 型が C/C++ のように 8bit ではなくて 16bit で Unicode を表します。ということでどういう変換を行っているか見てみると… EUC, JIS, SJIS ともサポートする必要があるためにか、これまた独自のマッピングルールを採用しています。

ASCII と JISX0201 Latin は同じ扱いとする。
U00a5, U203e が空きになるが、JISX0201 から変換された Unicode ではこれらが出てくることがあるので、Unicode -> ASCII の単方向のみそれぞれ 0x5c, 0x7e にマップする。と思ったら、U00a5 -> 0x5c はあるけど U203e -> 0x7e はないみたい。
JISX0208 0x2140 ('＼') は ASCII との衝突を避けるために Uff5c にマップする。
JISX0212 0x2237 ('・') が U007e にマップされるが、未対応。恐らく JISX0212 は誰も使ってないので誰も困ってなくて誰も Sun に報告してないのでそのままになっているんじゃないかと勝手に想像してます(^^;。

JISX0201	Unicode-1.1	Sun JDK
0x5c	U00a5 (Yen Sign)	U005c (Reverse Solidus)
0x5c	<-	U00a5 (Yen Sign)
0x7e	U203e (Overline)	U007e (Tilde)
0x7e	<-	U203e (Overline)
JISX0208	Unicode-1.1	JISX0221-ASCII
0x2140 ('＼')	U005c (Reverse Solidus)	Uff3c (Fullwidth Reverse Solidus)

Bug Parade で JIS をキーに検索するといろいろ出てきますので興味のある方はどうぞ。 Windows で JISX0208 の '～', '∥', '－', '￠', '￡', '￢' が化けることがあるという問題は Java のレベルで解決する類のものではない、としているようです。

mule-ucs における変換

mule-ucs-0.01.tar.gz について調べてみたところ、 Unicode-1.1 の規則をそのまま採用しているようです。

Be-OS における変換

伊藤隆幸さんが News に

From: yuki@dayo.ne.jp (ITO Takayuki)
Newsgroups: fj.os.beos
Subject: BeOS Unicode conversion survey
Date: 07 Mar 1999 18:33:07 GMT
Message-ID: <7bugqd$5af$2@horse.fsinet.or.jp>

という記事をポストされていますが、マッピングルールの問題、入力メソッドの問題、フォントの問題、文字幅の問題が重なっていろいろ苦労されているようです。

ここではその記事から分かる範囲でとりあえずマッピングルールについてのみ見てみます。 U005c が半角円記号に、U007e が Tilde に見えるということからすると、 ASCII と JISX0201 Latin を特に区別しているわけではなさそうです。 JISX0208 については、次の点が問題になっているようです。

0x2140 ('＼') が U005c (Reverse Solidus) にマップされているのは Unicode-1.1 と同じですが、Unicode -> JIS では U005c -> 0x005c となって元の 0x2140 に戻りません。
0x2141 ('～') が U301c (Wave Dash) ではなく Uff5e (Fullwidth Tilde) にマップされます。
0x215d ('－') が U2212 (Minus Sign) ではなく U002d (Hyphen-minus) にマップされていますが、Unicode -> JIS では U002d -> 0x002d となって元の 0x215d に戻りません。
0x2160 ('÷') が U00f7 (Division Sign) にマップされているのは Unicode-1.1 と同じですが、Unicode -> JIS では U00f7 -> 0x00f7 となって元の 0x2160 に戻りません。
0x217b ('○') が U25cb (White Circle) ではなく U25ef (Large Circle) にマップされます。

ベンダ定義文字の問題

NEC 特殊文字と IBM 拡張文字に関してですが、 JISX0208 と NEC 特殊文字の両方に入っている文字があったり、 NEC 特殊文字と IBM 拡張漢字の両方に入っている文字があったりします。これについては XKP から入手できる WindowsNT 拡張漢字処理仕様書 2.1 の 5.1.2 重複符号文字の対応関係のところにまとめてあるのでそちらをご覧頂くのがよろしいかと。

JIS エンコーディングの問題

ISO-2022-JP では ASCII, JISX0201 Latin, JISX0208 (ISO-2022-JP-2 ではそれに加えて JISX0212) が混在する可能性があるため、Unicode 上でこれら全てが区別できなければなりません。残念ながら上記のマッピングルールはいずれもこの条件を満たしていません。

Unicode-1.1 : 既に指摘したように ASCII と JISX0208, JISX0212 との混在ができません。
JISX0221-JISX0201 : ASCII を加えると U005c, U007e で衝突が発生します。
JISX0221-ASCII : JISX0201 を加えると U00a5, U203e で衝突が発生します。
Microsoft : ASCII と JISX0201 Latin を区別できません。また、Uff5e で衝突が発生しています。
Sun JDK : ASCII と JISX0201 Latin を区別できません。また、U007e で衝突が発生しています。
Be-OS : U002d, U005c で衝突が発生しています。

厳密には JISX0208-1978 と JISX0208-1983 も区別しなきゃいけないらしいですが、そこまでは調べていません。そもそも、これらと Unicode の間のマッピングルールって存在するのでしょうか？

I18N のための code set としては Unicode-1.1 は(多少 Know-How は必要だが)一応使える。
CJKV を含む M17N のための code set としては Unicode-1.1 は単独では使えない。 M17N に使おうと思ったら Unicode の文字列に何らかの形で言語情報等を付加する必要がある。
M17N ではなく I18N のために使うのであれば同時に一つの言語についてのみ考えればいいわけで、 CJK その他いろいろな言語が入り混じっていて巨大なテーブルを用意しないと変換できない Unicode を使わなくても、 16bit のところに JIS コードなら JIS コードをそのまま突っ込んでやってもいいんじゃないかな? ISO-8859-1 と重なるところだけ揃えてやれば実用上問題になることはあまりなさそうな気がしますが…。
Unicode-3.0(?) には言語タグ、異字体タグが入るそうで、そうなると CJKV を含む M17N にも使えるようになるのかな?

ソースコード

戻る

2009년 11월 18일 수요일

정규식(Regular Expression) 대충 정리...

자바스크립트에서는(여기서만 이런건지 잘 모르겠지만...) 정규식을 /.../로 묶어준다.

var pattern = /rules/;

식으로 써주면 된다.

^ : 시작표시(매칭이 처음부터 되어야 함)
$ : 끝표시(문자열 끝에 매칭되어야 함)
[] : 문자열 셋
[ab][a-z][0-9] 라고 써주면 첫글자는 a또는 b이고 그 다음에 a~z가 나오고 그 뒤에 0~9가 나온다는 뜻..
[]안에서 ^쓰면 그 문자가 아닌것들
* : 0번 이상 반복
+ : 1번 이상 반복
? : 0 또는 1회
{} : 횟수 표시
[a]{2}이면 aa이고 [a]{2,}이면 a가 2개 이상인거 [a]{2, 4}이면 aa, aaa, aaaa 이다.
\d : 숫자, [0-9]와 같음
\D : 숫자가 아닌 것들 [^0-9]와 같음
| : Or의 뜻
{} : 그룹을 묶어 준다.
. : 뉴라인(\n)제외한 한 문자 (진짜 .을 찍기 위해선 \.으로 표시해야 한다.)

더 자세한 문법은 Wikipedia

참고

옵션 /rules/ig 와 같이 써준다.

g : 글로벌의 뜻. 전역 매칭을 한다. 처음부터가 아닌 전체에서 정규식이 맞는걸 찾는다.
i : case Insensitive, 대소문자 구별안함
m : Multiline

정규식 테스트 사이트

덧) 특수문자를 매칭시켜주려면 \\를 사용한다. \\. 이나 \\| 처럼..... 2008.7.11

알고 있어야 할 8가지 정규식 표현 from nettuts+

http://blog.outsider.ne.kr/360

nettuts+에 Vasili

이 쓴 유용한 정규식 표현에 대한 글

을 올려서 내용 정리합니다. 정규식만 잘 써도 Validation이나 String을 다루기가 무척 편할텐데 쓸때마다 헷갈리고 약간은 어렵게 느껴지고 쉽게 다가가지지 않는게 정규식인것 같습니다.

Vasili는 정규식에 대해서 잘 모르면 Regular Expressions for Dummies

스크린캐스트 시리즈를 보기 권하고 있습니다. 시간내서 보면 꽤 도움이 될듯 합니다. 자리 잡고 스크린캐스트 보게는 잘 안되는것 같습니다. 글을 읽어도... ㅎㅎ

정 규표현식을 공부해도 막상 적용하려면 약간 막막하고 헷갈리기 마련인데 웹개발할 때 보통 많이 사용할 만한 내용을 위주로 설명해 주었기 때문에 이해하기도 쉽고 활용해서 쓰기에 꽤나 유용할 듯 보입니다. (위에도 간단히 밝혔지만 nettuts+의 올라온 포스팅을 번역,정리한 내용입니다.) 간단한 정규표현식 문법은 전에 올린 포스팅을 참고하시면 될 것 같습니다.

Matching a Username

view plain print ?

// Pattern
/^[a-z0-9_-]{3,16}$/

// Pattern
/^[a-z0-9_-]{3,16}$/

문자열의 시작부분을 찾는 ^ 다음에 소문자(a-z)나 숫자(0-9), 언더스코어(_), 하이픈(-)가 나올 수 있고 {3, 16}은 앞의 캐릭터들( [a-z0-9_-] )이 최소 3개에서 15개 이하로 나와야 하고 문자열의 끝을 의미하는 $가 마지막에 나옵니다.

Match되는 스트링 : my-us3r_n4m3
Match되지 않는 문자열 : th1s1s-wayt00_l0ngt0beausername (너무 김)

Matching a Password

view plain print ?

// Pattern
/^[a-z0-9_-]{6,18}$/

// Pattern
/^[a-z0-9_-]{6,18}$/

username부분과 아주 유사합니다만 유일하게 다른 부분은 글자수가 3~16자가 아니라 6~18자라는 부분( {6,18} )입니다.

Match되는 스트링 : myp4ssw0rd
Match되지 않는 문자열 : mypa$$w0rd (달러($)표시가 포함되어 있음)

Matching a Hex value

view plain print ?

// Pattern
/^#?([a-f0-9]{6}|[a-f0-9]{3})$/


// Pattern
/^#?([a-f0-9]{6}|[a-f0-9]{3})$/

이번에서 문자열의 시작을 찾는 ^로 시작합니다. 그 다음 number sign(#)은 뒤에 물음표(?)가 있기 때문에 옵션입니다. 물음표(?)는 그 앞에 나온 캐릭터가(여기서는 number sign)이 선택사항(있어도 되고 없어도 되는)임을 의미합니다. 그 다음에 나오는 그룹(괄호 안에 있는)에서 2가지 경우를 가질 수 있습니다. 첫번째는 a와 f사이의 소문자나 숫자가 6번나오는 것입니다. 세로바(|)는 3개의 a와 f사이의 소문자나 숫자가 대신 나올수도 있음을 으미합니다. 마지막으로 문자열의 끝을 의미하는 $가 위치합니다.

6개의 문자열을 앞에 둔 이유는 #ffffff같은 Hex값을 파서가 잡아내도록 하기 위한 것으로 반대로 3개의 문자열 검사를 앞에 두었다면 파서는 뒤의 3개의 f는 빼로 오직 #fff만을 잡아냈을 것입니다.

Match되는 스트링 : #a3c113
Match되지 않는 문자열 : #4d82h4 (h 가 포함되어 있음)

Matching a Slug

view plain print ?

// Pattern
/^[a-z0-9-]+$/



// Pattern
/^[a-z0-9-]+$/

mod_rewrite나 pretty URL을 사용해 본적이 있다면 이 정규표현식을 사용하게 될 것입니다. 시작 문자열인 ^가 처음에 나오고 뒤이어 소문자, 숫자, 하이픈(-)이 한개 또는 한개이상(+기호)나오고 마지막으로 문자열의 끝인 $가 나옵니다.

Match되는 스트링 : my-title-here
Match되지 않는 문자열 : my_title_here (언더스코어( _ ) 가 포함되어 있음)

Matching an Email

view plain print ?

// Pattern
/^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,6})$/




// Pattern

/^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,6})$/

문자열의 시작인 ^로 시작하고 첫번째 그룹(괄호 안)에서 1개 또는 그 이상의 소문자, 숫자, 언더스코어( _ ), 점(.), 하이픈(-)가 나옵니다. escape하지 않은 점(.)은 다른 문자를 의미하기 때문에 점(.)은 이스케이프 해줍니다.(\.) 그 뒤에 앳 기호(@)가 나오고 그 다음 1개또는 그 이상의 소문자, 숫자, 언더스코어( _ ), 점(.), 하이픈(-)으로 구성된 도메인명이 옵고 그 후 점(이스케이프된)이 소문자와 점으로 된 2~6개의 문자열이 옵니다. 2~6개로 한 이유는 .co.kr이나 .ny.us같은 국가 TLD(Top-Level-Domain)때문이며 마지막으로 문자열의 끝($)인 옵니다.

Match되는 스트링 : john@doe.com
Match되지 않는 문자열 : john@doe.something (TLS가 너무 김)

Matching a URL

view plain print ?

// Pattern
/^(https?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?$/





// Pattern
/^(https?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?$/

이 정규표현식은 위에 나온 정규표현식의 최종본이라고 할 수 있습니다.

첫번째 그룹은 모두 옵션인데 이것은 URL이 "http://"나 "https://" 또는 둘다 없이 시작하도록 한다. s뒤에 물음표(?)는 URL이 http와 https를 모두 허용한다. 이 그룹전체를 선택사항으로 하기 위해서 뒤에 물음표(?)를 추가했습니다.

다 음은 도메인명으로 한개이상의 숫자, 문자열, 점(.), 하이픈(-)뒤에 또다른 점(.)이 오고 그 뒤에 2~6개의 문자와 점이 옵니다. 이어지는 부분을 추가적인 파일과 디텍토리에 대한 부분으로 이 그룹에서는 갯수에 관계없이 슬래쉬(/), 문자, 숫자, 언더스코어(_), 스페이스, 점(.), 하이픈(-)이 나올 수 있으며 이 그룹은 많은 수의 디렉토리와 파일과 매치됩니다. 물음표(?)대신 별표(*)를 사용한 것은 별표는 0 또는 1이 아닌 0 또는 1개이상을 의미하기 때문입니다. 만약 물음표(?)를 사용했다면 오직 한개의 파일/디렉토리만 매치될 수 있었을 것입니다.

그 뒤에 슬래시(/) 매치되지만 이것은 선택사항이며 마지막으로 문자열의 끝($)이 나타납니다.

Match되는 스트링 : http://net.tutsplus.com/about
Match되지 않는 문자열 : http://google.com/some/file!.html (느낌표가 포함되어 있음)

Matching an IP Address

view plain print ?

// Pattern
/^(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$/






// Pattern

/^(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$/

자, 저는 거짓말을 하지 않습니다. 이 정규표현식은 제가(Vasili) 작성하지 않았고 이곳

에서 가져왔습니다.

정 규식이 첫번째로 잡아낸 그룹은 실제로 매치된(captured)된 그룹이 아닙니다. 왜냐하면 ?: 가 그안에 위치하고 있기 때문입니다. ?:는 파서가 이 그룹을 잡아내지 않도록 합니다. 또한 이 잡히지 않는 그룹은 3번 반복되기를 원합니다.(그룹의 끝에 {3}) 이 그룹은 또다른 서브그룹과 점(.)을 담고 있고 파서는 점(.)이 뒤에 있는 서브그룹을 매치하려고 찾습니다.

서브그룹은 또다른 잡히지 않는(non-captured) 그룹입니다. 이것은 0~5가 뒤에 오는 "25"거나 0~4와 모든 숫자가 뒤에 오는 "2"이거나 옵션이 0 또는 2개의 숫자가 이어지는 숫자들의 문자셋의 묶음입니다.

이 3가지가 매치된 이후에 다음 캡쳐되지 않는 그룹으로 들어갑니다. 이것은 0~5가 이어지는 "25" 또는 0~4와 함께 오는 "2" 그리고 마지막에 다른 숫자(0이나 두자리 숫자)가 옵니다.

마지막 문자($)와 함께 이 복잡한 정규표현식이 끝납니다.

Match되는 스트링 : 73.60.124.136
Match되지 않는 문자열 : 256.60.124.136 (첫번째 숫자는 250~255이어야 함)

Matching an HTML Tag

view plain print ?

// Pattern
/^<([a-z]+)([^<]+)*(?:>(.*)<\/\1>|\s+\/>)$/







// Pattern
/^<([a-z]+)([^<]+)*(?:>(.*)<\/\1>|\s+\/>)$/

이 포스팅에서 가장 유용한 정규표현식 중의 하나입니다. 이것은 어떤 HTML태그도 매치할 수 있고 일반적으로 라인의 첫번째에서 시작합니다.

첫 번째로 오는 것은 태그이름입니다. 이것은 반드시 한개이상의 문자가 되어야 하며 첫번째로 잡히는 그룹이기도 합니다. 이것은 닫는태그를 잡았을 때 찾아야 할 값입니다. 다음에는 태그의 속성입니다. 이것은 >를 제외한 어떤 문자도 올 수 있습니다. 옵션사항이지만 1개이상의 캐릭터와 매치되기를 원하기 때문에 별표가 사용되었습니다. 플러스기호는 속성과 값을 이루고 별표는 원하는 만큼의 속성(attribute)가 매치될 수 있도록 합니다.

다음으로 세번째 non-capture그룹이 오는데 내부에 >기호가 담길 것이고 컨텐츠부분과 닫는태그가 있습니다.(공백과 슬래시(/), > 기호) 첫옵션은 문자들에 이어지는 >기호를 찾습니다. \1은 캡쳐된 첫번째 그룹에서의 내용을 표현하는데 사용됩니다. 이 경우에는 태그의 이름이 됩니다. 이제 태그이름이 매치되지 않으면 자신의 닫는태그를 찾기를 원합니다. 이것은 "/>"가 이어지는 한개이상의 공백이 필요합니다.

Match되는 스트링 : <a href="http://net.tutsplus.com/">Nettuts+</a>
Match되지 않는 문자열 : <img src="img.jpg" alt="My image>" /> (속성은 >기호를 가질 수 없음)

내용은 아주 좋은데 급하게 작성했더니 번역이 영 그렇네요. 원문가서 보시길....(은근슬쩍 급하게 해서 번역이 이런 척... ㄷㄷㄷ)

2009년 12월 19일 토요일

2009년 12월 16일 수요일

2009년 12월 3일 목요일

2009년 11월 28일 토요일

■[Seasar2]S2Fisshplateを使ってみる 17:08

そもそもFisshplateって何じゃらホイ？

埋め込みデータ

テンプレート式

独自タグ（テンプレート式）

S2Fisshplate

何となく思った事

2009년 11월 27일 금요일

既存の日本語文字コードと Unicode の間のマッピングルール

目次

はじめに

関連リンク

関連雑誌記事

参考文献

Unicode-1.1 : ASCII <-> Unicode

Unicode-1.1 : JISX0201, JISX0208, JISX0212 <-> Unicode

日本語 EUC の問題

JISX0221-JISX0201

JISX0221-ASCII

Windows における変換

Sun の JDK における変換

mule-ucs における変換

Be-OS における変換

ベンダ定義文字の問題

JIS エンコーディングの問題

JIS エンコーディングにも対応した変換

半角/全角の問題

その他の問題

Qt-2.0 のサポート状況

感想

ソースコード

2009년 11월 18일 수요일