[動作確認]の検索結果

＋ 

A [Perl]UTF-8でエンコードされた文字の文字コードを表示するプログラム

－ 

A [Perl]UTF-8でエンコードされた文字の文字コードを表示するプログラム

Unicodeの文字コード表によるとUTF-8の半角英数、全角英数、半角カナ、全角カナの文字コードは以下のようになるようです。英数字の場合は半角と全角の文字がそれぞれ対応していますが、カタカナの場合は半角と全角で...

Unicodeの文字コード表によるとUTF-8の半角英数、全角英数、半角カナ、全角カナの文字コードは以下のようになるようです。 英数字の場合は半角と全角の文字がそれぞれ対応していますが、カタカナの場合は半角と全角では文字の数が違うようです。

半角数字:0 - 9
30 - 39

全角数字
EFBC90 - EFBC99
2バイト目まではEFBC

半角アルファベット大文字:A - Z
41 - 5A

全角アルファベット大文字:Ａ - Ｚ
EFBCA1 - EFBCBA
2バイト目まではEFBC

半角アルファベット小文字:a - z
61 - 7A

全角アルファベット小文字:ａ - ｚ
EFBD80 - EFBD9A
2バイト目まではEFBD

半角カナ（JISカナ）
EFBDA1 - EFBE9F
1バイト目がEFで2バイト目、3バイト目がBDA1 - BE9Fの範囲

全角カタカナ
E38299 - E383BF
1バイト目がE3で2バイト目、3バイト目が82A1 - 83BFの範囲

Unicode対応 文字コード表
http://ash.jp/code/unitbl1.htm
http://ash.jp/code/unitbl21.htm

動作確認用にまずUTF-8の文字コードを表示するプログラムを作成します。

#!/usr/bin/perl

use strict;
use warnings;
use Encode;

my $hanAlnum = "ABCDE12345abcde";
my $zenAlnum = "ＡＢＣＤＥ１２３４５ａｂｃｄｅ";
my $hanKana = "ｱｲｳｴｵ";
my $zenKana = "アイウエオ";

print_charcode($hanAlnum);
print "\n";

print_charcode($zenAlnum);
print "\n";

print_charcode($hanKana);
print "\n";

print_charcode($zenKana);
print "\n";

# UTF-8でエンコードされた文字列の文字コードを表示する
sub print_charcode {
    my ($src) = @_;

    my $srclen = length($src);
    my $pos = 0;

    while ($pos < $srclen) {
        my $code = ord substr($src, $pos, 1); # 先頭のASCIIコード値を取得
        my $bytelen = _bytesize($code);
        my $srcchar = substr($src, $pos, $bytelen);
        my $codestr = sprintf("%2.2X ", $code);
        if ($bytelen > 1) {
            my $times = $bytelen - 1;
            for my $i (1 .. $times) {
                my $charcode = ord substr($src, $pos + $i, 1);
                $codestr .= sprintf("%2.2X ", $charcode);
            }
        }

        # Windowsで表示するのでcp932（シフトJIS）に変換
        Encode::from_to($srcchar, 'utf8', 'cp932');
        print "$srcchar : $codestr\n";
        $pos += $bytelen;
    }
}

# 文字のバイト長を求める
sub _bytesize {
    my $code = shift;
    my $size = 1;
    if (0x80 & $code) { # 1バイト文字以外
        $code <<= 1;
        for my $i (2 .. 8) {
            $size++;
            $code <<= 1;
            last if (!(0x80 & $code));
        }
    }
    return $size;
}

Perl Hacks ―プロが教えるテクニック & ツール101選
オライリー・ジャパン 著者：chromatic,Damian Conway,Curtis "Ovid" Poe

amazon.co.jpのカスタマーレビューを見る
powered by amalink

[2248] Posted by kagahiro at 2012/12/17 00:25:00
0 point | Link (1) | Trackback (0) | Comment (0)

＋ 

A 携帯端末に対応したつもり（閲覧、コメント投稿のみ）

－ 

A 携帯端末に対応したつもり（閲覧、コメント投稿のみ）

語句ログを携帯端末からも閲覧、コメント投稿ができるようしました。ただし、エミュレーターでしか動作確認してないので、どんな携帯電話から見れるという保証はないです。語句ログ 携帯版

語句ログを携帯端末からも閲覧、コメント投稿ができるようしました。

ただし、エミュレーターでしか動作確認してないので、どんな携帯電話から見れるという保証はないです。

語句ログ 携帯版

[1860] Posted by kagahiro at 2010/05/11 10:00:33
1 point | Link (2) | Trackback (0) | Comment (1)

＋ 

A 「heteml（ヘテムル）」で59Trackerが動作するか調べてみました

－ 

A 「heteml（ヘテムル）」で59Trackerが動作するか調べてみました

59Trackerが、paperboy&co.のレンタルサーバー「heteml（ヘテムル）」でエラーになるという情報があったので、無料のお試しで借りてチェックしてみました。＞新規投稿、再構築、Ping設定 で、500 errorが表示されます...

59Trackerが、paperboy&co.のレンタルサーバー「heteml（ヘテムル）」でエラーになるという情報があったので、無料のお試しで借りてチェックしてみました。

＞新規投稿、再構築、Ping設定 で、500 errorが表示されます。
＞ブックマークで登録後にエラーが表示されるんですが、投稿自体は完了しています。
＞サーバーはhetemlというところを利用しています。

とりあえず、Perlのバージョンチェック。マニュアルには5.8.0と書いてあるけど、中身は5.8.5らしい。まあ、十分新しいといえるバージョンですね。

59Tracker 3.2のリリース版をインストールして、CGI のパーミッションをheteml指定の700に変更。

情報通り新規投稿、Ping設定で500 errorになることを確認。

使えるモジュールの中に、SOAP-Liteがなかったので、以下の手順を実行。

59Tracker3_1_spec.txt

SOAP-Liteがインストールされていない場合は、http://search.cpan.org/~byrne/SOAP-Lite-0.60a/ から、
SOAP-Lite-0.60a.tar.gzををダウンロードし、任意のディレクトリで解凍します。解凍されたディレクトリ中の
SOAP、 XMLRPCディレクトリをFTPソフトを使用して59bbsが動作するディレクトリにアップロード(転送モード：アスキー、
無変換)します。

これで動くようです。ロリポップで挫折して以来、paperboy&co.のサーバーはチェックしてませんでしたが、hetemlで動かせるということがわかったのはちょっとした収穫です。

それはそうとhetemlはヘテムルって読むんですね。ずっと、ヘムテルだと勘違いしてました。

[1656] Posted by kagahiro at 2009/10/26 14:58:54
0 point | Link (2) | Trackback (0) | Comment (0)

＋ 

A デバッグを効率的に行なうための９の心得

－ 

A デバッグを効率的に行なうための９の心得

バグのないソフトウェアはない、というくらいソフトウェアにはバグがつきものですが、ソフトウェアの開発プロジェクトには期間や予算に上限があるため、バグの修正に手間取ると十分なテストを実施することができず、...

バグのないソフトウェアはない、というくらいソフトウェアにはバグがつきものですが、ソフトウェアの開発プロジェクトには期間や予算に上限があるため、バグの修正に手間取ると十分なテストを実施することができず、品質が低い状態でリリースされてしまうことになります。テストを円滑に進めソフトウェアの品質の高めていくためには、バグを迅速かつ正確にバグを修正していく必要があります。

しかし、オブジェクト指向プログラミング（OOP）やデザインパターンなどプログラムの作り方についての解説書や記事はたくさんあるにも関わらず、「バグは本来あってはいけないもの、あるはずが無いもの」という意識があるためか、デバッグに関して語られている情報源はあまり多くありません。そのため、デバッグのテクニックについてはせいぜい「開発現
場の先輩に教えてもらう」というのが実情です。

知識を共有するために、私がこれまでのソフトウェア開発の経験から得た、デバッグを効率的に行なうための心得をいくつか挙げてみたいと思います。

1. バグの原因は自分が作っているプログラムにある可能性が最も高い
ソフトウェアを構成する要素として、OS、開発ツールに付属するライブラリ、市販ライブラリ、プロジェクト内で作成されたライブラリなどがありますが、バグの原因は自分が作っているプログラムである可能性が最も高いと考えたほうがすばやくバグを見つけられます。なぜなら、今まさに開発が行なわれているプログラムこそが最もテストされていないプログラムだからです。問題の原因をマイクロソフトのせいにする前に自分のプログラムを調べましょう。

2. テストの実施を妨げているバグを優先する
当然のことですが、テストができなければバグを見つけることができません。効率的にバグが発見できるように、めったに行なわれない操作によって発生するバグよりも、必ず行なわれる操作で発生するバグを優先的に修正していく必要があります。

3. 問題を確実に再現できるようする
問題が発生する条件（操作手順、データなど）を必ず特定しなければなりません。これができないと動作確認は不可能ですので、修正したつもりが実は直ってなかったという事態にもなりかねません。この作業自体はソースコードがなくても可能なので、テスト担当者の協力を得られるのであれば、情報を交換しながらテスト担当者と開発担当者が並行して調査を進めるのが良いでしょう。

4. 一度でも問題が発生した場合はバグがある可能が高いので必ず調査する
一度でも問題が発生した場合は、単にバグが発現する条件がわかっていないだけで、必ずどこかにバグがあります。開発作業中はいろいろプレッシャーがあるので難しい面もありますが、見つけた時点で調査しておいた方がいろんな面で良いでしょう。

5. ソースコードを見ただけで正しい処理が行なわれていると判断しない
プログラムはプログラマが思っている通りに動くのではなくコンパイラが解釈した通りに動くものです。コンパイラについての知識が豊富なプログラマが犯しがち問題ですが、プログラマがコンパイラの仕様について誤解しているために生じるバグもよくあります。プログラマ自身は正しいと思っているためソースコードを見ただけではバグを発見することが困難ですがが、このようなバグは実際にプログラムを動かしてみることで簡単に原因を発見することがきます。

6. 想定外の操作や想定外のデータが使用されていないかチェックする
プログラムはプログラマが想定していなかった操作が行なわれたり、想定外のデータが入力されたりした場合は正しく動作しないことが多いものです。問題を発生させる操作やデータがプログラムで想定されているかチェックしてみましょう。

7. バグの原因となっているソースコードは必ず特定する
関係の無いところを直しても問題の現象が発生しなくなる場合もありますが、それでバグが無くなったわけではありません。そのような場合は、また別のところで別のかたちで問題が発生することになりかねません。バグは必ずソースコードレベルで原因を特定し確実に修正すべきです。

8. できるだけ他の処理に影響を与えないようにソースコードを修正する
他の処理に影響を与えるような修正を行なった場合、これまで問題なく動いていた部分に新たなバグを埋め込んでしまう可能性が高いものです。別の問題を引き起こさないように、影響範囲に注意してソースコードを修正します。しかし、単なるコーディング上の間違いであればプログラムの修正は比較的簡単で他の処理に影響を与えることは少ないのすが、設計に問題がある場合は他の部分の影響を与えないようにバグ修正を行なうのが難しい場合があります。そのような場合は、本質的な問題の解決にはならないとしても、影響範囲を限定するために暫定的な対処を行なった方が良いでしょう。

9. ソースコードを修正した場合は必ずテストする
たとえ簡単な修正であっても間違った修正を行なう可能性は常にあります。また、修正が思わぬところに影響を与えることもあります。当たり前ですが、ソースコードを修正した場合は必ずテストを行ないましょう。テスト作業を手を抜くよりも、テストを行なった方がトータル見れば開発者自身にとっても負担が少ないはずです。

[1067] Posted by kagahiro at 2007/09/10 05:49:45
1 point | Link (3) | Trackback (0) | Comment (1)