牛乳がマッハでなくなる。紅茶の方はなかなか無くならない。幼稚園児と1/20メカトロウィーゴを作ったメカトロウィーゴのプラモデルは1/35と1/20がある。こっちは1/20の大きい方で、重量感があり、かなりしっかりしてる。大きいので1/35よりむしろ作りやすいくらいで、幼稚園児に手伝ってもらってもそこまで致命的な箇所もなく、私の雑な筆塗りでも塗装しやすかった。素の色がものすごく良くて、塗装しようかどうかちょっと悩んでしまった。無塗装のものが欲しいならもう一度作れば良いだろうと思って塗った。どんな作業でも割とそうだが、成功させようと思わないで始めることだと思う。難しめの死にゲーをやるときみたいに、ルーチンワークのように死ににいくつもりで向かえば良い。するといつか死なないターンも来る。要は、そこまで繰り返すかどうかだ。共有2017年8月8日火曜日Node.jsでPHPのセッションの復号をあれこれしてたNode.jsでPHPのセッションを読むというようなことをやっていた。筋の良いことではないし、当然同じことをやっている人は少なく、一応PHPの直列化した文字列を復号するパッケージは無いわけではないが片手で数えるほどで、大なり小なり問題を抱えていた。問題の形は様々ではあったけど、躓いている箇所は同じで、みんな文字長を計算する箇所で間違えていた。PHPの直列化した文字列はs:文字列長(バイト):"文字列"みたいになっているのだけど、PHP側ではUTF-8で文字列長を計算しているものが、JavaScript側ではUTF-16になっているので、長さを相互に調節しなければいけないということだ。これは問題としては特に難しくないはずだけど、そもそもマルチバイトの文字列のことが想定されていなかったり、その想定されていない状態から無理に対応をしようとして片手落ちになっていたりした。本来PRでも投げるべきなのだろうけど、いくつかパッケージを試した時点でそもそもこの方法で対応するのは良くないかもと思ってやめたので、備忘録として書いている。具体的に書いておくと、UTF-8ではUnicodeの符号位置を表すのはアスキーの場合1byte(これは完全にアスキーコードと同じ)、ウムラウト(Äとか)なんかの記号の場合2byte、日本語の標準的な文字の場合3byte、絵文字(🍰)や外字なんかの場合4byteみたいに可変長で文字を表している。これに対してJavaScriptの内部エンコード(これはJavaScriptのソースコードを記述してる文字コードとは関係ない)であるUTF-16の場合、2byteないし4byte(サロゲートペア)で表すことになる。サロゲートペアの文字列はJavaScript上では二文字のように見える。2を返すし、"🍰".charCodeAt(0)は55356、"🍰".charCodeAt(1)は57200を返すし、これを前半部・後半部とかだけ切り出してしまうと読めない文字に化けてしまう。PHPで直列化されたものをJavaScript側で読むコードを書くと、サロゲートペア以外は一文字として読んでいくような処理になる。最初の格納種別と、長さを読んで、その後長さ分の文字列を切り出すわけだけど、そのときに読んだ文字がUTF-8で何byteに相当するのかということをまず計算しなくちゃいけない。これは前出のString.charCodeAtとかString.codePointAtで調べれば良い。その上で、更に今読んだ一文字がサロゲートペアなら、その後半部(次の添字の文字)はうまいことスキップするような処理を入れてやればいい。最終的に私はNode.jsで処理するのをやめて、phpで標準入力から入ってきた直列化文字列をそのままJSONエンコードを通して標準出力するだけの数行のプログラムを書き、Node.jsのプログラムからspawnで呼び出すようにした。まともなやり方ではないかもしれないが、今回の仕事ではそれで十分だった。プログラムに色々な人が居るならば、私は綺麗に溶接してヤスリをかけ塗装するより、ダクトテープでぐるぐる巻きにするタイプであろうと思う。PLUGSという耳栓を海外から買った。