Windows 7 Enterprise 90日間評価版が公開されています。
ソフトウェアの動作検証にどうぞ。
提供数に上限があるそうなので、気になるなら早めにダウンロードしておくといいでしょう。
Ruby on Railsを使うならバージョン2.2以上を使おう。
バージョン2.1以下は、セキュリティホールが放置されている。
いずれも、バージョン2.3.4と2.2.3で修正されている。
XSS Vulnerability in Ruby on Rails
対象はRuby on Railsのバージョン2.0.0以降
Timing Weakness in Ruby on Rails
対象はRuby on Railsのバージョン2.1.0以降
とはいっても、バージョン間での互換性が低いのがRuby on Railsの特徴。
既存のシステムのバージョンアップも楽ではない。
第14回エンバカデロ・デベロッパーキャンプセッションT7自己フォロー(グリッドの特定列をボタンにする)より。
ボタンを上手に使っているところが参考になります。
TButtonにイベント処理を任せることで、描画処理がシンプルになっています。
実際にはもう少しコードが加わるとは思いますが。
ちなみに私も、コンポーネントを作成しない派です。
以前に使っていたフリーのコンポーネントが、IDEをバージョンアップしたら、インストールできなくなったことがあります。
当時のコンパイラに不具合があって、DelphiのコードをC++Builder用に変換するときにエラーになったのだと思います。
C++Builderは、DelphiのコードをC++Builder用に変換する作業が加わるため、Delphiよりもトラブルに遭遇する確率が高いと思います。
そのため、C++BuilderユーザーはDelphiユーザーよりも、
コンポーネントのインストールに抵抗があるのかもしれません。
# 私だけかもしれませんが。
ちょっと気になった点があります。
// テーマサービスの取得
TThemeServices* pTheme = ThemeServices();
if (pTheme) {
// テーマが有効
とありますが、Themes.pasを見ると、ThemeServices()は常に有効なオブジェクトを返すようです。
function ThemeServices: TThemeServices;
begin
if InternalServices = nil then
InternalServices := ThemeServicesClass.Create;
Result := InternalServices;
end;
テーマ (視覚スタイル) を使用しているかどうかを調べるには、 TThemeServicesのThemesEnabledプロパティを使った方がいいような気がします。
先日、久しぶりにFAXを送りました。
データをプリンタで印刷して、コンビニに行って、50円でFAXを送信。
送信費も高いと感じましたが、それ以上に費やした時間がもったいない。
インターネットFAXなら、パソコンから直接FAXを送信することができます。
FAXを利用する機会が少ないことから、インターネットを使ったFAX送信サービスを 「初期費用0円、月額料金0円」のサービスに限定して、調べてみました。
他のサービスと比較しても、とにかく安い。
月々513.52円のプロフェッショナルプランに加入するとFAXの受信もできる。
今回調べた中では一番良さそう。
BIGLOBEサービス会員限定だが、初期費用・月額基本料無料のBIGLOBEコンテンツサービスを利用すると、BIGLOBE以外のプロバイダを使用していても利用可能。
法人契約のみ。
CSV Mailer バージョン0.5.7を公開しました。
今回のバージョンアップでは、ご要望をいただいたパスワードを暗号化して保存する機能を実装しました。
バージョン0.5.7で作成した設定ファイルを、古いバージョンのCSV Mailerで開くと、パスワードを正しく読み込めませんので、ご注意下さい。
ご意見、ご感想、ご要望をお待ちしています。
C++Builder 2009で確認したところ、UnicodeStringをJISコードに変換すると文字が減るようだ。
//UTF-8
AnsiStringT<65001> utf8 = L"文字コード"; //=> 文字コード
//Shift_JIS
AnsiStringT<932> sjis = L"文字コード"; //=> 文字コード
//EUC_JP
AnsiStringT<20932> euc = L"文字コード"; //=> 文字コード
//x-mac-japanese
AnsiStringT<10001> mac = L"文字コード"; //=> 文字コード
//JISコードの時は文字が減る
//iso-2022-jp(JIS)
AnsiStringT<50220> jis1 = L"文字コード"; //=> 文字コ
//csISO2022JP (JIS 1 バイト カタカナ可)
AnsiStringT<50220> jis2 = L"文字コード"; //=> 文字コ
//iso-2022-jp (JIS 1 バイト カタカナ可 - SO/SI)
AnsiStringT<50220> jis3 = L"文字コード"; //=> 文字コ
どうやらマルチバイト文字が混ざると問題になるみたい。
AnsiStringT<50220> jis1 = L"12345";
UnicodeString s1 = jis1; //12345
AnsiStringT<50220> jis2 = L"abc";
UnicodeString s2 = jis2; //abc
AnsiStringT<50220> jis3 = L"あいう";
UnicodeString s3 = jis3; //あ
もう少し調べてみたい。
追記
C++Builder 2009で確認しました。
前回のUnicodeStringをJIS(ISO-2022-JP)に変換すると文字が減るの続き。
UnicodeStringをJISコードに変換すると文字が減るという問題です。
AnsiStringT<50220> jis1 = L"文字コード"; //=> 文字コ
Windows 2000におけるWin32APIのWideCharToMultiByte関数の動作がおかしいようです。
WideCharToMultiByte関数は、ISO-2022-JPに変換したときの正しいバイト数を返しません。
なお、Windows XP以降では問題ありませんでした。
次のソースコードは、ユニコード文字列をJIS(ISO-2022-JP)コードに変換したときのバイト数を取得する処理です。
const int codepage = 50220;
UnicodeString WCharSource = L"abcテスト";
int SrcChars = WCharSource.Length();
int DestBytes = WideCharToMultiByte(codepage, 0, WCharSource.c_str(), SrcChars, NULL, 0, NULL, NULL);
WideCharToMultiByte関数は、変換後の文字列を受け取るために必要なバッファのサイズ(バイト数)を返します。
上のコードでは12バイト必要ですが、この関数は「9」を返します。3バイト足りません。
3バイトというと、エスケープシーケンスが思い当たります。
JISコードではエスケープシーケンスを用いて、文字集合を切り替えます。
エスケープシーケンスの計算が正しいか試してみました。
const int codepage = 50222;
UnicodeString WCharSource = L"abcテストabc";
int SrcChars = WCharSource.Length();
int DestBytes = WideCharToMultiByte(codepage, 0, WCharSource.c_str(), SrcChars, NULL, 0, NULL, NULL);
WideCharToMultiByte関数は「12」を返します。6バイト足りません。
const int codepage = 50220;
UnicodeString WCharSource = L"abcテストabcテスト";
int SrcChars = WCharSource.Length();
int DestBytes = WideCharToMultiByte(codepage, 0, WCharSource.c_str(), SrcChars, NULL, 0, NULL, NULL);
WideCharToMultiByte関数は「18」を返します。9バイト足りません。
やはりエスケープシーケンスが考慮されていないようです。
原因がわかりましたので、対策も簡単です。
Windows2000でISO-2022-JPに変換するときはバッファを多めにとればいいのです。
さて、問題のUnicodeStringからAnsiStringT<50220>への変換ですが、
System.pasの_LStrFromPWCharLen関数かCharFromWChar関数で、
文字のバイト数を取得するときに、
OSがWindows2000かつコードページが50220ならば、
バッファのバイト数を増やして文字を取得し、取得後に不要な部分を切り捨てればいいと思います。
とても汚いコードになりそうです。
調べてみると、同じような問題に遭遇している方がいらっしゃいました。
「komatの古往今来: ALM2Thunderbird 1.0の動作OSについて」では、Windows 2000環境で変換に失敗するという問題に遭遇されています。
「Windows API関数のWideCharToMultiByteとMultiByteToWideCharの動作に問題がある」とありますが、おそらく同じ問題でしょう。
前回の記事「Windows 2000でWideCharToMultiByte関数を使うと、ISO-2022-JPのバイト数を間違う」では、 Windows 2000におけるWideCharToMultiByte関数の問題を調べました。
今回はWideCharToMultiByte関数のWindows XPでの問題です。
次のようにユニコード文字列をISO-2022-JPに変換した場合、
AnsiStringT<50220> jis = L"abcあいう";
Windows XPでは変数jisのバイトコードは「abc<ESC>あいう」のようになります。
<ESC>はエスケープシーケンスを表しています。
なお、Windows 7では「abc<ESC>あいう<ESC>」のようになります。
※UnicodeStringからAnsiStringTへの変換は、内部でWideCharToMultiByte関数を使用しています。
これが問題になるのは次のようなコードの時です。
AnsiStringT<50220> jis = L"abcあいう";
AnsiStringT<50220> jis2 = jis + jis;
Windows XPでは変数jis2のバイトコードは「abc<ESC>あいうabc<ESC>あいう」のようになってしまいます。
「あいうabc」の間に<ESC>がないため、文字化けが発生します。
なお、Windows 7では「abc<ESC>あいう<ESC>abc<ESC>あいう<ESC>」となり問題は発生しません。
Windows XPでも、WideCharToMultiByte関数を使ってISO-2022-JPに変換するときには注意が必要です。
今回のコードは、C++Builder2010で確認しました。
C++Builder 2010のTIdMessageは、プロパティのCharSetとContentTransferEncodingから、適切に文字コードを変換してエンコードしてくれるようになった。
これによって、C++Builder 2009のときのように、ISO-2022-JPに変換したバイト列をUnicodeStringに代入するという奇妙なコードが不要になった。
しかし、これによって新たに問題が生じている。
一つはWindows 2000におけるWideCharToMultiByte関数の不具合。
これによって、Windows 2000ではISO-2022-JPに変換した文字は文字化けする。
もう一つは波ダッシュ問題。
WideCharToMultiByte関数による変換では波ダッシュ問題が発生する。
この2つの問題は、Win32APIのWideCharToMultiByte関数が原因なので、Indyの不具合とは言えないと思う。
C++Builder 2009のときには、プログラム側で文字コードを変換しBase64エンコードをしなければならなかった。
一方で、プログラム側でこれらの問題に対応する余地があったとも言える。
C++Builder 2010ではライブラリ側が自動で変換するために、プログラム側では打つ手が見当たらない。
次の問題は、Indyのバグかもしれない。
プロジェクトオプションで、「実行時パッケージを使って構築」のチェックを外すと、
「ERangeError(メッセージ'範囲チェックエラー)」が送出される。
最後に問題が発生するサンプルコードを示す。
std::unique_ptr<TIdMessage> msg(new TIdMessage(NULL));
msg->CharSet = "ISO-2022-JP";
msg->ContentTransferEncoding = "base64";
msg->ContentType = "text/plain; charset=\"ISO-2022-JP\"";
msg->Subject = L"メールの件名"; //=> Windows2000なら件名が消える
msg->Body->Text = L"10~20"; //=> ~が文字化けする
msg->SaveToFile(ChangeFileExt(Application->ExeName, ".eml"), false);
うまい解決策があったら教えて下さい。
D2 メール自動データベース変換ソフト バージョン 2.2.9を公開しました。
今回はOutlookの機能を強化しました。
メールの受信日が取得できるのは面白いと思います。
他にもOutlookのフォルダ選択画面を少しだけ手を加えています。
皆様のご意見、ご要望、バグ報告をお待ちしています。
Outlook Export Tool バージョン0.0.1を公開しました。
Outlook Export Toolは、Outlookのメールを別形式のファイルにエクスポートするソフトウェアです。
Outlookを操作してメール情報を読み取り、eml形式などのOutlookがサポートしていないファイル形式にエクスポートすることができます。
D2のOutlookのメール読み込み機能は、指定したフォルダのメールをすべて読み込みます。
特定のメールだけD2で処理したい場合、Outlookには汎用的な形式にエクスポートできないため、Outlookのメールを他のメールソフトにエクスポートして、そのメールソフトから汎用的な形式にエクスポートする必要がありました。
Outlook Export Toolでは任意のメールをeml形式にエクスポートできますので、D2がより使いやすくなると思います。
eml形式のエクスポートはすべての情報を出力するわけではありません。ご注意下さい。
eml形式では次の情報をエクスポートします。
「X-ReceivedTime」は標準のヘッダではありませんが、Outlookから情報を取得することができましたので、独自のヘッダをして出力するようにしました。
D2で処理をするには十分な情報があるとおもいます。
皆様のご意見・ご要望をお待ちしています。
UnicodeStringをJISコードに変換すると「~」が文字化けします。
UnicodeString uni = L"10~20";
AnsiStringT<50220> jis = uni; //=> 「~」が文字化けする
MECSUtils ver1.30で導入されたMecsMappingFixJA関数を使うと、 波ダッシュ問題を回避することができます。
#include "MECSUtils.hpp"
UnicodeString uni = L"10~20";
uni = Mecsutils::MecsMappingFixJA(uni);
AnsiStringT<50220> jis = uni; //=>「10~20」
すばらしい。
ありがとうございました。
追記:
MECSUtils 1.33で関数名が変更されました。
UnicodeStringの波ダッシュ問題の回避策のまとめをご覧下さい。
小規模なWebアプリを作成するのに、CodeIgniterを使用しました。
以前にも同じようなことを書いたような気もしますが、
CodeIgniterはやっぱり偉い。
小規模なWebアプリにCodeIgniterが向いている理由
インストールはコピーするだけ
小規模アプリなのに、導入コストが高いなんてあり得ない。
安価なレンタルサーバでも動作可能
小規模アプリなので、サーバにお金はかけられない。
シンプルな作りで学習コストが低い
小規模アプリなのに、学習時間が長いと本末転倒
充実した日本語マニュアル
使い方を学ぶのにお金がかかりません。
CodeIgniter日本語化で日本語環境にも完全対応
安心して使えます。
充実したバリデーション機能
とても便利。開発効率もいい。
付属のユニットテストは簡易だが必要十分
ただし、大規模アプリには辛いかも。
以下、備忘録
バリデーション機能はCodeIgniter日本語化を導入すると、エラーメッセージが日本語になります。
インストール方法は単純にファイルを上書きするだけ。
インストール後はconfig.phpを編集して、languageを"japanese"に修正します。
//$config['language'] = "english";
$config['language'] = "japanese";
メールの送信もCodeIgniter日本語化で日本語に対応できるようです。 使い方はとても簡単。詳細はマニュアルのEmail Classを参照。
$this->load->library('email');
$this->email->from('your@example.com', 'Your Name');
$this->email->to('someone@example.com');
$this->email->cc('another@another-example.com');
$this->email->bcc('them@their-example.com');
$this->email->subject('Email Test');
$this->email->message('Testing the email class.');
$this->email->send();
//echo $this->email->print_debugger();
バリデーションは便利。使わないと損。
$this->validation->set_error_delimiters()は、$this->validation->run() の前に行うこと。
UnicodeStringをJISやEUC-JPに変換するときの波ダッシュ問題は、 MECSUtilsのMecsMappingFixJA関数を使うことで解決します。
逆にJISやEUC-JPの文字列をUnicodeStringに変換したときの波ダッシュ問題を解決するための関数として、 MecsMappingFixJAの逆の処理をする関数があると便利だと思います。
処理は単純にMecsMappingFixJAの反対の変換を行えば良さそうでした。
JISやEUC-JPの文字列をUnicodeStringに変換した後、この関数を使用します。
UnicodeString uni = Mecsutils::AnsiToUTF16(raw, CodePage);
uni = Mecsutils::MecsMappingFixJA2(uni);
MECSUtilsに次の関数を追加します。
//JISやEUC-JPをUnicodeStringに変換したときの波ダッシュ問題を解決する関数
function MecsMappingFixJA2(const S: UnicodeString): UnicodeString; overload;
var
i: Integer;
begin
result := S;
for i:=1 to Length(result) do
case result[i] of
#$2016:
result[i] := #$2225;
#$2212:
result[i] := #$FF0D;
#$301C:
result[i] := #$FF5E;
#$00A2:
result[i] := #$FFE0;
#$00A3:
result[i] := #$FFE1;
#$00AC:
result[i] := #$FFE2;
end;
end;
関数名はもう少し工夫した方がいいでしょう。
追記:
MECSUtils 1.33で導入していただきました。
UnicodeStringの波ダッシュ問題の回避策のまとめをご覧下さい。
CSV Mailer バージョン0.5.8を公開しました。
今回のバージョンアップでは次の変更を行いました。
CSV Mailerは、CSVのデータをメールに差し込んで送信することができるメール一斉送信ソフトです。
データの差し込みの自由度が高く、半角カナを全角に変換する機能など差し込み時のデータ変換の機能もあります。
「POP before SMTP」や「SMTP認証(SMTP Authentication)」にも対応しています。Gmailにも対応しています。
ご意見、ご感想、ご要望をお待ちしています。
RAD Studio 2010 Update 1がリリースされました。
RAD Studio 2010 Update 1 リリースノートによると、今回の修正は
慌ててアップデートする必要はなさそうです。
UnicodeStringをJISやEUC-JPに変換すると「~」が文字化けします。
UnicodeString uni = L"10~20";
AnsiStringT<50220> jis = uni; //=> 「~」が文字化けする
反対に、JISやEUC-JPをUnicodeStringに変換しても「~」が文字化けします。
# ちなみにShift-JISでは文字化けしません。
(修正)Shift-JISでも問題が発生するようです。
この問題を回避する関数がMECSUtilsに用意されています。
MecsMappingFix_UnicodeToJISX0208 関数とMecsMappingFix_JISX0208ToUnicode 関数です。
# MECSUtils ver1.33から関数名が変わりました。
UnicodeStringをJISやEUC-JPに変換するときは、MecsMappingFix_UnicodeToJISX0208 関数を使用してから、変換します。
#include "MECSUtils.hpp"
UnicodeString uni = L"10~20";
uni = Mecsutils::MecsMappingFix_UnicodeToJISX0208(uni);
AnsiStringT<50220> jis = uni; //=>「10~20」
UnicodeStringをShift-JISに変換するときは、MecsMappingFix_UnicodeToCP932 関数を使います。
#include "MECSUtils.hpp"
UnicodeString uni = …
uni = Mecsutils::MecsMappingFix_UnicodeToCP932(uni);
AnsiStringT<932> sjis = uni;
反対に、JISやEUC-JPをUnicodeStringに変換するときは、UnicodeStringに変換してから、MecsMappingFix_JISX0208ToUnicode関数を使用します。
#include "MECSUtils.hpp"
UnicodeString uni = Mecsutils::AnsiToUTF16(raw, CodePage);
uni = Mecsutils::MecsMappingFix_JISX0208ToUnicode(uni);
Shift-JISをUnicodeStringに変換するときは、MecsMappingFix_CP932ToUnicode 関数を使います。
#include "MECSUtils.hpp"
UnicodeString uni = Mecsutils::AnsiToUTF16(raw, CodePage);
uni = Mecsutils::MecsMappingFix_CP932ToUnicode(uni);
各関数についての詳細は、MECSUtils リファレンスに丁寧な説明がありますので、そちらをご覧下さい。
追記
MECSUtils 1.35でCP932(Shift-JIS)用の関数も用意されました。
Shift-JISに関する記述を修正しました。
「DEKOのざつだん。」によると、私が思っていたよりも複雑な問題だったようです。
DEKOさんの丁寧な対応に感謝します。
ブログソフトをMovableTypeからWordpressに変更しました。
RSSのURLが変更になります。
RSSリーダーなどに登録されている方は、変更をお願いします。
あたらしいRSSは次のURLになります。
http://www.gesource.jp/weblog/?feed=rss2
よろしくお願いします。