FC2ブログ

不動産と株の投資日記

日々の大家業の備忘録

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

5/31の取引

2914 日本たばこ : 前 3460 始 3595 高 +5 安 -145 終 3460
持越200株 3570L → 3595C +5,000円
当日200株 3455L → 3495C +8,000円

4063 信越化学 : 前 6290 始 6480 安 -120 高 +60 終 6470
持越200株 6350L → 6440C +18,000円

5108 ブリヂストン: 前 3325 始 3380 安 -60 高 +65 終 3370
持越200株 3360L → 3390C +6,000円

3382 7&iHD : 前 3495 始 3580 高 +10 安 -100 終 3505
持越200株 3560L → 3565C +1,000円

9983 ファストリテ: 前 33200 始 34600 安 -950 高 +600 終 34900
持越100株 33200L → 34600C +140,000円

9984 ソフトバンク: 前 5090 始 5250 安 -110 高 +60 終 5170
持越200株 5090L → 5150C +12,000円

合計+19万円(手数料含まず)


なんか久しぶりに勝った。今日の牛丼には卵をつけてもいいかな。

信越とソフトバンクは、底売りしちまった、、、反省。



来週6月1週といえば、最後の逃げ場&ドテン売りの急所。
華麗に売り豚に転生できるかな。

しかし、こう信用買残が多いと、寄り天率高すぎ。上値より下値の方が軽そう。
スポンサーサイト

玄関ドアへの督促状の貼り付け

家賃の督促状を玄関ドアに貼り付けようかと思ったら、裁判で負けるらしい、、、
郵便で送っても見るわけないやん、、、
大家って、つくづく社会弱者どす。


(asahi.com2010年5月28日より)
 滞納家賃の支払いを求める督促状を自宅玄関に張られ精神的苦痛を受けたとして,大阪府柏原市の会社員の男性(29)が家賃保証会社に110万円の損害賠償を求めた訴訟の判決が28日,大阪地裁であった。 窪田俊秀裁判官は「家賃の支払い状況はプライバシー情報で,不特定の人に知られる状態にするのは名誉を損ねる違法な取り立てだ」として,保証会社に慰謝料など6万5千円の支払いを命じた。
 消費者金融などの取り立てをめぐっては,貸金業法がこうした張り紙を禁じているが,滞納家賃については規制する法律がない。
 支援団体「全国追い出し屋対策会議」によると,同様の訴訟で,督促状の文言は問わず玄関に張るだけで違法と認めた判決は初めて。
 判決によると,男性は2008年9月分のマンション家賃8万5千円を滞納。保証会社は同月以降,家主に滞納分を立て替えたうえで,男性宅の玄関ドアに督促状を張りつけたほか,電話で「出ていけ」などと退去を要求。男性はその後,家賃を支払った。
 窪田裁判官は「督促状は郵便受けに入れれば足りる」と指摘。 高圧的な口調の取り立てについては「社会通念上の限度を超える」と判断した。
 強引な家賃の取り立てに刑事罰を科すことを盛り込んだ「追い出し規制法(通称)」案は今月25日に衆院国土交通委員会に付託された。先に審理した参院は全会一致で可決しており,6月にも成立する見通しになっている。


5/30 の取引

3382 7&iHD : 前 3685 始 3555 高 +65 安 -80 終 3495
200株 3555L → 3560C +1,000円

4503 アステラス : 前 5430 始 5350 安 -90 高 +150 終 5310
200株 5270L → 5280C +2,000円

9983 ファストリテ: 前 37350 始 35750 高 +350 安-2550 終 33200
200株 35750L → 35850C +20,000円
200株 35050L → 34900C -30,000円

9984 ソフトバンク: 前 5320 始 5350 高 +50 安 -290 終 5090
200株 5160L → 5160C +0円

合計-7,000円(手数料含まず)


予想通りの大暴落なのに、買い向かってるし、、、orz

7&i とアステラスは、逆指狩られました。

ユニクロは、寄りで買ったのと、後場寄り近辺で買ったもの。あまりの弱さに投げました。
後場のは、中途半端な値段でインしてるし、反省。

ソフトバンクは、約定して、ニュース見たらネガティブだったので、即撤退。


明日は月末なので、上がってくれるといいな。

uim-mozc キーバインド変更

サーバーが死んだのを機にそろそろ atok を卒業しようかと。
ていうより、atok が 32bit なので、何かと競合して面倒くさいのでやめたい。
でも、atok 以外のキーバインドはつらい。

ということで標準でインストールされている uim-mozc のキーバインドを変更する。

/usr/share/uim/mozc.scm から読み込まれている
/usr/share/uim/generic-key-custom.scm
/usr/share/uim/mozc-key-custom.scm
を変更すればいいらしい。もしくは、~/.uim

中身はschemeかな。

変換on 全角半角と、Shift+space
変換off 全角半角と、Shift+space
=> は、間違って日本語入力に入ってしまうので消す。 ひとつだけでも list 指定しないといけないっぽい。

うーん、ドキュメントないしギブアップ、、、


調べてると、UimPref というので GUI から設定できるらしい、、、orz
$ uim-pref-gtk


あんまり設定できないな、、、

5/29 の取引

108 ブリヂストン: 前 3440 始 3540 高 +10 安 -110 終 3475
200株 3400L -> 3540C +28,000円

4063 信越化学 : 前 6520 始 6700 高 +30 安 -220 終 6520
200株 6470L -> 6480C +2,000円

8766 東京海上 : 前 3125 始 3180 安 -80 高 +45 終 3155
200株 3180L -> 3190C +2,000円

合計 +32,000円(手数料含まず)

月曜に買った分を処分。

寄り天率が高いブリヂストンは、寄りで処分。

信越は、逆指してたのが狩られた。思いっきり、最安値、、、orz
月曜の引値で買ったので、狩られやすいのはわかってるんだけど、対処方法が思いつかない、、、

東京海上は、高値掴みしてたのを逃げて、安値で買い直し。


なんか、空室の掃除しに行ってる間に日経がダイブしてる、、、
明日は、暴落しやすい木曜日、、、しかも日経はデッドクロス、、、
日経-1000とかやめて欲しい。楽しいけど。

libxml2 お試し その1

Qt を CURL に変更するついでに、htmlcxx でHTML解析していたのを、libxml2 に変更できないか試してみた。

とりあえず、入力して出力するだけのプログラムを作ってみた。

int
main(
int argc,
char *argv[])
{
if ( argc != 2 )
return 1;

htmlDocPtr doc = htmlReadFile(argv[1], "UTF-8", 0);
htmlDocDump(stdout, doc);

return 0;
}


・問題点

- 大量のエラーメッセージ、、、
test.html:263: element a: validity error : ID PAGETOP already defined
test.html:1102: HTML parser error : htmlParseEntityRef: expecting ';'

人のHTMLなんで、変えられないし、しゃあない、、、

- char-set を認識してしまう、、、
iconv で変換してから渡すと、libsml2 が混乱してしまう。

楽しい温泉旅行

なんかね。
家賃の滞納者がね。
刑務所の旦那から家賃のためのお金もらったらしいんだ。
そしたらね。




温泉旅行行ったんだって。

カンマ区切り数値の文字列変換

1,234,567 みたいなカンマ区切りの数値を文字列と相互変換したい。

1. 数値 -> 文字列

いつのまにか printf が対応していた、、、

setlocale(LC_ALL, "");
snprintf(buf, sizeof(buf), "%'d", val);


2. 文字列 -> 数値

scanf の対応に期待したけど、対応してないっぽぃので、自作。

double
strtod_ex(
char *str)
{
double val = 0;
for (char *endptr = str;; endptr++)
{
val += strtod(endptr, &endptr);
if ( *endptr != ',' )
break;
val *= 1000;// 1000倍
}
return val;
}


エラー処理してないので注意!!

gcc4.8 CPU オプション

はじめて gcc 4.8 を使ったので、最近の対応 CPU タイプを調べてみた。

-march=TYPE / -mtune=TYPE で指定可能

-march は、命令セットを使うように指示
-mtune は、指定CPU用に最適化するように指示


CPU名内容
core2MMX, SSE, SSE2, SSE3, SSSE3 対応
corei7 MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1,SSE4.2 対応
corei7-avxMMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AES,PCLMUL 対応
corei7-iMMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AES, PCLMUL, FSGSBASE, RDRND,F16C 対応


/proc/cpuinfo で確認してみたところ、
メインサーバーは、Core i7 980X、AVX に対応してないので、corei7
予備サーバーは、Core i3 2120、AVXに対応しているので、corei7-avx

-march=corei7 -mtune=corei7 を指定することになりそう。

ゴミの分別収集はじまる

今日、ごみ収集業者がきて、2013/10/1 から、紙と衣類が分別になります、って説明にきました。

再生できる紙と、衣類と、それ以外の3種類に分別して、それとわかるようにゴミ置き場に分別場所を作ってほしいらしい。

うちの入居者がそんなん守るわけないやん、、10月は、ゴミとの戦い確定、、、


今日もゴミ置き場に家具が捨てられてあるし、、、防犯カメラで犯人捜しするか、、、月曜の定例行事、、、めんどぃ。

文字コードの変換

取得したHTMLの文字コードを解析を簡単にするために統一する。

文字コードの変換には、iconv と nkf がある。nkf は、入力文字列を自動判定してくれるので便利だけど、ライブラリ化されてないので、プログラムの呼出しをしないといけない。(ソースを組み込めばいいんだけど、ライセンスとかメンテナンスとか、いろいろ問題が、、、)

まずは、charset が正しいことを期待して、iconv を使用する。charset が存在せず、言語が日本語の場合は、popen()でnkf を呼び出す。

iconv に渡す引数は、コマンドラインから確認できる。
$ iconv -l


使用方法は、こんな感じ。
iconv_t cd = iconv_open("UTF-8", "WINDOWS-31J");
iconv(cd, in_buf, in_size, out_buf, out_size);
iconv_close(cd)




simplify 処理

文字コードを変換するのに加えて、simplify 処理をすることで、文字解析を行いやすくする。
この処理では次のことを行う。
- 全角文字を半角文字に変換する。
 (E38080) => (20)
!(EFBC81) => !(21)
”(E2809D) => "(22)
#(EFBC83) => #(23)
$(EFBC84) => $(24)
%(EFBC85) => %(25)
&(EFBC86) => &(26)
’(E28099) => '(27)
((EFBC88) => ((28)
)(EFBC89) => )(29)
*(EFBC8A) => *(2A)
+(EFBC8B) => +(2B)
,(EFBC8C) => ,(2C)
-(EFBC8D) => -(2D)
.(EFBC8E) => .(2E)
/(EFBC8F) => /(2F)
0(EFBC90) => 0(30)
1(EFBC91) => 1(31)
2(EFBC92) => 2(32)
3(EFBC93) => 3(33)
4(EFBC94) => 4(34)
5(EFBC95) => 5(35)
6(EFBC96) => 6(36)
7(EFBC97) => 7(37)
8(EFBC98) => 8(38)
9(EFBC99) => 9(39)
:(EFBC9A) => :(3A)
;(EFBC9B) => ;(3B)
<(EFBC9C) => <(3C)
=(EFBC9D) => =(3D)
>(EFBC9E) => >(3E)
?(EFBC9F) => ?(3F)
@(EFBCA0) => @(40)
A(EFBCA1) => A(41)
B(EFBCA2) => B(42)
C(EFBCA3) => C(43)
D(EFBCA4) => D(44)
E(EFBCA5) => E(45)
F(EFBCA6) => F(46)
G(EFBCA7) => G(47)
H(EFBCA8) => H(48)
I(EFBCA9) => I(49)
J(EFBCAA) => J(4A)
K(EFBCAB) => K(4B)
L(EFBCAC) => L(4C)
M(EFBCAD) => M(4D)
N(EFBCAE) => N(4E)
O(EFBCAF) => O(4F)
P(EFBCB0) => P(50)
Q(EFBCB1) => Q(51)
R(EFBCB2) => R(52)
S(EFBCB3) => S(53)
T(EFBCB4) => T(54)
U(EFBCB5) => U(55)
V(EFBCB6) => V(56)
W(EFBCB7) => W(57)
X(EFBCB8) => X(58)
Y(EFBCB9) => Y(59)
Z(EFBCBA) => Z(5A)
[(EFBCBB) => [(5B)
¥(EFBFA5) => \(5C)
](EFBCBD) => ](5D)
^(EFBCBE) => ^(5E)
_(EFBCBF) => _(5F)
‘(E28098) => `(60)
a(EFBD81) => a(61)
b(EFBD82) => b(62)
c(EFBD83) => c(63)
d(EFBD84) => d(64)
e(EFBD85) => e(65)
f(EFBD86) => f(66)
g(EFBD87) => g(67)
h(EFBD88) => h(68)
i(EFBD89) => i(69)
j(EFBD8A) => j(6A)
k(EFBD8B) => k(6B)
l(EFBD8C) => l(6C)
m(EFBD8D) => m(6D)
n(EFBD8E) => n(6E)
o(EFBD8F) => o(6F)
p(EFBD90) => p(70)
q(EFBD91) => q(71)
r(EFBD92) => r(72)
s(EFBD93) => s(73)
t(EFBD94) => t(74)
u(EFBD95) => u(75)
v(EFBD96) => v(76)
w(EFBD97) => w(77)
x(EFBD98) => x(78)
y(EFBD99) => y(79)
z(EFBD9A) => z(7A)
{(EFBD9B) => {(7B)
|(EFBD9C) => |(7C)
}(EFBD9D) => }(7D)
~(EFBD9E) => ~(7E)

- 半角カタカナは全角カタカナに変換する。
ァ(EFBDA7) => ァ(E382A1)
ア(EFBDB1) => ア(E382A2)
ィ(EFBDA8) => ィ(E382A3)
イ(EFBDB2) => イ(E382A4)
ゥ(EFBDA9) => ゥ(E382A5)
ウ(EFBDB3) => ウ(E382A6)
ェ(EFBDAA) => ェ(E382A7)
エ(EFBDB4) => エ(E382A8)
ォ(EFBDAB) => ォ(E382A9)
オ(EFBDB5) => オ(E382AA)
カ(EFBDB6) => カ(E382AB)
キ(EFBDB7) => キ(E382AD)
ク(EFBDB8) => ク(E382AF)
ケ(EFBDB9) => ケ(E382B1)
コ(EFBDBA) => コ(E382B3)
ガ(EFBDB6EFBE9E) => ガ(E382AC)
ギ(EFBDB7EFBE9E) => ギ(E382AE)
グ(EFBDB8EFBE9E) => グ(E382B0)
ゲ(EFBDB9EFBE9E) => ゲ(E382B2)
ゴ(EFBDBAEFBE9E) => ゴ(E382B4)
サ(EFBDBB) => サ(E382B5)
シ(EFBDBC) => シ(E382B7)
ス(EFBDBD) => ス(E382B9)
セ(EFBDBE) => セ(E382BB)
ソ(EFBDBF) => ソ(E382BD)
ザ(EFBDBBEFBE9E) => ザ(E382B6)
ジ(EFBDBCEFBE9E) => ジ(E382B8)
ズ(EFBDBDEFBE9E) => ズ(E382BA)
ゼ(EFBDBEEFBE9E) => ゼ(E382BC)
ゾ(EFBDBFEFBE9E) => ゾ(E382BE)
タ(EFBE80) => タ(E382BF)
チ(EFBE81) => チ(E38381)
ツ(EFBE82) => ツ(E38384)
テ(EFBE83) => テ(E38386)
ト(EFBE84) => ト(E38388)
ダ(EFBE80EFBE9E) => ダ(E38380)
ヂ(EFBE81EFBE9E) => ヂ(E38382)
ヅ(EFBE82EFBE9E) => ヅ(E38385)
デ(EFBE83EFBE9E) => デ(E38387)
ド(EFBE84EFBE9E) => ド(E38389)
ナ(EFBE85) => ナ(E3838A)
ニ(EFBE86) => ニ(E3838B)
ヌ(EFBE87) => ヌ(E3838C)
ネ(EFBE88) => ネ(E3838D)
ノ(EFBE89) => ノ(E3838E)
ハ(EFBE8A) => ハ(E3838F)
ヒ(EFBE8B) => ヒ(E38392)
フ(EFBE8C) => フ(E38395)
ヘ(EFBE8D) => ヘ(E38398)
ホ(EFBE8E) => ホ(E3839B)
バ(EFBE8AEFBE9E) => バ(E38390)
ビ(EFBE8BEFBE9E) => ビ(E38393)
ブ(EFBE8CEFBE9E) => ブ(E38396)
ベ(EFBE8DEFBE9E) => ベ(E38399)
ボ(EFBE8EEFBE9E) => ボ(E3839C)
パ(EFBE8AEFBE9F) => パ(E38391)
ピ(EFBE8BEFBE9F) => ピ(E38394)
プ(EFBE8CEFBE9F) => プ(E38397)
ペ(EFBE8DEFBE9F) => ペ(E3839A)
ポ(EFBE8EEFBE9F) => ポ(E3839D)
マ(EFBE8F) => マ(E3839E)
ミ(EFBE90) => ミ(E3839F)
ム(EFBE91) => ム(E383A0)
メ(EFBE92) => メ(E383A1)
モ(EFBE93) => モ(E383A2)
ャ(EFBDAC) => ャ(E383A3)
ヤ(EFBE94) => ヤ(E383A4)
ュ(EFBDAD) => ュ(E383A5)
ユ(EFBE95) => ユ(E383A6)
ョ(EFBDAE) => ョ(E383A7)
ヨ(EFBE96) => ヨ(E383A8)
ラ(EFBE97) => ラ(E383A9)
リ(EFBE98) => リ(E383AA)
ル(EFBE99) => ル(E383AB)
レ(EFBE9A) => レ(E383AC)
ロ(EFBE9B) => ロ(E383AD)
ワ(EFBE9C) => ワ(E383AF)
ヲ(EFBDA6) => ヲ(E383B2)
ン(EFBE9D) => ン(E383B3)

- 連続するスペース文字は半角スペース1つに置き換える。
- 先頭と末尾のスペース文字は削除
- >< の間の先頭末尾のスペース文字も削除

libcurl の使い方 その2

Cookie の取り扱い

5つほど関係ありそうなオプションがある。
char *cookie = "sessionid=xxxx";
curl_easy_setopt(curl, CURLOPT_COOKIE, cookie);
COOKIEを key/value 文字列で設定する。1つしか設定できない?
"sessionid=xxx; user=admin" のようにすると複数設定できるけど、仕様外かも。

char *filename;
curl_easy_setopt(curl, CURLOPT_COOKIEFILE, filename);
Cookie が保存されたファイルを指定する。
複数指定可。
ファイルの形式は、Set-Cookie: ラインが並んだもの。(Mozilla/Netscape形式)

char *jar;
curl_easy_setopt(curl, CURLOPT_COOKIEJAR, jar);
Cookie が保存するファイルを指定する。
curl_easy_cleanup()時に保持している Cookie が出力される。

int session_restart;
curl_easy_setopt(curl, CURLOPT_COOKIESESSION, session_restart);
1を指定すると新しいCookie セッションを作成する。

char *set-cookie;
curl_easy_setopt(curl, CURLOPT_COOKIELIST, set-cookie);
Set-Cookie スタイルの文字列で、Cookie を登録する。


同じCURL を使用している限り、Cookie は自動的に登録されて、次回通信時に使用される。
複数のCURLで共有する場合は、CURLSH を使用する。
処理の流れは
//初期化
CURL curl = *curl_easy_init();
// 入力先を指定する
curl_easy_setopt(curl, CURLOPT_COOKIEFILE, "/home/user/.xxx/cookiejar);
// 出力先を指定する
curl_easy_setopt(curl, CURLOPT_COOKIEJAR, "/home/user/.xxx/cookiejar);
for ( ... )
{
URL等設定
:
// 通信
curl_easy_perform(curl);
// HTML内の meta タグの Set-Cookie を登録する。
curl_easy_setopt(curl, CURLOPT_COOKIELINE, set-cookie);
}
// 後処理
curl_easy_cleanup(curl);

Cookie の確認方法
        struct curl_slist *cookies;
curl_easy_getinfo(curl, CURLINFO_COOKIELIST, &cookies);
struct curl_slist *c = cookies;
if ( c == NULL )
{
printf("(none)\n");
return;
}
for ( int i = 1;c != NULL; c = c->next, i++ )
printf("[%d]: %s\n", i, c->data);
curl_slist_free_all(cookies);

libcurl の使い方 その1

HTTP 通信を独自実装しようかと思ってたけど、cURL を使うと簡単そう。

このライブラリには、3種類の API がある。
- easy: 同期通信API
- multi: 複数通信API
- share: 共有通信API

ソースを取得して眺めてたけど、中規模程度のC言語ライブラリ。
Qt みたいな C++ と違って、ユーザー空間から独自拡張しやすいし、使いやすそう。

easy API の流れ
// 初期化
curl_global_init(CURL_GLOBAL_DEFAULT); // https を使用するなら必要
CURL *curl = curl_easy_init();
// 各種設定
curl_easy_setopt(curl, ...);
curl_easy_setopt(curl, ...);
curl_easy_setopt(curl, ...);
:
// 実行
curl_easy_perform(curl);
// 後処理
curl_easy_cleanup(curl);
curl_global_cleanup();

multi API の流れ
// 初期化
curl_global_init(CURL_GLOBAL_DEFAULT);
CURLM *cm = curl_multi_init}();
// 同時接続数設定
curl_multi_setopt(cm, CURLMOPT_MAXCONNECTS, 10);
// 接続設定
for ( int i = 0; i < 10; i++ )
{
CURL *curl = curl_easy_init();
// 各種設定
curl_easy_setopt(curl, ...);
:
curl_multi_Add_handle(cm, curl);
}
// 実行
curl_multi_perform(curl);
// 後処理
curl_multi_cleanup(cm);
curl_global_cleanup();

share API の流れ
DNS/COOKIE/SSL が通信間で共有できるらしい。
// 初期化
curl_global_init(CURL_GLOBAL_DEFAULT);
CURLSH *csh = curl_share_init();
// DNS を共有
curl_share_setopt(csh, CURLSHOPT_SHARE, CURL_LOCK_DATA_DNS);
// COOKIE を共有
curl_share_setopt(csh, CURLSHOPT_SHARE, CURL_LOCK_DATA_COOKIE);
// SSL を共有
curl_share_setopt(csh, CURLSHOPT_SHARE, CURL_LOCK_DATA_SSL_SESSION);
:
// 通信
CURL *curl = curl_easy_init();
:
// 共有
curl_easy_setopt(curl, CURLOPT_SHARE, csh);
:
//実行
curl_easy_perform();
curl_easy_cleanup(curl);
// 後処理
curl_share_cleanup(csh);
curl_global_cleanup();

1秒毎のリアルタイム処理

今までQt 任せだったタイマー処理を自前でやらないといけないので、1秒毎にWebサーバーから情報を取得する方法を考えてみた。

最初は、setitimer() を使って、シグナル処理しようかと思っていたが、このインターバルタイマーって、設定してからの時間になるから、9:00:00.00、9:00:01.00 と、毎1秒00 のときに処理をしたい場合、setitimer() を設定した時刻によって、誤差がでてしまう。これを10時間とか実行すると、誤差が拡大して、あんまりよろしくない。

なので、素直にloop/sleep を使用することを検討してみた。

test.c
int
main(
int argc,
char *argv[])
{
time_t prev = 0;
struct timeval now;
for ( ;; )
{
gettimeofday(&now, NULL);
if ( now.tv_sec == prev )
{
usleep(1000);
continue;
}

printf("time %d.%02d\n", (int)now.tv_sec, now.tv_usec/1000);
prev = now.tv_sec;
}
return 0;
}

実行結果
$ ./a.out 
time 1369500259.585
time 1369500260.00
time 1369500261.00
time 1369500262.00
time 1369500263.00
time 1369500264.00
time 1369500265.00
time 1369500266.00
time 1369500267.00
time 1369500268.00
time 1369500269.00
time 1369500270.00

top で計測していると、0.001sec 毎で、CPU1%、0.0001sec 毎で、CPU4.3%くらい消費する。
十分ですな。

空ファイルの作り方

ある大きさの空ファイルを作成してmmap時に SEGV がおきないようにファイルサイズの予約をしたいけど、一々書き込んでると時間がかかるなぁ、と思ってたら、昔の記憶を思い出した。

その予約サイズまで lseek して書き込めば、ディスクを使用しないけどファイルサイズだけを持つファイルを作成できるんだった。

test.c
#include 
#include
#include
#include
#include
#include
int
main(
int argc,
char *argv[])
{
if ( argc != 2 )
return 1;

int fd = open(argv[1], O_WRONLY|O_CREAT, 0666);
if ( fd < 0 )
return 1;

off_t off = lseek(fd, 4LL*1024*1024*1024, SEEK_SET);
if ( off < 0 )
return 1;

char buf[1] = {'\0'};
ssize_t wsize = write(fd, buf, sizeof(buf));
if ( wsize < 0 )
return 1;

close(fd);
return 0;
}


$ gcc test.c
$ df -h
ファイルシス サイズ 使用 残り 使用% マウント位置
rootfs 514G 385G 124G 76% /
$ ./a.out A
$ ls -lh A
-rw-rw-r-- 1 user user 4.1G 5月 25 23:13 A
$ df -h
ファイルシス サイズ 使用 残り 使用% マウント位置
rootfs 514G 385G 124G 76% /


ディスクも使用してないけど、できれば、ディスクサイズも予約してほしかった。
ディスクが溢れたときは、どうなるんだろ、、、

この挙動なんて言ったっけ、ホールだったかな。

Cookie のおさらい

RFC6525 日本語訳

Cookie は、Set-Cookie/Cookie の二つのヘッダによって制御される。

サーバー → クライアント Set-Cookieヘッダ
クライアント → サーバー Cookieヘッダ

Set-Cookie の構文は、
Set-Cookie: [名前=値]+[; Expires=期限][; Max-Age=期限][; Path=パス] [; Domain=ドメイン] [; [HttpOnly|Secure]]

Set-Cookie は、レスポンスヘッダ内に複数存在する可能性がある。
一つのSet-Cookie に複数の名前/値が存在する可能性がある。
属性の文字列を判定するときは大文字小文字を区別しない。

Expires: クッキーの有効期限
Max-Age: クッキーの期限切れまでの秒数(Expiresより優先)
Domain/Path: 対応するURI
HttpOnly/Secure: http/https のどちらかだけに適用

Cookie の構文は、
Cookie: 名前=値 [名前=値] ...

Cookie ヘッダを複数送信してはいけない。
サーバーは、受信した値の順序に依存してはいけない。
同じ名前の値を複数送信した場合の挙動は未定義。

Set-Cookie より単純。
Webアクセスするときに、対応する Cookie を探してきて付加するだけ。

日付の構文(重要じゃないけど、微妙に面倒臭い)
ex. 15-Nov-2013 23:12:40 GMT

cookie-date     = *delimiter date-token-list *delimiter
date-token-list = date-token *( 1*delimiter date-token )
date-token = 1*non-delimiter

delimiter = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
non-delimiter = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA / %x7F-FF
non-digit = %x00-2F / %x3A-FF

day-of-month = 1*2DIGIT ( non-digit *OCTET )
month = ( "jan" / "feb" / "mar" / "apr" /
"may" / "jun" / "jul" / "aug" /
"sep" / "oct" / "nov" / "dec" ) *OCTET
year = 2*4DIGIT ( non-digit *OCTET )
time = hms-time ( non-digit *OCTET )
hms-time = time-field ":" time-field ":" time-field
time-field = 1*2DIGIT

RFC 通りに Cライクな擬似コーディングすると、以下の感じ。
for ( date-token がある間 )
{
if ( !found-time && (date-token が time形式にマッチ) )
{
found-time = true;
hour-value, minute-value, second-value を解析
continue;
}
if ( !found-day-of-month && (date-token が day-of-month形式にマッチ) )
{
found-day-of-month = true;
day-of-month-value を解析
continue;
}
if ( !found-month && (date-token が month 形式にマッチ) )
{
found-month = true;
moht-value を解析
continue;
}
if ( !found-year && (date-token が year 形式にマッチ) )
{
found-year = true;
year-value を解析
continue;
}
}
if ( year-value >= 70 && year-value <= 99 )
year-value += 1900;
if ( year-value >= 0 && year-value <= 69 )
year-value += 2000;
if ( !found-day-of-month || !found-month || !found-year || !found-time )
goto ERROR;
if ( parsed-cookie-date が UTC に存在しない )
goto ERROR;
return parsed cookie-date;


Domain は、ホスト名のみで IPアドレスは不可。

Path の合致の条件は、
- path が同一である。
- path と前方一致で最後が /
- path と前方一致で一致しない部分の最初の文字が/

つまり、Path で示される下のディレクトリすべてに Set-Cookie は適用される。



とりあえずは、Cookie をディスク内に保存するつもりはないんで、日付は関係ないな、、、

HTTP ヘッダ

HTTPヘッダ一覧

先頭の○×は、アプリで対応するかどうか。キャッシュ関連は、将来のバージョンで。
Accept-Charset を指定しても、サーバーは平気で Windows-31J で送りつけてくるけど、、、気休め
RFC2616 には、Cookie の記載が全くないな、、、

一般ヘッダ
× Cache-Control: キャッシュアルゴリズムの制御
Connection: 接続オプション
× Date: メッセージの生成日
× Pragma: 実装依存
× Trailer: chunked 転送時のメッセージの後に付けるヘッダ
Transfer-Encoding: 転送コーディング
× Upgrade: プロトコルのアップグレード示唆
× Via: 経由したプロキシ
× Warning: 警告

リクエストヘッダ
× Accept: 受け入れ可能なメディアタイプ
Accept-Charset: 受け入れ可能な文字セット
Accept-Encoding: 受け入れ可能な内容コーディング
Accept-Language: 受け入れ可能な自然言語セット
× Authorization: 認証情報
× Expect: 期待するサーバーの挙動
× From: ユーザーの e-mail アドレス
Host: リクエスト先のホスト名
× If-Match: エンティティタグがマッチすればGET
× If-Modified-Since: 指定値以降に更新されていればGET
× If-None-Match: エンティティタグがマッチしなければGET
× If-Range: 更新されてなければ指定された部分だけGET
× If-Unmodified-Since: 指定値以降に更新されていなければGET
× Max-Forwards: 最大プロキシ/ゲートウェイ数
× Proxy-Authorization: プロキシの認証
× Range: 部分GET
Referer: リソースへの逆リンク
× TE: どんな転送エンコーディングが受け入れられるか、trailerフィールドを受け入れられるか
User-Agent: ユーザーエージェント名

レスポンスヘッダ
× Accept-Ranges: 受け入れ可能なリソースの範囲
× Age: レスポンスを生成した時点からの送信者の推定経過時間
× ETag: バリアントのエンティティタグの現在値
Location: 移動先のURI
× Proxy-Authenticate: プロキシの認証
× Retry-After: あとどれくらい利用不可能か
× Server: サーバーソフトウェア
× Vary: サーバーが欲しいヘッダ情報
× WWW-Authenticate: 認証スキーム

エンティティヘッダ
× Allow: サポートするメソッド一覧
Content-Encoding: 内容コーディング
Content-Language: 自然言語セット
Content-Length: エンティティのサイズ
× Content-Location: エンティティの取得可能なURI
× Content-MD5: エンティティのmd5sum値
× Content-Range: エンティティの範囲
Content-Type: エンティティのメディアタイプ
× Expires: レスポンスの有効期限
× Last-Modified: エンティティが最後に更新された日付

HTTP/1.1 おさらい その3

RFC2616日本語訳

8.1 持続的接続

8.1.1 目的
毎回コネクション張るのではなく、コネクションを維持しながら通信することでサーバーの負荷を減らす。

8.1.2. 全体の動作
HTTP/1.1 なら、サーバーが対応してると仮定できる。
Connection ヘッダフィールドで動作を制御する。

8.1.2.1 ネゴシエーション
Connection ヘッダに close が含まれている場合は、毎回接続が切られる。
サーバーから close が送られてくるとその通信を最後に接続が切られる。

8.1.2.2 パイプライン化
持続的接続をしている場合は、転送をパイプライン化できる

8.1.3 プロキシサーバー
プロキシでは、この昨日は特に重要。

8.1.4 現実的な考察
プロキシサーバーは、Webサーバーよりもタイムアウト値を大きくするべき。
クライアントやサーバーがタイムアウトを望むときは、転送接続上礼儀正しく閉鎖するべき。
クライアントが送信中にサーバーが接続を切った場合は、クライアントは再送しなければいけない。
対話的なプログラムなら、ユーザーに再送を要求してもよい。

8.2 メッセージ転送の必要条件

8.2.1 持続的接続とフローコントロール
TCP のフローコントロールを使う

8.2.2 エラーステータスメッセージのための接続のモニタリング
サーバーは、エラーをモニタリングして、エラー時に転送を止めるべき

8.2.3 100(Continue) ステータスの使用
クライアントが対応している場合は、Expect: 100-continue を送る
サーバーが対応している場合は、100-continue を受け取ったらステータス 100 を返す。

8.2.4 サーバーが早まって接続を閉じた場合のクライアントの振る舞い
binary exponential backoff アルゴリズムを使って再試行する

9 メソッド定義
Host ヘッダは、すべてのリクエストに付加しなければならない。

9.1 安全なメソッドと等冪{idempotent} なメソッド
9.1.1 安全なメソッド
GET と HEAD

9.1.2 等冪{idempotent} なメソッド
再読込できるメソッド?GET, HEAD, PUT, DELETE,OPTIONS,TRACE

9.2 OPTIONS

対応しないからいいや

9.3 GET
If-Modified-Since, If-Unmodified-Since,If-Match, If-None-Match, If-Rangeヘッダを付けると条件付きGETになる。
RANGEヘッダを付けると部分的GETになる

9.4 HEAD

9.5 POST
レスポンスが適切な Cache-Control や Expires ヘッダフィールドを含んで いなければ、このメソッドのレスポンスはキャッシュ可能ではない。

9.6 PUT
対応しない

よくPOST と間違える、、、

9.7 DELETE
9.8 TRACE
9.9 CONNECT

対応しない。このへんって、WebDAVかプロキシ作らない限り関係ないな、、、

10 ステータスコード定義
10.1 Infomational 1xx
一時的なレスポンス
10.1.1 100 Continue
クライアントは、リクエストが完了してなければ続ける、完了していれば、そのまま待つ
10.1.2 101 Switiching Protocols
Upgrade ヘッダフィールドに新しいプロトコルを定義

10.2 Successful 2xx
受信成功
10.2.1 200 OK
10.2.2 201 Created
新しいリソースが作られた
10.2.3 202 Accepted
処理は受け付けたがまだ終了していない
10.2.4 203 Non-Authoritative Information
外部サーバーからの情報
10.2.5 204 No Content
ボディ無し
ブラウザは、前のページを表示しておくべき
10.2.6 205 ResetContent
ボディ無し
画面をリセットするべき
10.2.7 206 Partial Content
Range GET の返値
Content-Range か、Content-Type: multipart/byteranges をヘッダに付ける。

10.3 Redirection 3xx
別ページへ移動
10.3.1 300 Multiple Choices
10.3.2 301 Moved Permanently
10.3.3 302 Found
10.3.4 303 See Other
10.3.5 304 Not Modified
10.3.6 305 Use Proxy
10.3.7 306 (Unused)
10.3.8 307 Temporary Redirect

10.4 Client Error 4xx
クライアントのエラー
10.4.1 400 Bad Request
10.4.2 401 Unauthorized
10.4.3 402 Payment Required
10.4.4 403 Forbidden
10.4.5 404 Not Found
10.4.6 405 Method Not Allowed
10.4.7 406 Not Acceptable
10.4.8 407 Proxy Authentication Required
10.4.9 408 Request Timeout
10.4.10 409 Conflict
10.4.11 410 Gone
10.4.12 411 Length Required
10.4.13 412 Precondition Failed
10.4.14 413 Request Entity Too Large
10.4.15 414 Request-URI Too Long
10.4.16 415 Unsupported Media Type
10.4.17 416 Requested Range Not Satisfiable
10.4.18 417 Expectation Failed

10.5 Server Error 5xx
サーバーのエラー
10.5.1 500 Internal Server Error
10.5.2 501 Not Implemented
10.5.3 502 Bad Gateway
10.5.4 503 Service Unavailable
10.5.5 504 Gateway Timeout
10.5.6 505 HTTP Version Not Supported

11 アクセス認証
認証の定義は、別の仕様書

12 コンテントネゴシエーション
12.1 サーバ駆動型ネゴシエーション
Accept (section 14.1), Accept-Charset (section 14.2), Accept-Encoding (section 14.3), Accept-Length (section 14.4), User-Agent (section 14.43) を使って実現
12.2 エージェント駆動型ネゴシエーション

12.3 透過的ネゴシエーション
透過的ネゴシエーションは、サーバ駆動型ネゴシエーションとエージェント 駆動型ネゴシエーションの両方の組み合わせ

HTTP/1.1 おさらい その2

RFC2616日本語訳

4 HTTP メッセージ
リクエスト or ステータス
ヘッダ CRLF
ヘッダ CRLF
ヘッダ CRLF
CRLF
ボディ


HTTP/1.1 クライアントは、リクエストの際に余計な CRLF を前にも後にもつけてはならない。

4.1 メッセージヘッダ
   message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
field-content = "the OCTETs making up the field-value and consisting of either *TEXT or combinations of token, separators, and quoted-string"

LWS は、連続したスペース文字
リクエストヘッダ/レスポンスヘッダの後にエンティティフィールドを送るのが良い習慣

同じフィールド名は、そのフィールドが複数の値を持つことができる場合にだけ許される。
その順番は大事なのでプロキシは順番を変更してはいけない。

4.3 メッセージボディ
      message-body = entity-body
| "entity-body encoded as per Transfer-Encoding"


リクエスト時のボディは、Content-Length や、Transfer-Encoding で、ボディを認識する。

レスポンス時のボディは、ステータスコードや、HEADメソッドかによってボディがあるかないかが変わる。

4.4 メッセージの長さ
Transfer-Coding が適用された後の長さを用いる。

メッセージの長さは以下の通り
1. ボディがなければ、空行で終わること。
2. chunked なら、chunked のところで定義済み
3. Content-Length と転送長さが違う場合は、送ってはいけない。Transfer-Encoding と同時に存在する場合は、Content-Length が無視される。
4. multipart/byteranges で定義される
5. 接続が閉じられるまで。

つまり、メッセージボディの長さは、chunked の長さか、Content-Length を見て判断する。
不正な長さを受信したらエラーを出さなければならない。

4.5 一般ヘッダフィールド
リクエストでもレスポンスでも使えるヘッダ
      general-header = Cache-Control            ; Section 14.9
| Connection ; Section 14.10
| Date ; Section 14.18
| Pragma ; Section 14.32
| Trailer ; Section 14.40
| Transfer-Encoding ; Section 14.41
| Upgrade ; Section 14.42
| Via ; Section 14.45
| Warning ; Section 14.46


5. リクエスト
Method  Request-URI HTTP/1.1 CRLF


5.1 メソッド
       Method         = "OPTIONS"                ; Section 9.2
| "GET" ; Section 9.3
| "HEAD" ; Section 9.4
| "POST" ; Section 9.5
| "PUT" ; Section 9.6
| "DELETE" ; Section 9.7
| "TRACE" ; Section 9.8
| "CONNECT" ; Section 9.9
| extension-method
extension-method = token

サーバが対応していない場合は、405(Method Not Allowed) か 501(Not Implemented) を返す。

5.2 Request-URI
Request-URI    = "*" | absoluteURI | abs_path | authority


プロキシ経由の場合は、absolute-URI を使用すること。
HTTP/1.1 サーバーは、absolute-URI を受け付けなければいけない。

Request-URI に HEXエンコードが使用されている場合は、サーバーはデコードすること。

5.2 リクエストによって識別されるリソース

Request-URI が absolute-URI なら、Host ヘッダを無視する。
相対URI なら、Hostヘッダを参照する。
上記のホストでなければ、 400(Bad Request) を返す。

5.3 リクエストヘッダフィールド
request-header = Accept                   ; Section 14.1
| Accept-Charset ; Section 14.2
| Accept-Encoding ; Section 14.3
| Accept-Language ; Section 14.4
| Authorization ; Section 14.8
| Expect ; Section 14.20
| From ; Section 14.22
| Host ; Section 14.23
| If-Match ; Section 14.24
| If-Modified-Since ; Section 14.25
| If-None-Match ; Section 14.26
| If-Range ; Section 14.27
| If-Unmodified-Since ; Section 14.28
| Max-Forwards ; Section 14.31
| Proxy-Authorization ; Section 14.34
| Range ; Section 14.35
| Referer ; Section 14.36
| TE ; Section 14.39
| User-Agent ; Section 14.43


6. レスポンス
       Response      = Status-Line               ; Section 6.1
*(( general-header ; Section 4.5
| response-header ; Section 6.2
| entity-header ) CRLF) ; Section 7.1
CRLF
[ message-body ] ; Section 7.2


6.1 ステータスライン
Status-Line = HTTP/1.1 Status-Code Reason-Phrase CRLF



6.2 ステータスコードと説明句
- 1xx: Informational - リクエストは受け入れられ、処理を続けている
- 2xx: Success - 動作は正常に受信され、理解され、受け入れられた
- 3xx: Redirection - リクエストを完了するためには、さらに動作を行 わなければならない
- 4xx: Client Error - リクエストは間違った構文か、果たす事のできないものを含んでいる
- 5xx: Server Error - サーバは明らかに正当なリクエストを果たすのに 失敗した

ステータスコードは、該当するコードがなければ x00 が返される。
      Status-Code    =
"100" ; Section 10.1.1: Continue
| "101" ; Section 10.1.2: Switching Protocols
| "200" ; Section 10.2.1: OK
| "201" ; Section 10.2.2: Created
| "202" ; Section 10.2.3: Accepted
| "203" ; Section 10.2.4: Non-Authoritative Information
| "204" ; Section 10.2.5: No Content
| "205" ; Section 10.2.6: Reset Content
| "206" ; Section 10.2.7: Partial Content
| "300" ; Section 10.3.1: Multiple Choices
| "301" ; Section 10.3.2: Moved Permanently
| "302" ; Section 10.3.3: Found
| "303" ; Section 10.3.4: See Other
| "304" ; Section 10.3.5: Not Modified
| "305" ; Section 10.3.6: Use Proxy
| "307" ; Section 10.3.8: Temporary Redirect
| "400" ; Section 10.4.1: Bad Request
| "401" ; Section 10.4.2: Unauthorized
| "402" ; Section 10.4.3: Payment Required
| "403" ; Section 10.4.4: Forbidden
| "404" ; Section 10.4.5: Not Found
| "405" ; Section 10.4.6: Method Not Allowed
| "406" ; Section 10.4.7: Not Acceptable
| "407" ; Section 10.4.8: Proxy Authentication Required
| "408" ; Section 10.4.9: Request Time-out
| "409" ; Section 10.4.10: Conflict
| "410" ; Section 10.4.11: Gone
| "411" ; Section 10.4.12: Length Required
| "412" ; Section 10.4.13: Precondition Failed
| "413" ; Section 10.4.14: Request Entity Too Large
| "414" ; Section 10.4.15: Request-URI Too Large
| "415" ; Section 10.4.16: Unsupported Media Type
| "416" ; Section 10.4.17: Requested range not satisfiable
| "417" ; Section 10.4.18: Expectation Failed
| "500" ; Section 10.5.1: Internal Server Error
| "501" ; Section 10.5.2: Not Implemented
| "502" ; Section 10.5.3: Bad Gateway
| "503" ; Section 10.5.4: Service Unavailable
| "504" ; Section 10.5.5: Gateway Time-out
| "505" ; Section 10.5.6: HTTP Version not supported
| extension-code

extension-code = 3DIGIT
Reason-Phrase = *CR, LF を含まない TEXT


クライアントは、対応していないステータスコードを受信すると、x00 のコードに対する処理と同様の処理を行う。

6.3 レスポンスヘッダフィールド
      response-header = Accept-Ranges           ; Section 14.5
| Age ; Section 14.6
| ETag ; Section 14.19
| Location ; Section 14.30
| Proxy-Authenticate ; Section 14.33
| Retry-After ; Section 14.37
| Server ; Section 14.38
| Vary ; Section 14.44
| WWW-Authenticate ; Section 14.47


7. エンティティ
リクエストメソッドやレスポンスステータスで規制されていなければ送信可能

7.1 エンティティヘッダフィールド
       entity-header  = Allow                    ; Section 14.7
| Content-Encoding ; Section 14.11
| Content-Language ; Section 14.12
| Content-Length ; Section 14.13
| Content-Location ; Section 14.14
| Content-MD5 ; Section 14.15
| Content-Range ; Section 14.16
| Content-Type ; Section 14.17
| Expires ; Section 14.21
| Last-Modified ; Section 14.29
| extension-header

extension-header = message-header


7.2 エンティティボディ
  entity-body    = *OCTET


エンティティボディは、メッセージの中に存在

7.2.1 タイプ
エンティティボディがメッセージに含まれる時、このボディのデータタイプ は Content-Type と Content-Encoding 各ヘッダフィールドによって決定
entity-body := Content-Encoding( Content-Type( data ) )


HTTP/1.1 では、Content-Type をヘッダに含めるべき。
わからない場合は、application/octet-stream として扱うべき。

7.2.2 エンティティ長
転送エンコーディングが適用される前のメッセージボディの長さ

HTTP/1.1 おさらい その1

RFC2616日本語訳

3.1 HTTP のバージョン

HTTP/1.1 で固定なんで問題なし

3.2 URI
3.2.1 一般構文
文字数の制限はないが、サーバーが対応していない場合は、404 を返す
3.2.2 http URL
"http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

port が内場合は80番が仮定される

3.2.3 URIの比較
・URL全体では大文字小文字を区別する
・ホスト名の比較は大文字小文字を区別しない
・スキーム名の比較は大文字小文字を区別しない
・空の abs_path は / と同義
・文字はHEXエンコーディングしてもしてなくても同一にする
以下は同じ
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html


3.3 日付のフォーマット
3.3.1 完全な日付

RFC822/1123、RFC850/1036、 ANSI asctime() スタイルの3種類が許される
RFC850 は、2000年問題があるが受信側は対応しなければならない。
但し、HTTP-date ヘッダは、RFC1123
受信アプリケーションは、SNMP/NNTP の形式も受け付けられた方がいい。

日付/時刻は、GMTを使用する。 SP はスペース文字
HTTP-date    = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT
date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (e.g., Jun 2)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
wkday = "Mon" | "Tue" | "Wed"
| "Thu" | "Fri" | "Sat" | "Sun"
weekday = "Monday" | "Tuesday" | "Wednesday"
| "Thursday" | "Friday" | "Saturday" | "Sunday"
month = "Jan" | "Feb" | "Mar" | "Apr"
| "May" | "Jun" | "Jul" | "Aug"
| "Sep" | "Oct" | "Nov" | "Dec"


3.5 内容コーディング
Accept-Encoding: <token>
Content-Encoding: <token>

大文字小文字は区別しない
gzip: RFC1952 32bit CRC付き LZW
compress: LZW
deflate: RFC1950/1951 zlib フォーマット
identity: 圧縮無し

3.6 転送コーディング
Transfer-Encoding: <transfer-coding>
transfer-coding = "chunked" | transfer-extension
transfer-extension = token *( ";" parameter )
parameter = attribute "=" value
attribute = token
value = token | quoted-string

"chunked" は、一度だけしか設定してはだめ。
IANA に登録されているものは、chunked / identity / gzip / compress / deflate
サーバーが対応してない場合は、501 (Unimplemented)が返る。

3.6.1 チャンク形式転送エンコーディング
いわゆるボディを送る前にサイズを付加する方式
       Chunked-Body   = *chunk  last-chunk trailer CRLF
chunk = chunk-size [ chunk-extension ] CRLF chunk-data CRLF
chunk-size = 1*HEX
last-chunk = 1*("0") [ chunk-extension ] CRLF
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)
trailer = *(entity-header CRLF)

チャンクのサイズは16進数、サイズが 0 のチャンクで終了
trailer には、HTTPヘッダフィールドを追加できるが、受信側に無視されるかもしれない。
HTTP/1.1 アプリはすべて "chunked" エンコーディングに対応しなければならない。
理解できない chunk-extension は無視しなければならない。

3.7 メディアタイプ
Accept: media-type
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token

type/subtype の間にスペースを入れてはならない。
メディアタイプ値は、IANA で管理されている。

3.7.1 公式化とテキストデフォルト
"text" 形式の文末は、CRLF CR LF の3タイプに対応しなければならない。
テキストのマルチバイト文字セット内で、CR/LF が13/10 でなければ、それも対応しなければならない。
ヘッダフィールドやマルチパート境界などのHTTP制御構造では、単独のCR/LF をCRLFに置換してはならない。??
charset のデフォルト値は、ISO-8859-1それ以外は、charset を設定すること。

3.7.2 マルチパートタイプ
body-parts間は、CRLFを使用する。
RFC2046と異なり、どのエピローグも空でなければならない。
HTTPアプリは、エピローグを送信してはいけない。

206(Partial Content) レスポンス中の multipart/byteranges は、HTTPキャッシュメカニズムで解釈される。

HTTPユーザーエージェントは、MIMEユーザーエージェントと同じ振る舞いをするべき。

multipart/form-data は、RFC1867 で、POSTリクエスト用に定義されている。

3.8 製品トークン
User-Agent: product
Server: product
product = token ["/" product-version]
product-version = token

ex.
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4


3.9 品質値
0〜1までの小数点3桁の小数

3.10 言語タグ
Content-Language: language-tag
Accept-Language: language-tag
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
ex. en, en-US, en-cockney, i-cherokee, x-pig-latin

詳しくはRFC1766で定義
大文字小文字を区別せず、スペース文字は使えない。

3.11 エンティティタグ
If-Match: entity-tag
If-None-Match: entity-tag
If-Range: entity-tag
entity-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string

W/ は弱い比較
異なるURI から同じエンティティが得られても同じではない。

3.12 レンジ単位
HTTP/1.1 では、"bytes"だけ


5/23の取引

9983 ファストリテ: 前 41400 始 42000 高+2400 安-3900 終 38100
100株 41400S → 41750C -35,000円
200株 42000S → 41750C +50,000円

合計 +15,000円

決死の覚悟で寄りナンピンして、利確したのに、後場下げ下げやん、、、俺の勇気を無駄にしやがって、、、

こんなデイトレ日和な日に取引してない、、、
明日の後場寄りは、追証投げがでるかもしれないので、前場引けと後場寄りは楽しみ。

QNetworkAccessManager SSL 繋がらない

Qt4.8 になってから、QNetworkAccessManager で特定の https サイトが繋がらないので、調べてみた。

どうも Qt4.8 になって、OpenSSL の TLSv1.2 に対応したのが原因らしい。

OpenSSL 直打ちのテストプログラムを作って試してみた。

・SSLv23_client_method(void); /* SSLv3 but can rollback to v2 */
 → だんまり (QNetworkAccessManager の挙動)
・SSLv3_client_method(void); /* SSLv3 */
 → 成功
・TLSv1_client_method(void); /* TLSv1.0 */
 → 成功
・TLSv1_1_client_method(void); /* TLSv1.1 */
 → エラー
・TLSv1_2_client_method(void); /* TLSv1.2 */
 → だんまり
・DTLSv1_client_method(void); /* DTLSv1.0 */
 → SSL_connect()で失敗。

TLSv1 か SSLv3 で接続すれば、成功するらしい。

SSLv23 を使用しても、SSL_OP_NO_TLSv1_1 | SSL_OP_NO_TLSv1_2を使用すればアクセスできる模様。


うーん、Qt から設定する方法がわからん、、、
QNetworkRequest に無理矢理ぶち込んでも、どっかでリセットされるし、、、
せめてエラーで返ってくれればいいんやけど、だんまりだと他のサイトに逃げることもできない、、、

自前でHTTP処理を作り直すしかないのか、、、

あと、SSL_shutdown()がいつもエラーを返すんだけど、ええのかこれ。

5/22の取引

4503 アステラス : 前 5690 始 5700 安 -50 高 +100 終 5750
200株 5670L → 5690C +4,000円

9432 日本電信電話: 前 5260 始 5260 安 +0 高 +190 終 5390
200株 5280L → 5310C +6000円

3765 ガンホー : 前1034000 始974000 安-66000 高+264000 終1100000
1株 1188000L → 1189000C +1,000円

9766 コナミ : 前 2855 始 2966 高 +18 安 -151 終 2872
200株 2858L → 2859C +200円

合計 +11,200円(手数料含まず)

しょぼいっす。
寄り前に外資系売り越しって言うから寄りで利確したら上がる上がる、、、
株数は売り越しだけど、売買代金は買い越しだったらしい、、、早く言え、騙された。

弁護士さんから請求書

弁護士さんから着手金の請求書が届きました。

請求書の内訳で、源泉所得税とかいうのが引かれていたので調べてみると、弁護士や税理士などの士業の人の手数料は、源泉徴収しないといけないらしい。知らなんだ。

だから、源泉の計算書に税理士報酬を記載する欄ががあったのか。単に税務署が税理士を管理するために書かせているのかと思ってました。

だけど、源泉徴収って10%しか引いてないんだけど、弁護士の所得税って10%??
まさかね、、、確定申告してるよね、きっと、、、

5/21の取引

6723 ルネサス : 前 616 始 619 安 -29 高 +96 終 626
500株 632S →642C -5,000円

9983 ファストリテ: 前 39200 始 38700 高 +250 安 -450 終 38550
200株 38650S → 38450C -40,000円

合計 -45,000円(手数料含まず)


ルネサスは、約定メールがきて板を見ると、いきなり特買気配、、、10分間ほど呆然、、、
寄った後のリバで損切り、、、ドテンを悩んだけど、できなかった、、、よわい、、、
最後垂れてマイテンしてたけど、結果論なんで仕方ない。

6971 京セラ決算[買い]

2013/4/25 京セラ株の決算分析

当日の株価: 前 9710 始9800 高9850 安9740 終9800
翌日の株価: 前 9800 始10050 高9830 安9740 終9930



売上高営業利益税引前利益当期純利益
26年3月期予想1.4兆1400億1500億960億
25年3月期1.28兆円(+7.5%)769億円(-21.2%)1014億円(-11.8%)665億円(-16.2%)
24年3月期1.19兆円(-6.0%)977億円(-37.4%)1149億円(-33.3%)794億円(-35.2%)



営業利益率1株利益配当現金負債
25年3月期6.0%362.36円120円3055億円2413億円
24年3月期8.2%432.58円120円2733億円1588億円


急速に営業利益率が落ちてる。
今回営業利益が減少したのは、米国子会社の環境汚染浄化費用が207億円、前回は不明。
税引前利益で増えているのは、受取利息・配当金が147億円。KDDIの分かな。あと、有価証券売却益が45億円。JALの分かな。

来期の営業利益予想は盛りすぎな気がするので、決算前は要注意。


6857 アドバンテスト決算[売り]

2013/4/25 アドバンテスト株の決算分析

当日の株価: 前 1500 始1520 高1570 安1496 終1533
翌日の株価: 前 1533 始1433 高1442 安1395 終1412



売上高営業利益経常利益当期純利益
26年3月期予想1600億円130億円130億円98億円
25年3月期1329億円(-5.8%)0.8億円(-90.5%)-13億円-38億円
24年3月期1410億円(+41.6%)8億円(-86.3%)-34億円-22億円



営業利益率1株利益配当現金負債
25年3月期0.1%-22.03円20円457億円564億円
24年3月期0.6%-12.67円15円582億円273億円


なんか、虫の息な感じですな、、、
増資やCBの可能性もあるし、メモリテスタのシェアが上昇に転じるまで手出し無用。

6305 日立建機[売り]

2013/4/25 日立建機株の決算分析

当日の株価: 前 2259 始2270 高2295 安2213 終2277
翌日の株価: 前 2277 始2300 高2361 安2266 終2327



売上高営業利益経常利益当期純利益
26年3月期予想8300億円830億円690億円370億円
25年3月期7724億円(-5.5%)515億円(-6.1%)364億円(-29.6%)235億円(+1.9%)
24年3月期8171億円(+5.6%)548億円(+32.1%)517億円(+23.4%)230億円(+107.8%)



営業利益率1株利益配当現金負債
25年3月期6.7%110.77円40円626億円2360億円
24年3月期6.7%108.88円30円728億円1973億円


売上減は、中国の固定資産投資が低調だったのと、石炭需要減速でインドネシア、オーストラリアで需要減少。
売上減でも、営業利益率があまり変わらないのは、経費にバッファがあるというか、利益をださないようにする体質なのかな。
経常で減少しているのは、支払利息は117億円と為替差損が68億円。支払利息高くないかい?どっから借りてるんだろう、、、
純利で減少しているのは、法人税173億円。持分変動利益が99億あるけど、差分だけ減少してる。

日立ハイテクもそうだったけど、日立グループの会社って営業利益少ないな、、、
グループ会社どうしで、高値取引とかしてるんだろうか、、、

あまり買いたくはないです、、、

6301 コマツ決算[買い]

2013/4/25 コマツ株の決算分析

当日の株価: 前 2581 始2589 高2593 安2554 終2587
翌日の株価: 前 2587 始2650 高2680 安2595 終2655



売上高営業利益経常利益当期純利益
26年3月期予想2.05兆円3050億円2970億円1840億円
25年3月期1.88兆円(-4.9%)2116億円(-17.5%)2046億円(-18.0%)1263億円(-24.4%)
24年3月期1.98兆円(+7.5%)2563億円(+15.0%)2496億円(+13.6%)1670億円(+10.8%)



営業利益率1株利益配当現金負債
25年3月期11.2%132.64円48円936億円4376億円
24年3月期12.9%173.47円42円831億円3994億円


売上げの減少は、中国の売上げが減少したため。
営業利益の減少は、売上げ減少に伴う原価比率の向上と、販管費の増加。販管費の増加理由は書いてないけど、おそらく円安が要因かな。
純利で減っているのは、法人税が690億円。
来期予想の根拠は、景気回復と円安。
想定レートは、95円/ドル、123円/ユーロ、15.3円/元

基本買い目線だけど、決算前は下方修正注意な感じかな。



弁護士さんと打合せ

滞納者の家賃滞納について打ち合わせてきました。

弁護士「私の方から督促状をだして様子見ましょうか?弁護士から連絡がいくと払ってくる人も多いですよ。
私「督促状を出すと時間がかかるので、訴訟でお願いします。

ということで、契約解除と明け渡しの訴訟を起こす方向で動くことになりました。

この滞納者、旦那が薬で刑務所に服役中なんですが、もうすぐ出所してくるらしいです。
マンションに薬中の人間がいたら、マンションの治安にかかわります。
ここは、かわいそうですが、他の住人のためにも出て行ってもらいましょう。


人生初の裁判なんで、めちゃくちゃ楽しみです。
弁護士さんの訴状の書き方とか覚えて、次回は自分でできるようにしないと、、、

あ、別に裁判がしたくて訴訟にしたんじゃないです、、、きっと、、、たぶん、、、ごめんなさい。

 | HOME |  »

Calendar

« | 2013-05 | »
S M T W T F S
- - - 1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31 -

Monthly

Categories

Recent Entries

Recent Comments

Recent Trackbacks

Appendix

ナマポ不動産

ナマポ不動産

株歴5年
大家歴4年
です。

株の手法は、酒田五法を自己流でアレンジした勘トレです、、、orz

2013 確定損益(含み損益込前月比)
 5月   +940,578
 6月 +1,103,401 (+648,940)
 7月   +496,406 (+337,406)
 8月   +227,368 (+467,586)
 9月   +385,146 (+809,644)
10月 +2,880,993 (+611,895)
11月   +323,062 (+494,426)
12月   +439,567 (+235,485)
申告 +512万円(うち配当 +33万円)

2014 確定損益(含み損益込前月比)
 1月    +508,788 (+427,432)
 2月    +560,810 (+778,034)
 3月    +507,715 (-253,540)
 4月     +68,688 (-1,069,645)
 5月    +347,468 (+1,255,721)
 6月  +1,068,696 (+901,076)
 7月    +305,470 (+380,862)
 8月     +69,794 (-641,412)
 9月  -1,215,544 (+390,466)
10月    +304,769 (+591,055)
11月    +231,939 (+196,234)
12月  +1,422,970 (+887,793)
申告 +451万円(うち配当 +26万円)

2015 確定損益(含み損益込前月比)
 1月    +266,262 (+832,570)
 2月  +1,097,569 (+907,316)
 3月    +530,465 (+467,067)

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。