Posted on 2015年7月7日(火) 04:29
最近「ComicGlassのソートがWindowsの並びと違う」とご意見を頂きました。
WindowsXP以降ではファイル名のソート順が数値などを解釈する自然な並びになるようになっています。
よって単純なコードの比較とは違う結果になります。
よく説明されるのは、
20string
2string
3string
というソート順だったのが
2string
3string
20string
という感じになることでしょうか。
WindowsであればStrCmpLogicalW()というAPIを呼び出すとこのソートが行われます。
Windows以外の環境でこのソートを再現する方法は、検索するといくつか提案されていますが、どうも結果が違います。
公式な仕様が見つかればいいんですが、どうも見つかりません。
そこで、それを再現すべくそもそもWindowsがどのようにソートしているか実験してみました。
（特に海外のサイトの情報はUnicode文字に関する配慮がほとんどされてない事が多いので）
結論から言うと、StrCmpLogicalWを再現するのって無理ゲーなんじゃないかと・・・。
いい方法あったら是非教えてください。
とりあえず、以下調査結果でございます。
・StrCmpLogicalWは記号、数値、その他文字の順で並ぶ
ASCIIやUnicodeでは「！」は「０～９」より前にあるが「;」などは数値より後です。
しかしながらWindowsでは「;」などの記号も数値より前に並びます。
（Unicodeコード順）
!test.txt
0test.txt
;test.txt
（Windows）
!test.txt
;test.txt
0test.txt
というわけで、その文字が「記号」であるか「数値」であるか「その他文字」であるかを区別しているようです。
そこで問題になるのが、何が記号で何が記号でないか。
（記号になる例）
!
;
®
µ
§
»
★
（記号にならない一例）
¼
À
うーん。規則性がわからん。
プログラムを組んでStrCmpLogicalWで実際に試してみたのですが、かなり後ろの方のコードまで記号扱いになるものとと文字扱いになるものが入り乱れています。
どうもUnicodeコンソーシアムが規定するUNICOD文字一覧表に記号かどうかの情報があるようです。
つまりUnicodeとして記号かどうかで判断されており、それは規則性などなく全一覧を知らないとどうにもならない。
まぁ、それだけなら全コードの情報を持っておけばいいのですが・・・
・・・しかし！
Windowsが知らない新しいUnicodeは正しく解釈していないような気がします・・・。
例えばU+2639（☹）、U+263A（☺）、U+263B（☻）は記号扱いですが、その他顔文字は記号になりません。
もしかしたらWindowsではサロゲートペアが正しく処理されていないだけかもしれません・・・。
これは心が折れますね・・・！
・StrCmpLogicalWは全角の記号も半角と記号と同じ扱いになる
同じ記号の場合は全角の方が後になる。
・・・ってことは正準等価性を使った正規化してるんでしょうかね？
その説を支持する結果として「»」が「§」よりも前に並ぶんですよね。コードは後ろなのに。
しかし後述しますが、数値で混在すると別々に評価されるっぽい。つまり単純に先に正規化しても駄目と・・・。
・StrCmpLogicalWは数字が並んでいる場合はまとめて１つの意味付けがされる
0001.txt
2.txt
003.txt
これはファイルに0から順に名前つけて桁が増えた時に変な順番になるのを防げます。
・StrCmpLogicalWは20桁以上の数値は数値として扱わない
符号なし64bitで表せる値の最大値は18,446,744,073,709,551,616で20桁なので、20桁目からオーバーフローします。
よって、Windowsも64bit演算で扱える最大値の19桁まで取り扱うようになっていると思われます。
これは実装が楽で助かります。
・StrCmpLogicalWは全角の０～９も数字として扱われる
・ただし半角全角混在の場合はそうならない。何故だ・・。
情報求む・・・・！
とりあえずASCIIコードにある記号だけ記号として解釈し、数値は19桁まで数値として認識する、という方法でだいたい近い結果にはなります。一致はしませんが。
Posted on 2014年10月24日(金) 01:00
タイトルのとおり。
どうも、Windows相手にNetBIOSの名前解決を試みると失敗することがあるようです。
ネットワーク・アナライザで見ると、リクエストは飛んでるのに応答が来ない。
発生条件は不明ですが、テストで変なリクエスト送ったあとに起きやすい気がするけど、何もしてなくても起きる時もある。
理由は不明ですが、一旦失敗するようになると、特定のIPアドレスから発信したものに対して応答が返らなくなる模様・・・。
全くそのままでIPアドレス変えると動くようになります。
このあたりエラーメッセージを簡略化してたので（接続できませんでしたくらいに）、次からメッセージ入れようと思います。
基本ここで失敗はしないと思っていたので。
どうもSMB/CIFS周りはロバスト性に欠けてやっかいですわー。
Windows同士でも調子わるいときありますもんね。
無駄にSMB/CIFS周り（のバッドノウハウ）に詳しくなっていく・・・。
Posted on 2014年10月10日(金) 21:00
ネットワークプログラミングの基本中の基本。socket()関数があります。
（基本すぎて今ではもう直接使う人はいないのかもしれませんが僕は使います。。）
socket()関数は戻り値としてソケットのファイル・ディスクリプタを返します。
このソケットのファイル・ディスクリプタが何故か現代人には勘違いしやすいようで、うっかり0をエラー値だと思い込んでしまいます。socket()はエラーが発生したときには-1を返します。
これがうっかり間違えます。実際0が返ってくることがありますのでたまに動かないという分かりにくい不具合の原因になります。
わかっているのにうっかり間違えた例が以下のような感じです。本当に良く見かけます。自分も間違えますが・・・。
int fd = socket(AF_INET, SOCK_STREAM, 0);
if (fd <= 0) {
// COV_NF_START - we'd need to use up *all* sockets to test this?
startFailureCode = kGTMHTTPServerSocketCreateFailedError;
goto startFailed;
// COV_NF_END
}
おそらくポインタを返す時の失敗はNULLだろう、ハンドルを返すときのエラーは0だろう的な思い込みがあるせいではないかと思います。
WindowsのAPIは成功すると非ゼロを返すという仕様のものが多いので、そういう普段使っている環境での慣れもあるのかも・・・。
ちなみに上記のコードはGoogle Toolbox for Macの一部にありました。
同様に
if(soc){
close(soc);
}
みたいなミスもうっかりやりがちなのでお気をつけください。
Posted on 2014年9月30日(火) 23:40
・・・タイトルのようなソフトをリリースしましたのでお知らせします。
リリースしたのは少し前ですが、記事にしていませんでしたので。
最近のWindowsではソフトウエアでボリュームのミラーが作れるようになり、HDDの故障に備えることができるようになりました。
Windowsのミラーの良いところは何より扱いやすいことです。BIOS画面一切さわる必要ありませんし。
しかし、いざ障害が起きた時にそれを知る手段がイマイチないのが問題でした。
というわけでステータスが変わったらメールするソフト作ってみました。
こちらでございます。
http://arinkosoft.com/download/asvolumestatuschecker/
Posted on 2014年9月19日(金) 16:24
とりあえず速報です。
iPhone6 Plus買いました。
でかいですね。
最初の設定時に気づいたのですが、「拡大モード」というのがあります。
シミュレータにはありませんでした。
その名のとおり、画面の要素全体が大きめになります。
アプリ側でそのような情報は来なかったと思うので、どのように対応しているかと思ったらピクセル数がiPhone6と同じになるようです。
さらにHOME画面も回転しなくなったりなど、まさにiPhone6のようになります。
よって、開発者はiPhone6PlusがあればiPhone6の解像度もテストできますよね。ステキ！
以下が検証結果です。
なんと！
iPhone6 Plusの拡大モードは、ピクセル数はiPhone6と同じですが、画面のscaleが@3x相当になってますね。
つまりまさかの新しいスクリーンサイズが今日新たに判明です！ ステキ！
iPhone 6 シミュレータ
deviceName=x86_64
[UIScreen mainScreen].bounds=(375.000000,667.000000)
[UIScreen mainScreen].scale=2.000000
iPhone 6 Plusシミュレータ
deviceName=x86_64
[UIScreen mainScreen].bounds=(414.000000,736.000000)
[UIScreen mainScreen].scale=3.000000
iPhone 6 実機
deviceName=iPhone7,2
[UIScreen mainScreen].bounds=(375.000000,667.000000)
[UIScreen mainScreen].scale=2.000000
iPhone 6Plus 実機・標準モード
deviceName=iPhone7,1
[UIScreen mainScreen].bounds=(414.000000,736.000000)
[UIScreen mainScreen].scale=3.000000
iPhone 6Plus 実機・拡大モード
deviceName=iPhone7,1
[UIScreen mainScreen].bounds=(375.000000,667.000000)
[UIScreen mainScreen].scale=3.000000 ←New!
Posted on 2014年9月17日(水) 23:30
画面サイズの数字がよくわからなくなるので早見表作りました。
| Model |
論理サイズ |
物理サイズ |
物理/論理比 |
| widthxheight |
比率 |
近似 |
x1 |
x2 |
x3 |
Pixel |
| 4s以前 |
320×480 |
2:3 |
2:3 |
320×480 |
640×960 |
– |
640×960 |
1 |
| 5/5s |
320×568 |
40:71 |
9:16 |
– |
640×1136 |
– |
640×1136 |
1 |
| 6 |
375×667 |
375:667 |
9:16 |
– |
750×1334 |
– |
750×1334 |
1 |
| 6plus |
414×736 |
9:16 |
9:16 |
– |
– |
1242×2208 |
1080×1920 |
約0.870 |
| iPad |
768×1024 |
3:4 |
3:4 |
768×1024 |
1536×2048 |
– |
1536×2048 |
1 |
物理サイズはRetinaモデルのものを書いてます。
iPhoneのx1サイズは3GSが最後ですので、新しいOSのみに対応するなら無いものと考えてOKです。
iPadはiPad mini(初代)がx1です。
iPhone6 Plusのみ論理座標と物理ピクセル数に差があります。
5sを基準として座標を変換するために倍率を計算しました。
（将来に備えてこの数字を直接使うのではなく、内部で計算したほうが幸せになれるとは思いますが）
| Model |
横 |
縦 |
倍率 |
| 横 |
縦 |
だいたい |
| 5/5s |
320 |
568 |
1.0 |
1.0 |
1.0 |
| 6 |
375 |
667 |
1.171875 |
1.17429577465 |
1.173 |
| 6plus |
414 |
736 |
1.29375 |
1.29577464789 |
1.295 |
Posted on 2014年9月8日(月) 23:53
UTF-8って素晴らしいですよね。
unicodeは元々、世界中の全ての文字を16bitで表現するという英語圏以外の人からすればあまりに愚かな試みからスタートしましたが、もちろん破綻。
16bitを使いながら、サロゲートペアを使って16bit以上のコードも表現するようになりました。
結局サロゲートペアが必要な時点でUTF-16は欠点ばかりのものとなってしまいました。
最近よく使われるのはUTF-8です。ASCIIコードと互換性が保ちやすく大変便利ですね。
UTF-8は結局のところUTF-32をシリアライズしただけのものなんですが、へぇよく考えてるなぁという感じなのです。
任意のバイトストリームから混同せずに文字列を取り出せます。
ただ欠点もあって、色々処理をするときに文字ごとに長さが違うので厄介です。
そこでUTF-8から32bit表現（UTF-32)に変換するコードを書いてみました。
プログラムの内部的にはUTF-32を使うと捗りますので。
このようなUTF-8の欠点はサロゲートペアがある時点でUTF-16でも同様なんですが、サロゲートペアはあまり出てこないので無視してしまってる駄目な処理系もあるような気がします。
なお、セキュリティの観点からはUTF-8の冗長表現が問題になることもあります。
本来ASCIIコードである文字でももっと大きなバイス数で表現することが出来てしまうので不正文字チェックを抜けてしまうということです。
例えば0xC0 0xAF(11000000 10101111)は、２バイトのUTF-8として扱うと[101111]の部分がデータになりますので、0x2F(バックスラッシュ）と等価になります。
つまりより小さいバイトのコードは大きなバイト数でも表現出来てしまうため、単純チェックだとすり抜けるということです。
仕様ではこのようなバイト列は不正なUTF-8バイト列としなければなりません。
また5バイトと6バイトのUTF-8も現在ではUnicodeとしては不正とされていますがISO/IEC 10646では存在しています。
以下のコードではそのような不正なUTF-8もそのまま変換します。
unsigned long utf8ToUtf32(unsigned char *input, int *bytesInSequence)
{
unsigned char c1, c2, c3, c4, c5, c6;
*bytesInSequence = 1;
if (!input)
{
return 0;
}
//0xxxxxxx (ASCII) 7bit
c1 = input[0];
if ((c1 & 0x80) == 0x00)
{
return c1;
}
//10xxxxxx high-order byte
if ((c1 & 0xc0) == 0x80)
{
return 0;
}
//0xFE or 0xFF BOM (not utf-8)
if (c1 == 0xfe || c1 == 0xFF )
{
return 0;
}
//110AAAAA 10BBBBBB 5+6bit=11bit
c2 = input[1];
if (((c1 & 0xe0) == 0xc0) &&
((c2 & 0xc0) == 0x80))
{
*bytesInSequence = 2;
return ((c1 & 0x1f) << 6) | (c2 & 0x3f);
}
//1110AAAA 10BBBBBB 10CCCCCC 4+6*2bit=16bit
c3 = input[2];
if (((c1 & 0xf0) == 0xe0) &&
((c2 & 0xc0) == 0x80) &&
((c3 & 0xc0) == 0x80))
{
*bytesInSequence = 3;
return ((c1 & 0x0f) << 12) | ((c2 & 0x3f) << 6) | (c3 & 0x3f);
}
//1111 0AAA 10BBBBBB 10CCCCCC 10DDDDDD 3+6*3bit=21bit
c4 = input[3];
if (((c1 & 0xf8) == 0xf0) &&
((c2 & 0xc0) == 0x80) &&
((c3 & 0xc0) == 0x80) &&
((c4 & 0xc0) == 0x80))
{
*bytesInSequence = 4;
return ((c1 & 0x07) << 18) | ((c2 & 0x3f) << 12) | ((c3 & 0x3f) << 6) | (c4 & 0x3f);
}
//1111 00AA 10BBBBBB 10CCCCCC 10DDDDDD 10EEEEEE 2+6*4bit=26bit
c5 = input[4];
if (((c1 & 0xfc) == 0xf0) &&
((c2 & 0xc0) == 0x80) &&
((c3 & 0xc0) == 0x80) &&
((c4 & 0xc0) == 0x80) &&
((c5 & 0xc0) == 0x80))
{
*bytesInSequence = 4;
return ((c1 & 0x03) << 24) | ((c2 & 0x3f) << 18) | ((c3 & 0x3f) << 12) | ((c4 & 0x3f) << 6) | (c5 & 0x3f);
}
//1111 000A 10BBBBBB 10CCCCCC 10DDDDDD 10EEEEEE 10FFFFFF 1+6*5bit=31bit
c6 = input[5];
if (((c1 & 0xfe) == 0xf0) &&
((c2 & 0xc0) == 0x80) &&
((c3 & 0xc0) == 0x80) &&
((c4 & 0xc0) == 0x80) &&
((c5 & 0xc0) == 0x80) &&
((c6 & 0xc0) == 0x80))
{
*bytesInSequence = 4;
return ((c1 & 0x01) << 30) | ((c2 & 0x3f) << 24) | ((c3 & 0x3f) << 18) | ((c4 & 0x3f) << 12) | ((c5 & 0x3f) << 6) | (c6 & 0x3f);
}
return 0;
}
Posted on 2014年9月2日(火) 23:07
昨日、ComicGlassのアップデートのためiTunes connectにアプリを送信したところ、CFBundleShortVersionStringが無いということで警告が出ました。（警告は出ましたがアップロード自体は受理されてステータスはWaiting For Reviewに）
ComicGlassを最初に作ったのはiOS3の頃です。その時にはCFBundleShortVersionStringが無かったようでxcodeで自動的に作られなかったので今までずっと無いままでした。CFBundleShortVersionString無いなーとは思ってたんですが、バージョンアップのとき変更するの一つでいいし楽だからいいやと放置してました。
前回までは警告出なかったので最近警告が出るようになったんだと思います。
このCFBundleShortVersionStringですが、本来はピリオドで区切った３つの数字を用いるのが正しい表記のようです。10.0.1みたいな感じですね。現在ComicGlassのバージョン表記は7.50といった２数字表記になっているのでいつか改めないといけないかもしれません。警告が出るようになったということは今後厳格にチェックが入る前触れかもしれないので・・・。
なお、現在のところCFBundleShortVersionStringが３数字になっていなくても（7.50.1ではなく7.50とかでも）警告なく通るようです。
新たにアプリ作るときは正しいフォーマットでバージョン番号を付けたほうが良いと思われます。
お気をつけください。
Posted on 2014年7月17日(木) 03:04
Snow Leopardの次から色々と断絶があり、現在のxocdeでSnow Leopard以前で動くバイナリを作ることは出来ません。
iOSについても同様で、iOS4.x以前向けのSDKは現在のxcodeには含まれていません。
もう無視していいかなーと思っていましたが、今だに必要になったのでメモ。
必要なもの
・Mac(MacOSX のバージョンは新しいものでOK）
なお、Snow Leopardが動くMac実機が用意できれば何の問題もありません。普通にそれ使って下さい…。
・Snow Leopardのインストールディスク
・Xcode4.2のインストーラ
Xcode4.2の入手方法
Xcode4.2を入手する方法について困る方がいらっしゃると思います。
Xcode4.2をダウンロードしたことがあるAppleアカウントがあればAppleのサイトから再ダウンロードできます。
（Downloads for Apple Developersのページにて”Xcode 4.2″で検索）
Xcode4.2を購入した事があるか、当時有償で開発者登録しておりXcode4.2をダウンロードしたことがある場合は何の問題もなく再ダウンロードできると思いますが新規アカウントなどでは検索しても出てきません。
実はXcode4は600円の有償販売でした。よって今でも無料ダウンロードは出来ないということになっているようです。
しかも今はもう買えません・・・。
勝手にXcode4.2のインストーラを置いているサイトがあるかもしれませんが、それは違法コピーということになりますのでご注意ください。
アップルさんにはこの際無償公開して欲しいところです。せめて再販売・・・。
現在の環境構築手順
１．VirtualBox（無料）をダウンロードしてMacにインストール
MacはMarvericksで大丈夫です。
２．仮想マシンにSnow Leopardをインストール
特に気をつけることはなく普通にインストールできます。
ちなみにWindowsでやろうとしても無理ですし、ライセンス的にもNGです。
３．Downloads for Apple Developersのページにて”Xcode 4.2″で検索
・・・ここでXcode4.2が出てこなかった方。
大変残念ですが、ログインしているアカウントではXcode4.2はダウンロードできません。
４．Snow LeopardにXcode4.2をインストール
・・・「インストールが失敗しました」。となる場合はソフトウエアアップデートをかけてください。
Appleインストーラの更新がこの時期にかかっており、アップデートしないとインストールに失敗します。
以上です。
新しいxcodeのプロジェクトをXcode4.2で開いたりするとぶっ壊れますのでご注意ください。
また、Xcode4.2で使っていたプロジェクトを新しいXcodeで開いてしまうと、二度とXcode4.2では開けなくなりますのでご注意ください。
Posted on 2014年6月9日(月) 06:05
詳細
後日また詳細に書こうと思いますが、ComicGlassの次バージョンにてSMB2プロトコルへの対応とSMBサーバ機能が利用できるようになりました。
SMB2はWindows Vista以降で利用できるプロトコルでWindowsXP/WindowsServer2003以前で使われていたSMB1の後継プロトコルになります。
現在ほとんどの機器がSMB1に対応して動作していると思いますが、XPのサポート期限も切れ、WindowsServer2003のサポートもまもなく切れますのでSMB2以降が主流になってくるかもしれません。
Windows8以降では高セキュリティ設定をするとSMB1が使えないことがあります。
SMBサーバ機能は、文字通りSMBサーバ（ファイル共有サーバ）として動作する機能です。
WindowsのエクスプローラーからComicGlass内のファイルを読み書きできます。
書き込みはもちろん、読み出しも出来ますし、直接ファイルを開いて確認することも可能になります。
フォルダを内容を含めてコピーしたり、ファイル名をPCから編集することも出来ますのでファイルの管理やバックアップが大変便利になります。
ただし、エクスプローラーで開いたままiPhoneをスリープしたりアプリを終了してしまうとWindows側がタイムアウトするまで困ったことになりますので使い方には少し注意が必要です。
（一応、ファイルへのアクセス中は自動的にiPhoneがスリープしないように実装してあります）
実装について
SMBの実装はVisuality Systems社のCIFS NQを使っています。
製品なので、接続互換性のテストがしっかりされており、（おそらく通信相手の仕様間違いも含めて（例））色々な相手と正しく通信できると思います。
基本用途は組み込み向け製品向け製品なのでiOSに移植するために実装した部分で不具合がある可能性は多分にありますが、とりあえず安定した通信が期待できるのではないかと。
（一応当面は旧独自実装も使えるよう、選択式にしてあります。これまで問題なかったのに問題が起きたという場合には旧設定にしてみてください。そして発生状況を教えて頂けると大変助かります）
次のページ »
