ショック。 やっぱり自分で使うライブラリは、ソースコード全部把握してから使わなきゃダメね。 正規表現では+や*とかを使って、ものすごく長い範囲にヒットさせる事が出来るわけだが、 TRegExpで、ものすごく長い文字列にヒットさせようとすると、 オーバーフローが起こって何の警告も出さずにアプリが落ちる事がわかった。 たぶんさ、足し算とか引き算とかで桁があふれた場合は警告出るんだろうね。 今回のオーバーフローは、正規表現ライブラリ内のとある…続きを読む

出来れば自分で書きたくないので、利用できる物を探してみるのだが、 Delphiであると言うことがどうしても足かせになる。 .NETの正規表現が逆方向も検索できて大変よろしいのだがな。 ともかく、Delphiってのはユニコードがない時代に作られたものなので、 Delphi向けの正規表現といえばSJISしか検索できないとか日本語ダメとかで、 逆にユニコードの検索が出来るとDelphiから利用できなかったりで、 Delphiかつユニコードな正…続きを読む

ずっと仕様だからしょうがないとか思ってあきらめてた部分は多々あるわけだが、 その仕様だからってのは、仕様じゃなくすることは出来るけど面倒すぎるって事ばかり。 で、たまたまやる気が持続したので、仕様を打破する更新とか続いたわけだ。 もうさ、不満があったら面倒でも修正しちゃうって流れに完全にシフトしちゃったんだけど、 知識不足でどうしても手が出せないのが正規表現部分。 真魚は作者と嫁が使うために作られた物であり、 作者も嫁もよくわかっていな…続きを読む

本当に、見えないところの変更はいっぱいやってるんだが、 それを変更したからって全然ありがたくないようなことばかりなんだよね。 バグは結構あって、気がつき次第直しているんだが、 そのほとんどは、作者だからこそ意図してない動作に気がついているが、 よその人が使う分には仕様かと思ってしまうようなくだらないことで、 だからこそ指摘されて直すのではなく、自分で気がついてばかりいる。 いくら真魚なんて使っている人がほとんどいないっていっても、 わか…続きを読む

折り返しに関してアレコレとやってたら、深みにはまりつつある。 まず、動作確認中にバグを一つ見つけた。 小さい「っ」とか「ゃ」を行頭におけないっていう禁則が動いてなかった。 コレは単に内部で間違って逆の処理をしてただけなので、修正は1秒で終わった。 それは別に良い。 今悩んでいるのは、アポストロフィだ。 そもそも、一つの文字につき、決めなきゃいけないことがどれだけあるかと言うと、 ○色分けで何扱いするか ○折り返すときに切れる場所か ○単…続きを読む

これもSJISのエディタでは特に考えなくてもいい話だ。 アルファベットが連続していたら、その途中で折り返したらいけないってだけ。 その際、どれがアルファベットの文字なのかってのは単純なんだよね。 SJISには半角と全角のアルファベットがあり、 半角のアルファベットは途中で折り返しちゃいけなくて、全角は折り返し出来る。 そもそも全角のアルファベットはSJISの文書では使えるけど、ASCIIでは使えない。 だから、全角の文字は日本語流の折り…続きを読む

なんか、更新した場所がたくさんあるので、ここらでいったん出しておく。 結構燃え尽きてるので次があるかはわからないが。 前回の2.08ではEmEditorフリー版に影響を受けた部分が多少あったわけだが、 今回は萌ディタの開発日記に影響を受けた部分がいっぱいある。 やっぱりユニコードでプロポーショナル対応なエディタは参考になるな。 SJISのエディタだと参考にしなくてもTEditorのソース読めばいいからね。 TEditorを研究してパクり…続きを読む

JIS/EUC変換読み書き部分を作り直し、今まで対応してなかった文字に対応したので、 文字コード自動判定部分も、新たに対応した領域を使いたい。 jconvert.pasは結構古いものなので、 JIS、EUCを検出することは出来ても、UTF-8やUTF-7を自動判定することは出来ず、 真魚では、まずjconvert.pasの判定もして、 しかも自前で書いたUTF-7とUTF-8の判定をもするという形をとっているわけだが、 全部まとめて1p…続きを読む

なんか文字コードに躍起になっているが、もともと萌ディタの開発日記が発端である。 http://www.geocities.co.jp/SiliconValley-Oakland/3617/progress_2004Q2.html EUCはSJISにない文字も扱える仕様に変更済み。 次にJISなんだが、そこに書いてあるようにいろいろあるわけだが、 読み込みについてはどんな実装をするか悩まずに出来た。 EUC変換のために作ったテーブルを使っ…続きを読む

EUCへの対応については、補助漢字領域の拡張を目的に進めてきた。 すなわち、旧来のSJIS変換を行うとEUCにしかない文字が失われてしまうので、 SJISを介さずにEUC＜-＞ユニコード変換を行うように仕様変更だ。 それはもうできあがったからそれで良い。 次にJISへの対応をどうするかという話だ。 JISは多くの拡張がなされているため、全てに対応すれば中韓国語も扱えるはずだ。 だが、中韓国語拡張したJIS文字コードはどこで利用されるのか…続きを読む

ようやく満足のいくEUC対応ができあがったようだ。 が、乗りかかった船なのでもうちょっと調べている。 http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/kanjibukuro/japan.html これのEUC-JPとShift_JISのところに、ちょっと納得いくことが書いてあった。 ＞いずれを使うかは、使う人の自由にまかされます。 なるほどな。 DelphiアプリでのEUC変換は、jconvert.…続きを読む

自体はどんどん複雑化する。 ユニコードの私用領域であるU+E000辺り以降が、SJISやJISへ変換出来ると言うことを、 ATOKの文字パレットで確認したが、JISの規格では使われていない、 0x7F21から0x927Eまでが割り当てられているようだ。 EUCでは、JISでの0x2121～0x7E7Eに0x8080を加えた、0xA1A1～0xFEFEを使っているので、 規格をはみ出して私用領域を割り当てようとすると桁があふれてしまうのだ…続きを読む

JISX0212の補助漢字領域の資料が正しいかどうかはわからないが、 JISX0208の第一水準、第二水準漢字領域については、 資料には不備が多すぎて使い物にならなかったと言うことで、 CP50220を使って、OSにJISX0208領域を実際に変換させてテーブルを作成させた。 そしたら、CP20932を使ったときと同様、それと同じ文字で問題があった。 これも、SJIS経由での変換とは多少違った物を作ってしまった。 いや、多少かどうかは知…続きを読む

二つの方法がダメになった。 ○SJISを経由すると補助漢字が失われる。 ○CP20932でもうまくいかない。 で、最後の方法として、 ○アプリが変換テーブルをもつ。 コレをやるにあたり、 http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/ にあるテキストファイルを使用した。 矩形選択と正規表現置換で、完璧にDelphiコードに変換できた。 そして実際に正しい変換が出…続きを読む

日本語文字コードって、WindowsではSJIS、UnixではEUCということだが、 インターネットが普及したおかげで、EUCをWindowsで扱う機会も増えてきたということだが、 EUCにはあってSJISにはない文字っていうのもあるってことを、萌ディタの開発日記で知った。 旧来のSJISのテキストエディタでは、SJISにない文字なんだから編集出来なくて当たり前で、 ”EUC対応”って書いていても特定の文字は変換できなくて切り捨ててきた…続きを読む