アーカイブ

タグ: ‘対応’ の記事

世間ではスイカ対応でiPhoneがアップデートだとか言って盛り上がってるようだ。 日常生活で電車に乗ってないし、普段使わないものを常駐させたくない。 使ってないから知らないけど、どうせ使うときはパケット通信も行われるんだろ。 あと買い換えが頻繁なあたしには、変更も面倒臭そう。 いやその変更のために覚えておかなければいけない労力ほどには使わないだろう。 これまではAndroidも使ってたんだから、必要なら使ってただろう。 設定が面倒臭い分…続きを読む

 昨今のパソコンは昔より画面が横長になり、縦に窮屈に感じるようになってきた。だから最近のWindowsでは「メニューバーを隠してAltキーを押したときだけ出す」という方向性にあり、そういうソフトもだいぶ定着してしまった。あたしは最近、FirefoxとSleipnirを比べながら利用しているが、どっちも基本的にメニューは非表示でいけてる。それはFirefoxもSleipnirも、メニューバーの代わりにわかりやすいボタンが一個ウィンドウの左…続きを読む

真魚のプログラムアイコンは、32×32のサイズしか用意していない。 しかし、Windows Vistaでは48×48のサイズのアイコンを要求する。 48×48のアイコンを持っていないプログラムについては、32×32のアイコンを1.5倍して表示する。 別にいいんじゃねーの? 拡大したことによってちょっとはにじんだ感じはするけれども、判別できなくなる訳じゃないし。 他のアプリと間違えない程度に、何でも良いじゃん。 作者はアイコンに何のこだわ…続きを読む

現在、真魚にはPHP用に入力補完の単語リストがあったりするが、 そこに並べられている関数名は、萌ディタの定義ファイル?を丸写ししたもの。 実に649もの関数が、何を参考に並べられたものかは知らないが、とりあえずパクった。 予約語は予約語として定義されてるからわかりやすいのだが、 関数は環境によって使えたり使えなかったりするらしく、どれを候補にするかの基準が欲しい。 試しに、今これを書いてるこのPCで、これの関数一覧取得をやってみた。 h…続きを読む

1512 letters | 586 views | コメントする

その前に、BDS2006が何百MBもメモリー要求してスワップでしょっちゅう作業中断する件。 メモリー買い足せばいいんだろうけど、事務所のはやっかいな位置に取り付けてあって、 他のいろんなものをいちいちバラさないとダメなので面倒でやる気がしない。 何の根拠もないが、おそらくソースに含まれる数百KB分のテーブルデータかなと疑い、 文字コード変換部分をDLL化して、ソースを切り離そうかと画策。 テーブルのデータを受け渡すだけの関数をエクスポー…続きを読む

なんか文字コードに躍起になっているが、もともと萌ディタの開発日記が発端である。 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コードに変換できた。 そして実際に正しい変換が出…続きを読む

一見かなりまともそうだったのだが、いくつかの文字がどうしようもなかったりした。 補助漢字部分の拡張が目的ではあるが、それにより今まで変換できた文字が出来なくなる。 WideCharToMultiByteで、UTF-16からSJISへの変換に成功した文字の内、 UTF-16からEUCへの変換に失敗したのは、「昴」「~」とか14文字だ。 逆にそれらを、MultiByteToWideCharで、EUCからUTF-16に変換すると、 似て非なる…続きを読む

まとめると、EUCをWindowsで扱う方法は三つ。 ○SJISに変換する。 SJISにはない補助漢字領域の文字は全て破棄する事になる。 ○EUC<->UTF16変換テーブルをアプリ内で持つ。 一番やりたいのはこれだが作業がつらい。 ○CP20932を使ってWindowsにやらせる。 本来のEUCでは補助漢字領域を3バイトで表すが、CP20932は2バイトで表す。 この2バイトと3バイトの相互変換が実に簡単な事がわかった。 CP2093…続きを読む

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