00:01
こんにちは。今日も帰りの歩き道で撮っています。
昨日、録音を撮り直したという話をしていたんですけど、これからはそういうことをやめようかなというふうに思い直しました。
他の方のリッスンの配信を聞いていても、そんなに高音高い重い音声コンテンツじゃないので、ノイズがあっても気にならないというか、逆に生活感が聞こえた方が臨場感があっていいなというふうに思うんですよね。
あとは、手軽なアウトプットなはずなのに、ちょっとハードルが上がるのは良くないなというふうに思いまして、そういうのはやめようと。
とにかく一発撮りでバンバン出す。そういうふうにやっていきたいなと思います。
ハードルが上がってしまった失敗例としてですね、私のブログがあって、個人のブログのドメイン。
メモ.yammer.jpというドメインにしていて、ここはメモ書きだと雑に書く場所なんだというふうに宣言しているにも関わらずですね、だんだんちゃんとした文章を書かなきゃなみたいな気持ちになって、
ハードルが上がって出す頻度が落ちてみたいなことを繰り返して、いやそれじゃいかんって、たまに仕切り直すみたいなことをしてですね、やっぱハードルが上がるのは良くないですね。
ちゃんとしたアウトプットとして、遂行したり成形したりするのももちろん大事なんですけど、全部が全部そうしていると、なかなか思いついたことを全て出し切るわけにもいかないので、
場所とか携帯とかに合わせて、いろいろ変えていったほうがいいんじゃないかなってことで、リッスンは雑に出すということで、ハードルを下げて一発撮りでいこうと思います。
今日も多くの話をしたいなというふうに思います。今日話すのは、URLじゃないですね、ブラウザのフォームのポストリクエストについてもうちょっと話そうかなというふうに思います。
前回、HTTPのボディをパースするという話をしたんですけど、Webアプリケーションで扱うには、このパースしたボディをですね、さらに読み込んでいかなければいけません。
ブラウザのフォームのリクエストっていうのは、HTMLタグでフォームって書いて、インプット、タイプサブミットとかして、ボタンを押すとポストリクエストが送られると思うんですけど、
03:11
これ送られたときのコンテンツタイプは、アプリケーションスラッシュXWWWフォームURLエンコードでした。そんな感じになると思うんですよね。
HTTPのボディはどうなっているかというと、URLエンコードされたヒートバリューが連なっているという形式になっていると思います。
URLエンコードっていうのは、空白がプラスに置き換わって、あと、数字とか、アルファベットとかの基本的なアスキーの文字の数字とか、
アルファベットとか以外の文字、特殊な記号とか、マルチバイト文字とかは、パーセントプラス2桁の16進数っていうので、置き換わって1バイトを表すっていうふうに変換されると思います。
例えば、utf-8で、あっていう文字を送ろうと思って、例えば、インプットのネームがfooで、そこのバリューがあだとしたら、
fooイコール、パーセント8、0パーセント、みたいな感じの形式になって送られるんじゃないかなというふうに思います。
これを多くでどうやって読むかっていうと、まず、ヒートバリューの組み合わせでそれを分割しますと、
文字列をアンパサンドで区切って、アンパサンドでキーバリューのセットがたくさん並んで、それを区切って、イコールでもさらに区切って、キーとバリューの組み合わせにすると、
プラスを空白に置き換えると、あとパーセント16進数16の2桁っていうのを解釈することになります。
これ解釈するのはどうやってやるかっていうと、多くにはstgar2numっていう関数とsprintfっていう関数があるので、これらを組み合わせます。
まず16進数2桁の部分を取ってきて、先頭に0xっていう文字を付けます。
例えば、80っていうパーセント80みたいな1バイトを表す文字があったら、0x80みたいな文字にして、これをstr2numっていう多くの表示の関数に渡して、
06:03
多くの変数の中で16進数の表記の数値型の値にします。これをsprintfっていう関数の引数に渡します。
sprintfっていうのはよくあるプリントfのフォーマットを第一引数に受け取るので、そこをパーセントCっていうふうにしておいて、
1文字受け取るっていうので、第二引数にその接数の文字を入れておくと、これで16進数の文字が1バイトの文字列に置き換わるようになります。
私の作ってるWebアプリケーションではUTF-8を前提にしてるので、好きの1バイトか、もしくは2から4バイトの可変調の文字が来るので、
単純に変換してるんですけど、実際にはチェックをかけて、例えば3バイト分のバイトシンクエンスが続いたら、そこのUTF-8のバイト並びのルールに合致してたら、
3バイト分一気に変換するみたいな、そういう処理を書いてます。
さっき気づいたんですけど、厳密にはバイトシンクエンスのチェックたぶん足りてなくて、
例えばUTF-8だったら、好きに収まる1バイトの文字っていうのは、2バイトで表現しちゃいけないみたいなルールがあるんですよね。
最短で表現しちゃいけない。そういうチェックが抜けてるんで、完全に安全なUTF-8のデコードっていうのはたぶんできてないということにさっき気づいたんですけど、
そういうのはお遊びのアプリケーションなので、あるところもあるんですけど、ブラウザのフォームリクエストは一応多くのプログラムの中で、
UTF-8の文字は普通に文字列として取れるっていうところまでは実装できてるんじゃないかなっていうふうに思ってます。
というわけで、今日はフォームリクエストのURLエンコードのデコードの話をしました。
私の作ってるWebアプリケーションのソースコードをGitHubのYammerJPスラウォークブログっていうリポストリがあって、
ここにあるディレクトリのsrc/.libっていうところに前回まで話したような実装とかを入れてるんですね。
例えば、今回の話もそうですし、前回のHTTPの話もそうです。
09:00
このディレクトリにあるソースコードのファイル、例えば今回であればURLエンコードなんで、
url.org。前回であればHTTPの実装であれば、なのでhttp.orgってファイルをやってるんですけど、
気づいたら10個とか20個とか入れができててですね、
この調子でここで話していってもラチが開かないというか、気づいたら実装が割と増えてしまっていたので、
次回ちょっと何話そうかなっていうのは結構悩んでますね。
何にしようかな。そうですね。
ルーティングとか、テンプレートエンジンの話とか、
フォースツーの話でもいいけど、それはそんなに面白くないかなとかですかね。
画像のアップロードの話はどこかでしたいですね。
というわけで話したいことはすごくたくさんあるんですけど、
今日はこの辺にしたいなというふうに思っています。
では皆さんお元気で、もし調子が良ければまた明日お会いしましょう。
では。
