22:00以前作成した、デバイスごとにサポートするiOSの最終バージョンを一覧を更新しました。・iOS5以前をサポートすることは、現在困難だと思います。touch代4世代をサポートしなくて良ければiOS6のサポートをやめられます。実質もうOKかと思います。・iPhone4をサポートしなくてよければiOS7のサポートをやめられます。・iOS8を最終バージョンとする端末はありませんが、iOS8のiPadはまだ多数あるようなので対応しておいたほうがいいかも。アニメも終わって、ゲームも稼働終了となり、アイカツスターズ!という新しい展開にするそうです。アイカツカードといえば裏面のバーコードを読み取る形式だったので、ものすごい種類(2500種類くらい?)を捌ききれるのかと検証してみましたが、全然余裕でしたというのがその時の結論。プロモーションカードを配布していたので、娘のために貰ってきました。このカードはプロモーション用なので普通の印刷ですが、筐体から排出されるカードはオンデマンド印刷に変わります。いうわけで、裏面にあったバーコードが表面のQRコードに変わりました。実は今主流の形式ですね。いうか、「妖怪ウォッチともだちウキウキペディア」が既に同じ形式なので新しくもなんともありません。やって写真撮ってしまうと、QRコードも利用できてしまうのが困る。以前はカードしか挿入できなかったので、一旦紙に印刷しないとスキャンできませんでしたが、今回は筐体のCMOSカメラに見せる形式のようなので写真撮影→スマホ画面でも認識するでしょう。一応QRコードをボカしました。前回同様、どのくらいのコードが入っているのか見てみますかね・・・。別にセル数変えられるからいくらでも拡張できちゃうんだろうけど。QRコードリーダーで読み込んでみると、「http://dcd.sc/」で始まるURL形式で84文字のデータになっています。カードの固有情報と思われる部分はそのうち65バイトかな?URLには記号も含まれているのでQRコード的にはバイナリ扱いになります。セルのサイズから、バージョンは8です。あと、QRコードには誤り訂正レベルというのが4種類(L,M,Q,H)があり、Hが最も復元しやすく、Lが最もデータ量が多くなります。誤り訂正レベルは何使ってるんですかね。(84byteは一番誤り生成レベルが高いHでちょうど入るのでおそらくHなんでしょうけど、一応確認します)下の画像は、上のカードのQRコードの左上を拡大したものです。赤枠の部分は、タイミングパターンというもので、必ず白と黒の交互のパターンになっています。他の部分のセルを切り出すときのヒントになるマーカーみたいなものですね。青枠の部分が形式情報を保存している部分です。この位置以外にも、右上と左下の検出シンボルにも分割して同じ情報が入っています。(汚れや隠れに対応するためと思います)この0~14の部分を、白を0,黒を1として読み取ると、001110011100111になります。(この数字の左端が上位ビットなので=画像の14の位置です)この15bitのうち、最初の2bitが誤り訂正レベルを示しています。同じビットが続くと読み取り精度に悪影響を与えるため、101010000010010でXORをとってあります。といわけで、もう一度XORをかけて元に戻すと、100100011110101になります。最初の2bitは10ですね。誤り訂正レベルは以下のように定義されていますので、このコードの誤り訂正レベルはHということになります。□□(白,白)だったら、誤り訂正レベルH□■(白,黒)だったら、誤り訂正レベルQ■□(黒,白)だったら、誤り訂正レベルM■■(黒,黒)だったら、誤り訂正レベルLです。いうわけですので、セルサイズが変わらないという前提で言えば、コーデ(衣装)カードは84byteのURL形式が固有IDとして割当られるようです。旧アイカツカードにも実はQRコードも併記されているんですが、こちらはもっとコード量が少ないです。URLが「http://aikatsu.com/」になっているので、固有コードはもっと短いです。旧アイカツカードの裏のQRコードの誤り訂正レベルはL(7%復元)、バージョン4だったのに対して、アイカツスターズのQRコードは最も誤り訂正レベルの高いレベルH(30%復元)、バージョンは8になっていますね。オンデマンド印刷での品質を考慮した結果でしょうか。ところで、Webにある、QRコード生成サイトで、同じURLのQRコードを同じバージョンと誤り訂正レベルで作ってみても、QRコードが同じになりません。同じになる場合もあるんですが、QRコード生成時に、いまいち規格上固定されない部分や、規格の年式による微妙な違いがあり、実装により変わるみたいです。アイカツスターズの筐体が、この部分の違いまで見極めて勝手に作ったQRコードを不正なカードと判断するかするかどうかは・・・まぁ、しないでしょうね。ライバル機である、プリパラのQRコードは白黒反転されております。これはデータの保護というよりは、デザイン面での配慮な気がします。19:34前回の記事のつづきです。月が変わり、帯域制限の対象ではなくなったはずなのでもう一度測定してみました。速度.zip1.2秒849KB/s.bin0.9秒1.10MB/s.exe1.1秒966KB/s.lzh1.2秒864KB/s.pdf1.2秒869KB/s.aikatsu1.2秒864KB/sあ、速い・・・。帯域制限がかかっていたファイルタイプと、そうでないファイルの速度差がなくなりました。月末に測定した時の転送時間は、zipファイルは80秒弱、pdfファイルは2秒ちょっとでした。上記表以外にも複数回測定してみましたが、概ね安定した速度です。帯域制限がかかっていないと思っていたファイルでも転送速度がだいぶ速くなっています。LTEプランの帯域制限中の挙動はおそらく以下のような挙動かなと思われます。特定のタイプと一致すると更に帯域制限される(96Kbpsくらい?)ただし、帯域制限の目安の通信量をどの程度超えたかや、基地局の混雑具合によって制限値が変わるという書き込みも見られるので、数値は環境によって変わるかもしれません。LTEの回線でアプリのテストをしているときに謎の不具合として発見しました。スピードテストや、普通のブラウジングは快適に行えているのに何故かzipファイルの転送時のみものすごく遅くなり、最初は自分のアプリの不具合を疑いましたがHTTP通信全般で発生するようです。LTEで、「当月のご利用通信量が10GB以上」で帯域制限を行うと公表されています。テストした日までの通信量は10.588GBで、目安の通信量を超過している状態です。この状態でHTTPによるリクエストを出すと、ファイル種類によって挙動が変わります。月初めはどのような挙動になるか不明なので来月になったらやってみます。以下コマンドで1MBのダミーファイルを生成。count=1ファイルの中身はそのままで、拡張子のみを色々変えてwgetで転送してみた結果が以下です。速度.zip95秒9.68KB/s.bin72秒13.1KB/s.exe74秒12.6KB/s.lzh73秒12.8KB/s.7z78秒12.1KB/s.rar77秒12.7KB/s.jpg2.1秒480KB/s.png2.3秒436KB/s.pdf2.6秒388KB/s.cbz2.1秒495KB/s.pptx3.1秒335KB/s.aikatsu2.0秒502KB/s1回づつしか測定していないので誤差は大きいと思いますが、ファイルタイプによって明確な差がついていることは明らかです。10倍どころか30倍違う・・・!1MB転送するのに1分以上もかかっているようでは、実用的にはかなりキツイ状態です。HTTPSにした場合は帯域制限かからなくなります。LTEプラン)では、HTTP通信の内容を見て帯域制限を実施していることがわかります。.aikatsuは制限がかかっていないので、「JPEGは制限しない」のようなホワイトリストでなく、「zipは制限する」といったブラックリスト方式みたいですね。僕が発見したのはzip,bin,exe,lzh,7z,rarですが、他にもあるかもしれません。次にファイルタイプの判別方法ですが、ファイルの拡張子ではなくMIMEタイプを見て判別しているようです。ファイルに以下を以下のようにしてMIMEタイプを変更して同じRARファイルをダウンロードした場合です。速度application/x-rar-compressed93秒9.25KB/simage/jpeg2.1秒491KB/swww/unknown2.7秒376KB/sその他、いくつかオレオレMIMEを指定してみましたが帯域制限はうけませんでした。よって、HTTPサーバの設定を変更してMIMEタイプを変えてしまえば帯域制限を免れることができますね...。いうか最近のWebサーバはRARとかまでMIMEが正しく設定されているのか・・・。していいか分からない苦情が来ることに備えるには以下の対策が考えられます。(実際これが原因で帯域制限の仕様を知った・・・)・HTTPSを利用する昨今色々あるので、もう全部HTTPSにできればそれが良いかもしれません。・MIMEタイプを変更するこれを変えてしまうのは反則かもしれませんが、現実的にはzipなどのMIMEが間違っていてもダウンロードさえされれば別に困りません。image/jpegなどにするとブラウザ側が困るので、www/unknownあたりにしておくのが無難かと思います。すげえ!とりあえず、ComicGlassのサンプルファイル置き場はこの対策で乗り切ります。ブラックリストに入っているMIMEは今日現在の挙動なので今後は変わるかもしれません。自分で薦めておいて何ですが、みんながこんなことやり始めたらHTTP崩壊だな・・・。利用者側の対策できることは少ないですが、HTTP通信の内容がわからなければいいわけなので、VPN接続してトンネル経由でアクセスすれば制限はかかりません。帯域制限としては良心的な気もします。実際に公表された通信量を超えても、HTML,JPEGやPDFなど通常のブラウジングには制限がかからないので通常の利用に弊害がありません。HTTP以外の通信は特に制限されている様子はありません。僕のようなzipをHTTP転送するのに特化されている特殊なアプリ開発者にとっては罠もいいところですが・・・。上に書いた通信速度はByte/秒です。通信速度はbit/秒で書いてあることも多いので注意してください。12KB/sは96kbpsになります。400KB/sは約3.1Mbpsになります。よって、今回のテストでも制限を受けないファイルタイプであれば3Mbps程度は出ており、たぶん制限なくてもこんなもんです。追記(15/07/22)いくつか補足と訂正を。・「最近のWebサーバはRARとかまでMIMEが正しく設定されているのか・・」と書きましたが、正確には(Apacheが)/etc/mime.typesを参照してるだけですね。・測定は平日昼間(正午ころ)行っています。夜間はプロトコル関係なく帯域制限がかかります。こちらは「24時間ごとのご利用通信量が約366MB以上の場合当日21時から翌日2時まで制限」という方にひっかかっているものと思われます。測定が1回づつしかやってない件については、面倒だからなんですが、数値見てもらえばわかるように1回で十分に誤差ではない有意な差が出ているので問題ないかと思います。実際体感してみればわかりますけどとんでもない差なので・・・。記事中にも書きましたが公表された帯域制限にひっかかっている状態の話です。プロトコルによって帯域制限かけるのは、古くはP2Pなどで遮断はダメだけど帯域制限ならOKという方向で概ね世の中落ち着いているようなので、キャリアは真っ当な対応をしていると個人的には思ってます(ただ、帯域制限は僕の契約時には存在せず、後から導入されたものなのでキャリアとしてもあまり強く制限できない事情もあるのかもしれません)。一方でサービス提供者やアプリ開発者の立場からはすごく迷惑なので仕様を明確にしてユーザーに分かるようにしておいてほしいですね。・MIMEタイプの変更は本当にやるひとはあまり居ないと思いますが、普通のWebサイトだったらやっぱ止めたほうがいいと思います。一方で、スマホなどのアプリ内でzipでアーカイブしたアプリ内データをHTTP使ってダウンロードするなんて仕様にしていると、「このアプリだけクソ遅いので星ひとつです。金返せ」とか書かれかねないので本当に注意が必要です。アプリ側を変更しないで今すぐできる対策としてはやっぱMIMEタイプ変更は、けっこういいアイデアかと思ったんですけど。どちらにしても、これからは「IPネットワークもはや透過的ではない」と思ってアプリケーション開発をしないといけないってことですね。04:29最近「ComicGlassのソートがWindowsの並びと違う」とご意見を頂きました。WindowsXP以降ではファイル名のソート順が数値などを解釈する自然な並びになるようになっています。よって単純なコードの比較とは違う結果になります。説明されるのは、20string2string3stringというソート順だったのが2string3string20stringという感じになることでしょうか。WindowsであればStrCmpLogicalW()というAPIを呼び出すとこのソートが行われます。Windows以外の環境でこのソートを再現する方法は、検索するといくつか提案されていますが、どうも結果が違います。公式な仕様が見つかればいいんですが、どうも見つかりません。そこで、それを再現すべくそもそもWindowsがどのようにソートしているか実験してみました。(特に海外のサイトの情報はUnicode文字に関する配慮がほとんどされてない事が多いので)結論から言うと、StrCmpLogicalWを再現するのって無理ゲーなんじゃないかと・・・。いい方法あったら是非教えてください。以下調査結果でございます。・StrCmpLogicalWは記号、数値、その他文字の順で並ぶASCIIやUnicodeでは「!」は「0~9」より前にあるが「;」などは数値より後です。Windowsでは「;」などの記号も数値より前に並びます。(Unicodeコード順)!test.txt0test.txt;test.txt(Windows)!test.txt;test.txt0test.txtというわけで、その文字が「記号」であるか「数値」であるか「その他文字」であるかを区別しているようです。そこで問題になるのが、何が記号で何が記号でないか。★(記号にならない一例)1⁄4Àうーん。プログラムを組んでStrCmpLogicalWで実際に試してみたのですが、かなり後ろの方のコードまで記号扱いになるものとと文字扱いになるものが入り乱れています。Unicodeコンソーシアムが規定するUNICOD文字一覧表に記号かどうかの情報があるようです。Unicodeとして記号かどうかで判断されており、それは規則性などなく全一覧を知らないとどうにもならない。・・・しかし!Windowsが知らない新しいUnicodeは正しく解釈していないような気がします・・・。U+2639(☹)、U+263A(☺)、U+263B(☻)は記号扱いですが、その他顔文字は記号になりません。したらWindowsではサロゲートペアが正しく処理されていないだけかもしれません・・・。これは心が折れますね・・・!・StrCmpLogicalWは全角の記号も半角と記号と同じ扱いになる同じ記号の場合は全角の方が後になる。・・・ってことは正準等価性を使った正規化してるんでしょうかね?その説を支持する結果として「»」が「§」よりも前に並ぶんですよね。後述しますが、数値で混在すると別々に評価されるっぽい。単純に先に正規化しても駄目と・・・。・StrCmpLogicalWは数字が並んでいる場合はまとめて1つの意味付けがされる0001.txt2.txt003.txtこれはファイルに0から順に名前つけて桁が増えた時に変な順番になるのを防げます。・StrCmpLogicalWは20桁以上の数値は数値として扱わない符号なし64bitで表せる値の最大値は18,446,744,073,709,551,616で20桁なので、20桁目からオーバーフローします。よって、Windowsも64bit演算で扱える最大値の19桁まで取り扱うようになっていると思われます。これは実装が楽で助かります。・StrCmpLogicalWは全角の0~9も数字として扱われる・ただし半角全角混在の場合はそうならない。情報求む・・・・!とりあえずASCIIコードにある記号だけ記号として解釈し、数値は19桁まで数値として認識する、という方法でだいたい近い結果にはなります。23:16娘が小学校1年生になりました。みえるね!”という男の子が出てくるのですが娘はこれに納得しないのです。「四角にはならない」と言うのですが・・・うん、僕にも四角には見えない。円柱は立体物で、「四角に見える」とか「円に見える」と言うには平面に投影した結果を言っています。3次元の形状を2次元に投影する方法はいくつかありますが、目でみる場合には「透視投影」を行うことになります。要するに遠くのものは小さく見えるし、近くのものは大きく見えます。視点を変換して横から見てみます。これが四角に見えるためには無限の距離から見なければなりません。無限の距離にあるものなんて大きさが限りなく0なので見えません。図面のように平行射影すれば円柱の側面は四角に見えるかもしれませんが、目で見たら絶対四角にはならないんですよね。問題の意図としては正射影したらどんな形かと言いたいんだとは思いますが、正射影を説明するのも難しいし・・と思ったけど、「遠くから見たら四角っぽくなるでしょ」というファジーな説明でなんとなく理解してくれたみたいです。