NSString UIKit AdditionsにあるsizeWithFont:は、文字列を指定フォントで表示した時の表示サイズを求めるメソッドとされている。
ところがこれ、横幅は正しいのだが、縦幅は正しくないことがある。
表示幅が取得値(size.height)より大きいことがあるのだ。
どのような場合にそうなるか。
指定フォントが英字フォントで、文字列に日本語を含む場合がそれに当たる。
この場合、英字部分は指定フォントが使われるが、日本語に関しては代替フォントが使われる。
例えば、標準的フォントとしてよく使われるHelveticaは英字フォントであり、実は日本語は含まない。それでも日本語も表示できるのは、この代替機能があるからだ。絵文字もこの機能によって、どのフォントでも表示できるようになっている。
（フォントが実際のところどの文字コードに相当するフォントを持っているかは、FontBookで情報を見ると分る。）
そして、殆どの場合その代替フォントのほうが大きいので、高さがそちらに合わせられる。
このため、実表示サイズが取得値と合わなくなる。
sizeWithFontが返してくるのは指定したフォントのlineHeightであり、文字列に含まれるすべての文字を考慮した高さではないのだ。
その代替となっている日本語フォントのlineHeightを得ておけばいいと思うかもしれないが、それがそう単純ではなく、実際に表示される文字だけのフォント幅に合わせられる。
よって、表示文字列が固定ならいいが、文字列が可変なら高さも可変になる。
ということで、現在出来る回避策は、実際に表示させてみるしかない。
例えばUITextView.textに「改行付きで」代入し、その前後でcontentSize.heightの
差分を取る。これなら正確に取得できる。
ただし、.textへの代入の処理はかなり重いので、すべての行の高さを得ようと思うなら、ちょっと工夫が必要である。
アップルは英語圏なので、こういう日英文字混在の条件下ではデバッグされていないのだろう。iOS5.1でも治っていない。iOS6でどうかは未検証。
2012/09/25追記
drawAtPointの返してくる高さも同様と判明。横幅はなぜかちょっと違う。
sizeWithFontの方が小数点以下を切り上げた幅を返してきている感じ。
あと、ひょっとしたらこの問題はUITextView内に表示した時だけに発生するのかもしれない。UITextViewないならフォントの高さなんて気にしなくていいのではないかと思われるかもしれないが、外部表示との同期をかけようとすると問題になる。
それがどういうことかは、次回アプリを見てもらえばわかるかと。
2013/09/29追記
1年ぶりの追記。実はiOS7では contentSize.heightの返す値が全く意味不明になっておりこの方法が使えなくなってしまった。現状回避策は見つかってない。
2012年9月14日金曜日
2012年9月1日土曜日
Macのゴミ箱の中の消えないファイルの消し方
Macで「ゴミ箱を空にする」を実行しても消せないファイルが残ることがある。
（不要になった）TimeMachineのフォルダを削除したときなど、boot.efiというファイルにロックがかかっていて、情報からアクセス権を変更してロックを外そうにも外せず、
この状態になる。
こういう時は、Optionキーを押しながら「ゴミ箱を空にする」を実行すればよい。
たったこれだけで綺麗サッパリ消してくれる。
（不要になった）TimeMachineのフォルダを削除したときなど、boot.efiというファイルにロックがかかっていて、情報からアクセス権を変更してロックを外そうにも外せず、
この状態になる。
こういう時は、Optionキーを押しながら「ゴミ箱を空にする」を実行すればよい。
たったこれだけで綺麗サッパリ消してくれる。
2012年8月18日土曜日
Xcode 4.4.1とMoutainLion V10.8.1のバグ
MacOSがMountainLionになってXcodeもV4.4.1が出た。
が、いつものごとく幾つものバグがあった。
（１）Finderからのドロップでプロジェクトにファイルを追加すると、コンパイル対象にならない
ファイルはあるはずなのにリンクが通らないという謎の現象が発生し、調査の結果がこれ。
プロジェクトのところでマウス右クリックのAdd File Toを使った場合はこうはならない。
ファイルがあるのにリンクが通らないとエラーが出る場合はこれが原因。
一旦Delete→Remove ReferenceしてからAdd File Toをやり直せばよい。
コンパイル対象でないファイルの追加にはドロップも使える(画像とか)。
（２）エディタで「Open in eparate Assistant Editor」で分割表示しているとき、
右側（Assistant Editor側）で単語補完候補がすぐ消えてしまう
入力がかなり面倒になる。
入力を続けていると、一時的に治ることもある。
（３）リアルタイムエラー検出で使うソースを間違える
例えば
proj-+--a.m,a.h
+-lib--a.m,a.h
と同じファイル名のソース(.m/.h)が2箇所にあり、proj直下のファイルをプロジェクトにAddしていて、libはフォルダごと登録しているが、この2つのファイルは登録してないとする。
この時、本来lib下のファイルは無視されなければならないが、これがエラー検出に使われる。ソースを見ても絶対にあってるのに警告が出るときは、同一ファイルが複数箇所にないか確認したほうがいい。
これで一体どれだけ無駄なデバッグさせられたか。
同じファイル名のソースが複数出来てしまうのもバグ(に近い仕様)で、プロジェクトにAddするときコピーを作ってしまうとか、グループ間移動をした時ときに発生すると考えられる。
（４）iOS4.x用シミュレーターがないのはバグに近い仕様だと思う。
Device Debugging SupportはiOS3/4用ともまだあるが、シミュレーターは消えている。
まだあるじゃろうiOS4機。それとももう無視していいというお達しなのか？
仕方ないので、うちではVMware Fusion上にLionを構築してXcode4.3.2を復旧させた。
まさかこういう使い出があるとは。->だめ。一旦プロジェクトをXcode4.4用にしてしまうと4.3.2ではエラーが出てしまう。4.3.3にしたら通った。
（５）同名のグループが複数作れてしまう
多分、New Groupで作成したものとドラッグでフォルダごと入れた場合に出来るのだと思う。
（６）IBでClassを変更しても内部的に更新されないことがある。
サブクラスを作ってそれに変更したのに、正しく動作しない。
Cleanかけてもだめ。
結局そのViewを一旦削除して再度貼り付けたら直った。
参照するファイルを間違えるのと同じ原因ではないかと推察中。
（７）ソースコードを修正してもそれをコンパイラが認識しないことがある
発生させる一例。
１．あるメソッドの引数を変更する
２．それを使っている部分で警告が出るようになる
３．その部分を引数付きに書き換える。ただし、エラーが出るようする(間違えておく)
４．メソッドの引数を元に戻す
５．エラーが出ている行も引数を削除し、エラーが出ないようにする
としても、エラーが消えない。コンパイルしなおしてもダメ。
Cleanをかけたら消えた。
別の条件で発生したときはCleanをかけてもダメで、プロジェクトを一旦閉じて再度開いて、更に再ビルドでようやく直った。
幾つかの現象から、どうも、4.4.1にはソースの修正を正しく認識できないバグがいる模様。どうしてもおかしいと思ったら、Cleanをかけてみるか、プロジェクトを一旦閉じて再度読み直すか、IBなら一旦削除して貼り付け直しするのが吉。
（８）Settings.bundle内を編集し続けているとハングアップすることがある
2回発生したから確実かと。
（９）日本語名ファイルがGitで通らない
コミット時にエラーが出る。
コンソールからgitのコマンドを発行するとちゃんといけるので、
Xcode内のgit処理のバグだと思われる。ずっと前のバージョンから治ってない。
(10)gitの管理下にあるファイルで、編集していないのに「M」マークが付くことがある。
しかも、しばらくすると勝手に消えるという謎付き。
実害はない。
・・・
V4.3台で存在した「実機をつないでデバッグしているとき、NSLog()の中に日本語があると文字化けする」バグは「ほぼ」修正された模様。一度に大量に表示させると、まだときおり/???というUnicode形式で表示されることがある。
アップルは、毎度のことながらデバッグが全く足りてない。
この分だと、もうすぐ出てくるiOS6もすぐには対応作業しないほうが吉かも。
どうせバグだらけだろうから。
「アップルのソフトはバージョンアップがあってから入れるのが正解」。
・・・
ついでに、MountainLion(v10.8/10.8.1)のバグも少々。
・省エネルギー設定でコンピューターのスリープを「しない」にしっていしても
勝手にスリープしてしまう。スリープと言うより、アプリを終了してスタンバイ状態に
入ろうとする。
2時間くらいで落ちる気がする。
このため、一晩中処理を走らせ続けたいと思っても出来ない。
（スタンバイになる前にアプリの終了を確認しており、ここで処理が停止してしまうから。）
->これは、「使用しない状態が？分間続いたらログアウト」の設定によると判明。「セキュリティーとプライバシー」〜「一般」〜「詳細」の内にあり。
・画面共有で接続されているとき、ホスト側からスリープに入るよう操作してもスリープしない
要するに遠隔からスリープさせられないということ。だめじゃん。
10.8.1では治っていた。
やっぱり治ってない。
ログイン画面のスリープを押してもスリープしない。
その後ログインしてスリープをかけてもスリープしない。
どうも、ログイン画面でスリープを押すとおなしくなる様子。
・ネット先のドライブが応答しない時、リセットがかかってしまう
エラーも出ずに急に再起動した。
・USBディスプレイドライバのDIsplayLinkDriver V1.8を入れているとスリープできなくなる＝スリープ時にシステムが落ちてしまう
→調査の結果、メーカーサイトの中の http://www.displaylink.com/support/ticket.php?id=331 に情報を発見。
要約すると「スリープ中にBluetoothデバイスの電源を切ると落ちる」らしい。
うちの場合、マウスがそれに相当している（手動で電源を切るだけでなく、デバイスが自動的に電源を切る場合も同様）。
これはOS X v10.8のバグで、10.8.1で修正される予定らしい。
「DisplayLinkを入れると露呈する」とある。
ということで、暫く待つしかなさそう。
→10.8.1では治っていることを確認。
・共有にしているフォルダの内容が更新されないことがある
ファイル削除したらそうなる感じなので、ファイル削除後のディレクトリエントリ作成周りにバグがいると思われる。
・Windows(7)とのファイル共有ができなくなった
今のところ、Win←Macはできているが、逆はできない。
画面共有はLion時はできなくなっていたが、MountainLionでは出来るようになったのに、
更に利用頻度が高いファイル共有ができなくなってどうするよ。
→出来る機体と出来ない機体が存在する。ということで、何かの設定だと思うのだけど、原因は不明。Mac間のファイル共有は出来てる。
→ようやく原因が判明。セキュリティとプライバシー」の設定で「ファイヤーウォール」〜「ファイヤーウォールオプション」〜「smbd」〜「外部からの接続をブロック」を「許可」に直したら治った。
こんなところいじった覚えはないので、10.8.1で勝手に設定されたと思う。
・スリープ明けにEthernetでつないでいるネットワークが切れてしまうことがある
省エネ設定の時間を過ぎて自動スリープに入った時に発生する。
ケーブルの抜き差しでは復旧せず、再起動するしかない。かなり致命的なバグ。
V10.8.3では発生頻度がかなり下がったが、まだ出る。
手動でスリープに入れたときは発生しにくいが、長時間スリープした後だと別症状で発生する。ただし、再度手動スリープして再起動すると治ったこともある。
V10.8.2で直った模様。まだ２回だけでの結果なので、もう少し様子見。
V10.8.2でも発生。IPv6では接続できているがV4では接続できない。
うちのプロバイダはｖ６を通さないのでインターネット接続ができなくなる。
WiFiでは発生しない。
・DVDプレイヤーで、話の切り替わり目で数秒〜数分が飛んでしまうことがある。
例えば1話目が終わり、2話目が始まるとき、2話目の最初しばらくが飛ぶ。
すべてのディスクではないが、かなり高い確率で発生する。
SnowLeopard/Lionでは発生していなかったので、MoutainLion版のみのバグ。
10.8.1で確認しているが、10.8.0がどうだったかは不明。
ちなみに、Mac go社のMac Bru-ray Playerでは発生しない。
（それはそれで他の問題が多すぎて常用しづらいのだけど。)
10.8.3では発生していないような気がする。
・フリーウエアのMacFaceが動かない
対応版は出そうにない。まあ、必須ソフトではないけど。
・同muCommander v0.9.0が「ファイルが壊れてる」と出て実行できない(Lionでは動く)
10.8.1でも変わらず。
→「セキュリティーとプライバシー」〜ダウンロードしたアプリケーションの実行許可を「すべてのアプリケーションを許可」にすると実行可能と判明。
しかし、「実行できません」ならわかるけど「ファイルが壊れてる」というのはエラーメッセージが間違っているとしか思えない。
・ロジクールマウスの特殊ボタンが効かなくなった
ドライバーを更新しようにも、日本サイトにあるドライバはMountainLionには対応してない。米国サイト http://www.logitech.com/en-us/home で検索するとMountainLion対応の最新版がある。メッセージ英語のみになってしまうが、まあ、簡単だから問題ないかと。とありあえず日本語版が出てくるまでのつなぎはこれでOK。
・落ちる頻度はLion(10.7.4)より多い
まだ不安定な部分がある様子。
１ファイルへの多重アクセスをすると落ちやすいような気がする。
落ちるというか、無反応になってしまう。
Xcodeでタグ上に残っているファイルをDelete-Move trashとかすると一発。
とにかく、デバッグ要員を１０倍くらい増やせ、アップル。新機能より安定性重視。
特に企業に入って行く気ならそれは非常に重要(その気はないのかもしれないが)。
が、いつものごとく幾つものバグがあった。
（１）Finderからのドロップでプロジェクトにファイルを追加すると、コンパイル対象にならない
ファイルはあるはずなのにリンクが通らないという謎の現象が発生し、調査の結果がこれ。
プロジェクトのところでマウス右クリックのAdd File Toを使った場合はこうはならない。
ファイルがあるのにリンクが通らないとエラーが出る場合はこれが原因。
一旦Delete→Remove ReferenceしてからAdd File Toをやり直せばよい。
コンパイル対象でないファイルの追加にはドロップも使える(画像とか)。
（２）エディタで「Open in eparate Assistant Editor」で分割表示しているとき、
右側（Assistant Editor側）で単語補完候補がすぐ消えてしまう
入力がかなり面倒になる。
入力を続けていると、一時的に治ることもある。
（３）リアルタイムエラー検出で使うソースを間違える
例えば
proj-+--a.m,a.h
+-lib--a.m,a.h
と同じファイル名のソース(.m/.h)が2箇所にあり、proj直下のファイルをプロジェクトにAddしていて、libはフォルダごと登録しているが、この2つのファイルは登録してないとする。
この時、本来lib下のファイルは無視されなければならないが、これがエラー検出に使われる。ソースを見ても絶対にあってるのに警告が出るときは、同一ファイルが複数箇所にないか確認したほうがいい。
これで一体どれだけ無駄なデバッグさせられたか。
同じファイル名のソースが複数出来てしまうのもバグ(に近い仕様)で、プロジェクトにAddするときコピーを作ってしまうとか、グループ間移動をした時ときに発生すると考えられる。
（４）iOS4.x用シミュレーターがないのはバグに近い仕様だと思う。
Device Debugging SupportはiOS3/4用ともまだあるが、シミュレーターは消えている。
まだあるじゃろうiOS4機。それとももう無視していいというお達しなのか？
仕方ないので、うちではVMware Fusion上にLionを構築してXcode4.3.2を復旧させた。
まさかこういう使い出があるとは。->だめ。一旦プロジェクトをXcode4.4用にしてしまうと4.3.2ではエラーが出てしまう。4.3.3にしたら通った。
（５）同名のグループが複数作れてしまう
多分、New Groupで作成したものとドラッグでフォルダごと入れた場合に出来るのだと思う。
（６）IBでClassを変更しても内部的に更新されないことがある。
サブクラスを作ってそれに変更したのに、正しく動作しない。
Cleanかけてもだめ。
結局そのViewを一旦削除して再度貼り付けたら直った。
参照するファイルを間違えるのと同じ原因ではないかと推察中。
（７）ソースコードを修正してもそれをコンパイラが認識しないことがある
発生させる一例。
１．あるメソッドの引数を変更する
２．それを使っている部分で警告が出るようになる
３．その部分を引数付きに書き換える。ただし、エラーが出るようする(間違えておく)
４．メソッドの引数を元に戻す
５．エラーが出ている行も引数を削除し、エラーが出ないようにする
としても、エラーが消えない。コンパイルしなおしてもダメ。
Cleanをかけたら消えた。
別の条件で発生したときはCleanをかけてもダメで、プロジェクトを一旦閉じて再度開いて、更に再ビルドでようやく直った。
幾つかの現象から、どうも、4.4.1にはソースの修正を正しく認識できないバグがいる模様。どうしてもおかしいと思ったら、Cleanをかけてみるか、プロジェクトを一旦閉じて再度読み直すか、IBなら一旦削除して貼り付け直しするのが吉。
（８）Settings.bundle内を編集し続けているとハングアップすることがある
2回発生したから確実かと。
（９）日本語名ファイルがGitで通らない
コミット時にエラーが出る。
コンソールからgitのコマンドを発行するとちゃんといけるので、
Xcode内のgit処理のバグだと思われる。ずっと前のバージョンから治ってない。
(10)gitの管理下にあるファイルで、編集していないのに「M」マークが付くことがある。
しかも、しばらくすると勝手に消えるという謎付き。
実害はない。
・・・
V4.3台で存在した「実機をつないでデバッグしているとき、NSLog()の中に日本語があると文字化けする」バグは「ほぼ」修正された模様。一度に大量に表示させると、まだときおり/???というUnicode形式で表示されることがある。
アップルは、毎度のことながらデバッグが全く足りてない。
この分だと、もうすぐ出てくるiOS6もすぐには対応作業しないほうが吉かも。
どうせバグだらけだろうから。
「アップルのソフトはバージョンアップがあってから入れるのが正解」。
・・・
ついでに、MountainLion(v10.8/10.8.1)のバグも少々。
・省エネルギー設定でコンピューターのスリープを「しない」にしっていしても
勝手にスリープしてしまう。スリープと言うより、アプリを終了してスタンバイ状態に
入ろうとする。
->これは、「使用しない状態が？分間続いたらログアウト」の設定によると判明。「セキュリティーとプライバシー」〜「一般」〜「詳細」の内にあり。
・画面共有で接続されているとき、ホスト側からスリープに入るよう操作してもスリープしない
要するに遠隔からスリープさせられないということ。だめじゃん。
やっぱり治ってない。
ログイン画面のスリープを押してもスリープしない。
その後ログインしてスリープをかけてもスリープしない。
どうも、ログイン画面でスリープを押すとおなしくなる様子。
・ネット先のドライブが応答しない時、リセットがかかってしまう
エラーも出ずに急に再起動した。
・USBディスプレイドライバのDIsplayLinkDriver V1.8を入れているとスリープできなくなる＝スリープ時にシステムが落ちてしまう
→調査の結果、メーカーサイトの中の http://www.displaylink.com/support/ticket.php?id=331 に情報を発見。
要約すると「スリープ中にBluetoothデバイスの電源を切ると落ちる」らしい。
うちの場合、マウスがそれに相当している（手動で電源を切るだけでなく、デバイスが自動的に電源を切る場合も同様）。
これはOS X v10.8のバグで、10.8.1で修正される予定らしい。
「DisplayLinkを入れると露呈する」とある。
ということで、暫く待つしかなさそう。
→10.8.1では治っていることを確認。
・共有にしているフォルダの内容が更新されないことがある
ファイル削除したらそうなる感じなので、ファイル削除後のディレクトリエントリ作成周りにバグがいると思われる。
・Windows(7)とのファイル共有ができなくなった
今のところ、Win←Macはできているが、逆はできない。
画面共有はLion時はできなくなっていたが、MountainLionでは出来るようになったのに、
更に利用頻度が高いファイル共有ができなくなってどうするよ。
→出来る機体と出来ない機体が存在する。ということで、何かの設定だと思うのだけど、原因は不明。Mac間のファイル共有は出来てる。
→ようやく原因が判明。セキュリティとプライバシー」の設定で「ファイヤーウォール」〜「ファイヤーウォールオプション」〜「smbd」〜「外部からの接続をブロック」を「許可」に直したら治った。
こんなところいじった覚えはないので、10.8.1で勝手に設定されたと思う。
・スリープ明けにEthernetでつないでいるネットワークが切れてしまうことがある
省エネ設定の時間を過ぎて自動スリープに入った時に発生する。
ケーブルの抜き差しでは復旧せず、再起動するしかない。かなり致命的なバグ。
V10.8.3では発生頻度がかなり下がったが、まだ出る。
V10.8.2でも発生。IPv6では接続できているがV4では接続できない。
うちのプロバイダはｖ６を通さないのでインターネット接続ができなくなる。
WiFiでは発生しない。
・DVDプレイヤーで、話の切り替わり目で数秒〜数分が飛んでしまうことがある。
例えば1話目が終わり、2話目が始まるとき、2話目の最初しばらくが飛ぶ。
すべてのディスクではないが、かなり高い確率で発生する。
SnowLeopard/Lionでは発生していなかったので、MoutainLion版のみのバグ。
10.8.1で確認しているが、10.8.0がどうだったかは不明。
ちなみに、Mac go社のMac Bru-ray Playerでは発生しない。
（それはそれで他の問題が多すぎて常用しづらいのだけど。)
10.8.3では発生していないような気がする。
・フリーウエアのMacFaceが動かない
対応版は出そうにない。まあ、必須ソフトではないけど。
・同muCommander v0.9.0が「ファイルが壊れてる」と出て実行できない(Lionでは動く)
10.8.1でも変わらず。
→「セキュリティーとプライバシー」〜ダウンロードしたアプリケーションの実行許可を「すべてのアプリケーションを許可」にすると実行可能と判明。
しかし、「実行できません」ならわかるけど「ファイルが壊れてる」というのはエラーメッセージが間違っているとしか思えない。
・ロジクールマウスの特殊ボタンが効かなくなった
ドライバーを更新しようにも、日本サイトにあるドライバはMountainLionには対応してない。米国サイト http://www.logitech.com/en-us/home で検索するとMountainLion対応の最新版がある。メッセージ英語のみになってしまうが、まあ、簡単だから問題ないかと。とありあえず日本語版が出てくるまでのつなぎはこれでOK。
・落ちる頻度はLion(10.7.4)より多い
まだ不安定な部分がある様子。
１ファイルへの多重アクセスをすると落ちやすいような気がする。
落ちるというか、無反応になってしまう。
Xcodeでタグ上に残っているファイルをDelete-Move trashとかすると一発。
とにかく、デバッグ要員を１０倍くらい増やせ、アップル。新機能より安定性重視。
特に企業に入って行く気ならそれは非常に重要(その気はないのかもしれないが)。
2012年8月9日木曜日
UTF8とSHIFT-JISの判別し方
UTF8はUTF16を算術演算して一定のコード範囲に収めるようにした文字コードである、らしい。
実際のところ、以下の5つパターンに収束する。
(1)c2～df+80～bf 2バイト
(2)e0～ef+80～bf+80～bf 3バイト
(3)f0～f7+80～bf +80～bf +80～bf 4バイト
(4)f8～fb+80～bf +80～bf +80～bf +80～bf 5バイト
(5)fc～fd+80～bf +80～bf +80～bf +80～bf +80～bf 6バイト
UTF8データ群中では、先頭のバイトで長さがわかる。
逆に後ろからでも順次読んでいけばその文字の先頭がわかるのは、ASCIIコードは0x00～0x7eなので、重複部がないからである。
SHIFT-JISは
第1バイトは
（あ）0x80～0x9f
（い）0xe0～0xef (JISのどの水準までサポートするかで変化することがある)
第2バイトは
（A)0x40～0x7e
（B)0x80～0xfc
なので、2バイト目がASCIIと重複する部分がある。
このため、逆側からの読み出しでは正しく文字を認識できない。
また、SHIFT-JISのファイルには1バイト半角カタカナも入っている可能性も高いので、
0xa0(0xa1)～0xdf
のコードも存在する。UTF8中には1バイト半角カタカナはない。
そういう状況でのUTF8とSHIFT-JISの識別の仕方。
前から順に読んでいって、上記(3)～(5)のパターン、すなわち0xf0～0xfdが出てきたらUTF8で即確定できる。
逆に、（あ）が出てきたらSHIFT-JIS。UTF8では（あ）のコードはいきなり出てこないから。
0xa0～0xc1が出てきたときは、半角カタカナなのでSHIFT-JIS。
ここまでの識別でもまだわからないのが
(1)と(2)
である。この部分の完全な判別はできない。
しかし、確率論的には推測できる。
（2）のコードはSHIFT-JISでも存在しうるが、その範囲は第二水準であり、
しかも次の1バイトが第1水準及び半角カタカナとなるため、事実上その並びが
普通のファイルで出てくることはほとんどありえないと考えていいだろう。
だからここはUTF8。
残りは（1）。
0xc2～0xdfは半角カタカナと重複するからここだけでは判別できない。
2バイト目が0x80～0x9fならSHIFT-JISの第1バイトかもしれない。
したがって、この先を更に読み続け、どちらかの文字コード範囲として矛盾が
出てきた時点でその可能性を排除する、という方法しかない。
ただし、場合によっては、UTF8とSHIFT-JISの双方でありえる可能性もある。
ということで、完全自動の文字コード認識は不可能という話。
基本自動、読めなかったら手動で、という風にしておく必要があるわけである。
X−BASIC for iOSではコード範囲を限定しているので、全自動。
実際のところ、以下の5つパターンに収束する。
(1)c2～df+80～bf 2バイト
(2)e0～ef+80～bf+80～bf 3バイト
(3)f0～f7+80～bf +80～bf +80～bf 4バイト
(4)f8～fb+80～bf +80～bf +80～bf +80～bf 5バイト
(5)fc～fd+80～bf +80～bf +80～bf +80～bf +80～bf 6バイト
UTF8データ群中では、先頭のバイトで長さがわかる。
逆に後ろからでも順次読んでいけばその文字の先頭がわかるのは、ASCIIコードは0x00～0x7eなので、重複部がないからである。
SHIFT-JISは
第1バイトは
（あ）0x80～0x9f
（い）0xe0～0xef (JISのどの水準までサポートするかで変化することがある)
第2バイトは
（A)0x40～0x7e
（B)0x80～0xfc
なので、2バイト目がASCIIと重複する部分がある。
このため、逆側からの読み出しでは正しく文字を認識できない。
また、SHIFT-JISのファイルには1バイト半角カタカナも入っている可能性も高いので、
0xa0(0xa1)～0xdf
のコードも存在する。UTF8中には1バイト半角カタカナはない。
そういう状況でのUTF8とSHIFT-JISの識別の仕方。
前から順に読んでいって、上記(3)～(5)のパターン、すなわち0xf0～0xfdが出てきたらUTF8で即確定できる。
逆に、（あ）が出てきたらSHIFT-JIS。UTF8では（あ）のコードはいきなり出てこないから。
0xa0～0xc1が出てきたときは、半角カタカナなのでSHIFT-JIS。
ここまでの識別でもまだわからないのが
(1)と(2)
である。この部分の完全な判別はできない。
しかし、確率論的には推測できる。
（2）のコードはSHIFT-JISでも存在しうるが、その範囲は第二水準であり、
しかも次の1バイトが第1水準及び半角カタカナとなるため、事実上その並びが
普通のファイルで出てくることはほとんどありえないと考えていいだろう。
だからここはUTF8。
残りは（1）。
0xc2～0xdfは半角カタカナと重複するからここだけでは判別できない。
2バイト目が0x80～0x9fならSHIFT-JISの第1バイトかもしれない。
したがって、この先を更に読み続け、どちらかの文字コード範囲として矛盾が
出てきた時点でその可能性を排除する、という方法しかない。
ただし、場合によっては、UTF8とSHIFT-JISの双方でありえる可能性もある。
ということで、完全自動の文字コード認識は不可能という話。
基本自動、読めなかったら手動で、という風にしておく必要があるわけである。
X−BASIC for iOSではコード範囲を限定しているので、全自動。
2012年8月1日水曜日
UTF8とSHIFT-JISコードの特徴
UTF8<->16の変換関数を書いたので、UTF<->SHIFT-JISの変換関数も公開したいところだが、それは出来ない。
なぜかというと、出し惜しみじゃなくて、文字コードにおいて、UTFとSHIFT-JISの間に算術的相関関係がないからである。
(一部のコード範囲を除き)基本的には、１：１で変換テーブルを作るしかないのだ。
だから、変換処理を公開すると言うことはそのテーブルを公開することに等しく、
SHIFT-JISの文字数を考えたら、それは現実的ではない。高速化を考慮するなら、
交互の変換にはそれぞれ別テーブルが必要となるのでなおさらである。
実際に、全ての対応表を載せているHPがあったりするが、その表示はかなり重い。
・・・
さて、X-BASIC for iOSの開発でUTF-8の文字コード(正確には文字エンコード、らしいけど)についてかなりだいぶ理解できたと思う。
SHIFT-JISに関してはその誕生時から見ていて、X1-ｔurboからX68000、さらには
多くの組み込み機器にも処理を実装してきた。日本でもトップクラスの理解者である、と自負してたりする(^_^;)。
なもんで、両方のコードを理解した今となっては、怖いもん無しである(^_^;;)
いや、それは冗談として、 UTF-8の特徴を少し説明。
UTF-8は、JISコードに対するSHIFT-JISのような物で、UTF16に対して算術演算をかけることでコード範囲を限定している。
双方の特徴をまとめると以下のようになる。
SHIFT-JIS
・前から読まないと正しいコードが得られない
・しかしそれさえ守れば、ASCIIコードと混在可能
・ASCII用に書かれた処理の多くは、簡単な2バイトコード判定の追加するだけで流用可能
・基本的に見た目のバイト数と文字コードのバイト数が一致する
X68000の1/2角・1/4角文字など、例外も存在した（まあその範囲はそもそもJIS規定外だが)。
・第2水準漢字までが2バイトで収まる(第3水準以降は知らない)
・JISコード（＝連続コード)と算術演算による交互変換が可能なため、漢字フォントの位置を求めるのが楽。
JISコード並びの文字フォントはフリーで多数出回っているため、 無償で漢字を表示できるシステムを構築できる(読みやすさは別にして)。
・JISコード第1水準漢字は音読みで並べられているため、音読み漢字変換なら比較的簡単に実装できる
UTF8
・前からだけでなく後ろからでも正しい文字コードを得られる
・そのままASCIIコードとの混在が可能
・しかもASCII用に書かれた処理の多くがそのまま使える
・見た目のバイト数と文字コードのバイト数が一致しない
・第2水準漢字まででも3バイト以上になることがある(というか2バイトで収まる範囲は少ない)
どちらがいいというのではなく、目的さえ間違えなければ、どちらもよく考えられたコードだと言える。が、SHIFT-JISは組み込み機器で使うに有益な特徴を持ったコードで、UTF8はOS上で英語圏発祥の処理を多国語化するに良いコードだと言えよう。
UTF８については次回もう少し解説。
なぜかというと、出し惜しみじゃなくて、文字コードにおいて、UTFとSHIFT-JISの間に算術的相関関係がないからである。
(一部のコード範囲を除き)基本的には、１：１で変換テーブルを作るしかないのだ。
だから、変換処理を公開すると言うことはそのテーブルを公開することに等しく、
SHIFT-JISの文字数を考えたら、それは現実的ではない。高速化を考慮するなら、
交互の変換にはそれぞれ別テーブルが必要となるのでなおさらである。
実際に、全ての対応表を載せているHPがあったりするが、その表示はかなり重い。
・・・
さて、X-BASIC for iOSの開発でUTF-8の文字コード(正確には文字エンコード、らしいけど)についてかなりだいぶ理解できたと思う。
SHIFT-JISに関してはその誕生時から見ていて、X1-ｔurboからX68000、さらには
多くの組み込み機器にも処理を実装してきた。日本でもトップクラスの理解者である、と自負してたりする(^_^;)。
なもんで、両方のコードを理解した今となっては、怖いもん無しである(^_^;;)
いや、それは冗談として、 UTF-8の特徴を少し説明。
UTF-8は、JISコードに対するSHIFT-JISのような物で、UTF16に対して算術演算をかけることでコード範囲を限定している。
双方の特徴をまとめると以下のようになる。
SHIFT-JIS
・前から読まないと正しいコードが得られない
・しかしそれさえ守れば、ASCIIコードと混在可能
・ASCII用に書かれた処理の多くは、簡単な2バイトコード判定の追加するだけで流用可能
・基本的に見た目のバイト数と文字コードのバイト数が一致する
X68000の1/2角・1/4角文字など、例外も存在した（まあその範囲はそもそもJIS規定外だが)。
・第2水準漢字までが2バイトで収まる(第3水準以降は知らない)
・JISコード（＝連続コード)と算術演算による交互変換が可能なため、漢字フォントの位置を求めるのが楽。
JISコード並びの文字フォントはフリーで多数出回っているため、 無償で漢字を表示できるシステムを構築できる(読みやすさは別にして)。
・JISコード第1水準漢字は音読みで並べられているため、音読み漢字変換なら比較的簡単に実装できる
UTF8
・前からだけでなく後ろからでも正しい文字コードを得られる
・そのままASCIIコードとの混在が可能
・しかもASCII用に書かれた処理の多くがそのまま使える
・見た目のバイト数と文字コードのバイト数が一致しない
・第2水準漢字まででも3バイト以上になることがある(というか2バイトで収まる範囲は少ない)
どちらがいいというのではなく、目的さえ間違えなければ、どちらもよく考えられたコードだと言える。が、SHIFT-JISは組み込み機器で使うに有益な特徴を持ったコードで、UTF8はOS上で英語圏発祥の処理を多国語化するに良いコードだと言えよう。
UTF８については次回もう少し解説。
2012年7月25日水曜日
UTF8-16変換処理の抜け
先に発表したUTF8-16変換処理でdefine関数の部分の定義が抜けていたので公開。
#define b32(w) (((w)&0xff000000)>>24) #define b24(w) (((w)&0x00ff0000)>>16) #define b16(w) (((w)&0x0000ff00)>> 8) #define b8(w) ( (w)&0x000000ff) #define w16(h,l) (((h)<<8 data-blogger-escaped-define="define" data-blogger-escaped-hh="hh" data-blogger-escaped-hl="hl" data-blogger-escaped-l="l" data-blogger-escaped-lh="lh" data-blogger-escaped-ll="ll" data-blogger-escaped-pre="pre" data-blogger-escaped-w16="w16" data-blogger-escaped-w24="w24" data-blogger-escaped-w32="w32">
2012年7月20日金曜日
UTF16をUTF8に変換する処理
今度はUTF16をUTF8に変換する処理。
実を言うと、UTF16はあまり使い道がない。と思う。
->とか書いてたけど、実はiOSの中の文字コードはUTF16だと判明。
characterAtIndexで返ってくるコードはUTF16である。
UTF8だと思って処理を書いてたらうまく動かないので調べたらそうだった。
(後日アップルのドキュメントを読み返したら、UTF16だとちゃんと書いてあった。
でも、あんなところに１行だけでは気が付く人少ないのでは？)
ただし、ソースコード(その中に記述する文字列)そのものはUTF8でなくてはならない。
ここは少しややこしいところ。
SHIFT-JISは、組み込み機器ではプログラムもデータも小さくなるので非常に使いやすい。
表示幅とバイト数が一致するのもいい点である。
UTF8はASCIIコードとの互換性が高く、ASCII用のプログラムを移植するに都合がいいことが、X-BASIC for iOSの開発でよくわかった。
SHIFT-JISとの変換に関してはUTF16の方が行いやすい。
実を言うと、UTF16はあまり使い道がない。と思う。
->とか書いてたけど、実はiOSの中の文字コードはUTF16だと判明。
characterAtIndexで返ってくるコードはUTF16である。
UTF8だと思って処理を書いてたらうまく動かないので調べたらそうだった。
(後日アップルのドキュメントを読み返したら、UTF16だとちゃんと書いてあった。
でも、あんなところに１行だけでは気が付く人少ないのでは？)
ただし、ソースコード(その中に記述する文字列)そのものはUTF8でなくてはならない。
ここは少しややこしいところ。
SHIFT-JISは、組み込み機器ではプログラムもデータも小さくなるので非常に使いやすい。
表示幅とバイト数が一致するのもいい点である。
UTF8はASCIIコードとの互換性が高く、ASCII用のプログラムを移植するに都合がいいことが、X-BASIC for iOSの開発でよくわかった。
SHIFT-JISとの変換に関してはUTF16の方が行いやすい。
ulong Utf16ToUtf8(ulong n)
// http://ja.wikipedia.org/wiki/UTF-8 参照
// Unicodeは文字コードの総称で、UTF-16やUTF-8はその表現方法の種類、である。
{
if (n<=0x7f) return(n); // ASCII互換
if (n<=0x7ff) {
// 8421 8421 8421 8421
// 110x_xxxx | 10xx_xxxx
return w16( (0xc0|(n>>6)) , (0x80|(n&0x3f)) );
}
if (n<=0xffff) {
// 8421 8421 8421 8421 8421 8421
// 1110_xxxx | 10xx_xxxx | 10xx_xxxx
return w24( (0xe0|((n>>12)&0x0f)) , (0x80|((n>>6)&0x3f)) , (0x80|(n&0x3f)) );
}
// n<=0x1fffff
// 8421 8421 8421 8421 8421 8421 8421 8421
// 1111_0xxx | 10xx_xxxx | 10xx xxxx | 10xx xxxx
return w32( (0xf0|((n>>18)&0x07)) , (0x80|((n>>12)&0x3f)) , (0x80|((n>>6)&0x3f)) , (0x80|(n&0x3f)) );
// 定義上はこれ以上もあるが、実在しないので省略
}
2012年7月14日土曜日
UTF8の文字コードをUTF16に変換する処理
しばらく忙しすぎて更新できてなかった。
理由は、どスランプとか開発作業とか。
中核の処理は動くようになったが、まだiOSへの対応については手つかず。
ずっとWindowsのCygwin上で開発してたので、Xcodeも忘れてしまった(^_^)。
まずはその思い出しから始めないと。
ということで、超久しぶりの更新は、そのプログラム中で使っている処理を１つ。
UTF8の文字コードをUTF16に変換する処理。
ただし、UTF8で32ビットの範囲に収まるコードのみ。
UTFまわりの処理はインターネットで探しても 意外と見つからない。
最近はOSや言語レベルでサポートされているようで、
Cでの記述、というかフローが正確にわかる物が無かった。
ということで、公開。
理由は、どスランプとか開発作業とか。
中核の処理は動くようになったが、まだiOSへの対応については手つかず。
ずっとWindowsのCygwin上で開発してたので、Xcodeも忘れてしまった(^_^)。
まずはその思い出しから始めないと。
ということで、超久しぶりの更新は、そのプログラム中で使っている処理を１つ。
UTF8の文字コードをUTF16に変換する処理。
ただし、UTF8で32ビットの範囲に収まるコードのみ。
UTFまわりの処理はインターネットで探しても 意外と見つからない。
最近はOSや言語レベルでサポートされているようで、
Cでの記述、というかフローが正確にわかる物が無かった。
ということで、公開。
ulong Utf8ToUtf16(ulong b)
{
if (b<=0xff) return(b); // ASCII
if (b<=0xffff) {
return ( (b16(b) & 0x1f) << 6) + (b8(b) & 0x3f);
}
return ( ((b24(b) & 0xf) << 12) + ((b16(b) & 0x3f) << 6) + (b8(b) & 0x3f) );
}
2012年4月30日月曜日
C言語；ポインターの増減
C言語のポインターに対する演算の結果について。
しばらく使わないと忘れてしまうので覚え書き。
long *lp=0;
short *wp=0;
char *cp=0;
としたとき、それぞれを++した時の実アドレスは、
lp++ == 4
wp++== 2
cw++== 1
である。
同様に、
&lp[1]のアドレスは4
&wp[1]のアドレスは2
&bp[1]のアドレスは1
である。
同じ演算子でも、ポインターの型によって得られる実アドレスが異なる。
アセンブラーでアドレスを演算する場合にも変化が伴うことがあるが、
Cとは結果が違う。
たとえば680x0MPUでは、
a0.l=0のとき、
move.l d0,(a0)+ → a0=4
move.w d0,(a0)+ → a0=2
move.b d0,(a0)+ → a0=1
であるが、
move.l d0,4(a0)
move.w d0,4(a0)
move.b d0,4(a0)
はいずれも4番地からにデータを書き込む。
自動インクリメント(またはデクリメント)は大きさを考慮するが、オフセット指定は
大きさは関係ないと言うことである。
通常加算は大きさを考慮しないので、
addq.l #1,a0
addq.w #1.a0
はいずれもa0=1となる。
アセンブラとC言語の両方に精通していると、C言語におけるポインターの演算結果を
迷うことがあったりするので、注意。
しばらく使わないと忘れてしまうので覚え書き。
long *lp=0;
short *wp=0;
char *cp=0;
としたとき、それぞれを++した時の実アドレスは、
lp++ == 4
wp++== 2
cw++== 1
である。
同様に、
&lp[1]のアドレスは4
&wp[1]のアドレスは2
&bp[1]のアドレスは1
である。
同じ演算子でも、ポインターの型によって得られる実アドレスが異なる。
アセンブラーでアドレスを演算する場合にも変化が伴うことがあるが、
Cとは結果が違う。
たとえば680x0MPUでは、
a0.l=0のとき、
move.l d0,(a0)+ → a0=4
move.w d0,(a0)+ → a0=2
move.b d0,(a0)+ → a0=1
であるが、
move.l d0,4(a0)
move.w d0,4(a0)
move.b d0,4(a0)
はいずれも4番地からにデータを書き込む。
自動インクリメント(またはデクリメント)は大きさを考慮するが、オフセット指定は
大きさは関係ないと言うことである。
通常加算は大きさを考慮しないので、
addq.l #1,a0
addq.w #1.a0
はいずれもa0=1となる。
アセンブラとC言語の両方に精通していると、C言語におけるポインターの演算結果を
迷うことがあったりするので、注意。
2012年4月11日水曜日
Windows7のデスクトップガジェットの強制的な削除仕方
Windows7でデスクトップガジェットを使っているとき、まれにその起動が出来なくなることがある。
ガジェット内部でエラーを発生してしまうと、そのエラーを起こしたガジェットだけでなく、登録している全てが落ちてしまうようだ。うちでは、IO-DATAのDrive Centerがこの状態になって往生した。
いったんこうなってしまうと、コントロールパネルのデスクトップガジェットも開けなくなり、通常ではどうしようもなくなる。
この場合、
c:\Users\ユーザー名\AppData\Local\Microsoft\Windows Sidebar
にあるSettings.iniをテキストエディタで開き、エラーを起こしていると思われるガジェットの設定を削除する。
削除対象は、[Root]タグ内にある
Section?="?"
というセクション名の登録、
[Hashes]タグ内にあるプログラムの登録と、
[Section?]タグの内容そのものである。
念のため、編集前にはバックアップをとっておいた方が良いであろう。
また、同\Gadgets\の下にガジェットのプログラム本体(のフォルダ)があるので、場合によってはそのフォルダも削除する。
いや、ガジェットが落ちるようになってしまったけど、解決に関する情報がどこにもなくて、
いろいろやっている内に発見した。同様なことで困ったいる人がいたら、どうぞ。
ガジェット内部でエラーを発生してしまうと、そのエラーを起こしたガジェットだけでなく、登録している全てが落ちてしまうようだ。うちでは、IO-DATAのDrive Centerがこの状態になって往生した。
いったんこうなってしまうと、コントロールパネルのデスクトップガジェットも開けなくなり、通常ではどうしようもなくなる。
この場合、
c:\Users\ユーザー名\AppData\Local\Microsoft\Windows Sidebar
にあるSettings.iniをテキストエディタで開き、エラーを起こしていると思われるガジェットの設定を削除する。
削除対象は、[Root]タグ内にある
Section?="?"
というセクション名の登録、
[Hashes]タグ内にあるプログラムの登録と、
[Section?]タグの内容そのものである。
念のため、編集前にはバックアップをとっておいた方が良いであろう。
また、同\Gadgets\の下にガジェットのプログラム本体(のフォルダ)があるので、場合によってはそのフォルダも削除する。
いや、ガジェットが落ちるようになってしまったけど、解決に関する情報がどこにもなくて、
いろいろやっている内に発見した。同様なことで困ったいる人がいたら、どうぞ。
2012年3月22日木曜日
Xcode4.3.2のバグ修正のチェック結果
ようやく公開されたので、現在調査中。
・・・
なんかうまく動かない。
V4.3.2自体が正常動作しない上に、V4.2.1までも動かなくなってしまった。
ということで、全部再インストールする羽目に。
アップルはいったいどういうチェックをしているのだ?
クリーンインストールの機体だけしかチェックしていないのではなかろうか?
→なんかまたインストールされ方が変わってる。
・・・
再インストール後チェック。
(1)iPadシミュレーターの枠がない(HOMEボタンが表示されない)のは仕様
(2)[[UIDevice currentDevice]systemVersion]が@"Unknown”を返してくるバグは修正された
(3) ビルトインマクロ__VERSION__は"4.2.1～"のまま。
"4.2.1 Compatible Apple Clang 3.1～"になってる
(4)実機をつないでデバッグしているとき、NSLog()の中に日本語があると文字化けするバグは修正されていない。
(5)日本語ファイル名があるとgitでcommit出来ないバグは修正されていない
(6)OrganizerのArchivesでアプリのアイコンが表示されないバグは修正された
(7)DistributionのCodeSigningが外れるバグは修正された
(8)シミュレーター上のUITextView/UITextFieldで落ちるバグは修正された
(9)WiFi接続のデバイスの検出機構(iOS Device DiscoverryのSupport Wirelessly Connected Devices)がなくなった
問題が多かったから？
ということで、重大なバグは修正された模様。一応開発に使えるレベルには戻った。
でも全てのバグは直ってない。
早よ直してくれ。
・・・
なんかうまく動かない。
V4.3.2自体が正常動作しない上に、V4.2.1までも動かなくなってしまった。
ということで、全部再インストールする羽目に。
アップルはいったいどういうチェックをしているのだ?
クリーンインストールの機体だけしかチェックしていないのではなかろうか?
→なんかまたインストールされ方が変わってる。
・・・
再インストール後チェック。
(1)iPadシミュレーターの枠がない(HOMEボタンが表示されない)のは仕様
(2)[[UIDevice currentDevice]systemVersion]が@"Unknown”を返してくるバグは修正された
(3) ビルトインマクロ__VERSION__は"4.2.1～"のまま。
"4.2.1 Compatible Apple Clang 3.1～"になってる
(4)実機をつないでデバッグしているとき、NSLog()の中に日本語があると文字化けするバグは修正されていない。
(5)日本語ファイル名があるとgitでcommit出来ないバグは修正されていない
(6)OrganizerのArchivesでアプリのアイコンが表示されないバグは修正された
(7)DistributionのCodeSigningが外れるバグは修正された
(8)シミュレーター上のUITextView/UITextFieldで落ちるバグは修正された
(9)WiFi接続のデバイスの検出機構(iOS Device DiscoverryのSupport Wirelessly Connected Devices)がなくなった
問題が多かったから？
ということで、重大なバグは修正された模様。一応開発に使えるレベルには戻った。
でも全てのバグは直ってない。
早よ直してくれ。
2012年3月17日土曜日
methods named 'xxx' found
プログラムを組んでいると、「methods named 'xxx' found」という警告がいくつか出た。
直訳すると「xxxという名前のメソッドが複数見つかった」となろうが、
それならエラーになるはずではないか。
よくよく調べると、id型のクラスインスタンスに対してメソッドを発行しようとすると
発生する（ことがある）とわかった。
「例」
タッチイベントを処理する
-(void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
NSTimeInterval tm=[[touches anyObject]timestamp]; // ここでmethods named 'timestamp' foundが発生する
}
touchesに実際に格納されるのはUITouchであるが、[touches anyobject]はid型で返す。
timestampという名前のメソッドは複数のクラスが持つので、
どれか解決できずに警告が出てしまう。
実行時にはNSSetの内容は決定しているので、[touches anyobject]のidが実際は何であるか、
この場合UITouchであることがわかっているのでtimestampを呼び出す先もわかる＝実行時エラーはでないのである。
警告を回避するには
NSTimeInterval tm=[(UITouch *)[touches anyObject]timestamp];
として型を確定してやればよい。ポインター型でキャストすることに注意。
Xcodeのエラーコードはわかりにくい(その上ドキュメントがない)ので困る。
直訳すると「xxxという名前のメソッドが複数見つかった」となろうが、
それならエラーになるはずではないか。
よくよく調べると、id型のクラスインスタンスに対してメソッドを発行しようとすると
発生する（ことがある）とわかった。
「例」
タッチイベントを処理する
-(void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
NSTimeInterval tm=[[touches anyObject]timestamp]; // ここでmethods named 'timestamp' foundが発生する
}
touchesに実際に格納されるのはUITouchであるが、[touches anyobject]はid型で返す。
timestampという名前のメソッドは複数のクラスが持つので、
どれか解決できずに警告が出てしまう。
実行時にはNSSetの内容は決定しているので、[touches anyobject]のidが実際は何であるか、
この場合UITouchであることがわかっているのでtimestampを呼び出す先もわかる＝実行時エラーはでないのである。
警告を回避するには
NSTimeInterval tm=[(UITouch *)[touches anyObject]timestamp];
として型を確定してやればよい。ポインター型でキャストすることに注意。
Xcodeのエラーコードはわかりにくい(その上ドキュメントがない)ので困る。
2012年3月16日金曜日
The new iPad
「The new iPad」が届いたのでちょいと感想など。
Xcodeでつなぐと「iPad (3rd generation)」と表示される。
なら「iPad3」でいいじゃん、と思ったりもするのだが、
まあ、こだわりがあるのだろう。
で、ちょっと触ってみた感じのiPad2との違い。
そんなところ。
Xcodeでつなぐと「iPad (3rd generation)」と表示される。
なら「iPad3」でいいじゃん、と思ったりもするのだが、
まあ、こだわりがあるのだろう。
で、ちょっと触ってみた感じのiPad2との違い。
- 文字がきれい。これは今回の一番の売りのRetinaDisplay(解像度倍)だから当然だけど、目に優しく感じる。
- iPhoneモードの2倍表示がきれい。従来のiPadにもiPhoneモード2倍表示はあったけど、単純拡大で文字はがたがただった。これが改良されたのか非常にきれいになった。iOS5の改良項目かと思ったが、iPad2では今まで通りだったので、3の特徴と言える。
- 音が良く聞こえるようになった。スピーカーの位置は同じだけど、音ははっきりしている。スピーカーそのものが良い物になったか。
- グラフィックを使う処理にもたつきがなくなった。iPad用のゲームで少々もたつきがあったゲームが、3では全くもたつかない。3はCPUの能力はほぼ同じだが、解像度倍に合わせてグラフィックの能力があげられているので、iPad解像度のゲームは恩恵を受けてこうなっているようだ。3専用ゲームではそうはいかんだろうけど。
- 背面カメラの画像が格段に良くなった。PCの画面を撮影しても今までは文字が読めなかったが、3でははっきり読める。ただ、モアレの発生はかなりきつい。
- 重さは、カタログ上は初代iPadと同じに戻ったらしいが、手に持った感じではiPad2と変わらなく思う。
多分に、厚みが変わっていないからだと思う。 - 外観上の違いはほとんどない(だからここにも写真を載せなかった)。あえて言うなら、背面カメラのレンズ径が倍くらい大きくなったのと、規格適合マークが大きく変わったことくらいか(iPad2はVCCIなど国内規格マークだったが、3はFCCやCEなど海外規格のみになっている)。両方持っている人は、自分でわかりやすいようにシールでも貼った方が良いかもしれない。
そんなところ。
2012年3月11日日曜日
開発用実機の接続について
Xcodeで開発用実機を「USBケーブルで」接続する場合、
本体のUSB端子もしくはそこに差したUSBハブからでなければならない。
USBハブにさらにハブをつなぎ、そこに差したケーブルで実機を接続すると認識してくれない「ことがある」。してくれることもあるが、不安定。
USBハブの種類というか構造にもよると思うけど。
Xcode4.2ではWiFi接続も出来るけど、また使ったことがない。
どんなもんだろうか？
→Xcode4.3.2ではWiFi接続機能は削除された。
本体のUSB端子もしくはそこに差したUSBハブからでなければならない。
USBハブにさらにハブをつなぎ、そこに差したケーブルで実機を接続すると認識してくれない「ことがある」。してくれることもあるが、不安定。
USBハブの種類というか構造にもよると思うけど。
Xcode4.2ではWiFi接続も出来るけど、また使ったことがない。
どんなもんだろうか？
→Xcode4.3.2ではWiFi接続機能は削除された。
Lionの壁紙が起動毎に初期化されてしまう・・・ように見える
Lionにしてから、壁紙が起動（またはログイン)毎に初期化されてしまう(Andromeda Galaxyになる)という問題が発生した。
調査の結果、以下のようにすれば解消されると判明。
(1)システム環境設定～デスクトップを開き、各画面に違う壁紙を設定する
そのときの各画面の壁紙名を控えておく
(2)Fiderからライブラリ～Preferences～com.apple.desktop.plistを開く
(3)BackGroundの下にある、0以外の数字だけの項目が画面別壁紙設定 なので、全てを開き、
(1)で 設定した壁紙名「以外」の設定の入っている項目を全て削除(Cut)する
spaces/default/0は消さないこと。
これで直る。
・・・修正。
初期化されたのではなく、表示されるページが変わっていたと判明。
デスクトップを複数用意している場合、背景(バックグラウンド)はデスクトップ毎に設定できる。
そのため、別のページが表示されると背景がおかしくなったように感じる。
上の処理をすると壁紙は戻るが、消したデスクトップに配置していたアプリの画面情報も消えるので注意。
なお、デスクトップの追加はMissionControl表示中、物理画面の右上あたりにマウスカーソルを持って行くと「＋」が出るので、これで行う。
MissionControlは本当にわかりにくいし、操作しにくい。
ExposeとSpacesに戻して欲しい（可能なら切り替えでも良いので両方使えるようにして欲しい)。
ちゃんとユーザーの声を聞け、アップル。
調査の結果、以下のようにすれば解消されると判明。
(1)システム環境設定～デスクトップを開き、各画面に違う壁紙を設定する
そのときの各画面の壁紙名を控えておく
(2)Fiderからライブラリ～Preferences～com.apple.desktop.plistを開く
(3)BackGroundの下にある、0以外の数字だけの項目が画面別壁紙設定 なので、全てを開き、
(1)で 設定した壁紙名「以外」の設定の入っている項目を全て削除(Cut)する
spaces/default/0は消さないこと。
これで直る。
・・・修正。
初期化されたのではなく、表示されるページが変わっていたと判明。
デスクトップを複数用意している場合、背景(バックグラウンド)はデスクトップ毎に設定できる。
そのため、別のページが表示されると背景がおかしくなったように感じる。
上の処理をすると壁紙は戻るが、消したデスクトップに配置していたアプリの画面情報も消えるので注意。
なお、デスクトップの追加はMissionControl表示中、物理画面の右上あたりにマウスカーソルを持って行くと「＋」が出るので、これで行う。
MissionControlは本当にわかりにくいし、操作しにくい。
ExposeとSpacesに戻して欲しい（可能なら切り替えでも良いので両方使えるようにして欲しい)。
ちゃんとユーザーの声を聞け、アップル。
2012年3月9日金曜日
Xcode4.3.1のバグ
iOS5.1の公開に合わせてXcodeも4.3.1(Lion専用)が公開された。
が、早速問題が多数出ている。
太字は重大なバグ。
(1)iPadシミュレーターでHOMEボタンが表示されない。
Retinaだと50％表示にしても縦1080でも枠付き表示しきれないからだと思われる。
外枠自体表示されないので、仕様変更であろう。
iOS4.x/5.xどちらも同じになってる。
メニューバーのハードウエア～ホームで押下をシミュレートできるが、
ホームダブルタップによるアプリ切り替えが出来なくて困る。
アプリの削除もやりにくい。
iPhoneシミュレーターはHOMEありで変更なし。
(2)シミュレーター上で[[UIDevice currentDevice]systemVersion]が@"Unknown”を返してくる。
実機では問題ないが、シミュレーターではデバイスまたはOSバージョンを変えても変化なし。
4.2.0まではちゃんとシミュレーターに設定したOSバージョンが返ってきてた。
バージョンチェックして動作を変えている場合、シミュレーター上では問題が出る。
なんかおかしいから調べてみて気がついた。
今のところ回避策が見当たらないので非常に困ってる。
→info.plistに独自キーを追加してそこにバージョンを「毎回打ち込んで」読み込ませることで、
当面回避。
なんていう手間。 やり方は1つ前の記事を参照のこと。早速役立った。
(3)ビルトインマクロ__VERSION__が"4.2.1～"になっている。
だめじゃん。
(4)シミュレーター上動作中でアプリがハングアップして落ちた場合、二度とシミュレーター上でアプリが実行できなくなることがある。
その状態でも実機ではデバッグできた。
シミュレーターのiPhone/iPadおよびバージョンを変えても改善しない。
シミュレーターおよびXcodeを再起動しても だめ。Mac自体を再起動してようやく復帰。
新しいデバッガーlldbのバグかも知れない。
1回だけ発生した。
(5)エディタで編集内容表示が消えてしまうことがある
スクロールすると戻る（ソースそのものには影響なし）。
2～3回発生。
(6)Xcode4.0.xほどではないが、遅くなった。
検索前とかビルド前にマウスカーソルが回る。
(Snapshotはとってないのに。)
せっかくv4.2.0で速くなったのに(4.1.0からだったかも) 。
→Lion自体の問題
(7)writeToFileがエラーを発生することがある
これはXcodeのバグではないが、LionではSnowLeopardとファイルアクセス権限の設定が異なっているため、これが出る。
デバッグ中の中間ファイルが書き出されなくて調べてたらこれとわかった。writeToFile:@"ファイル名だけ"という書き方をしているとまずだめ。
フォルダを厳密に指定し、そこのアクセス権限を読み書き可能に設定していなければならない。
(8)シミュレーターでiOS5.0以上を選択したとき、UITextFieldおよびUITextViewをタップするとEXC_BAD_ACCESSで落ちる
自分のプログラムの問題かと思って調べ、その後Apple提供のサンプル「HelloWorld」で試したらこれも落ちる。そのくせ実機で動作させたらあっさり動いた。丸1日調査してたのがばからしい結果。100％再現する。
重大なバグ。これらを使っている場合、実機でしか動作確認できない状況。
なお、iOS4.xのシミュレーターではINVARID dictionaryというのが出てるが、一応動作には問題ない。
Xcode4.2.0まででは発生していない。
(9)実機をつないでデバッグしているとき、NSLog()の中に日本語があると文字化けする。
シミュレーターでは問題ない。環境設定のフォント設定の間違い、なんてこともない。
これは実機OSが4.3でも5.1でも同じに発生する。
(10)日本語ファイル名があるとgitでcommit出来ない
V4.2.0でも有ったバグ。直されてない。
最初からわかってれば全て英語ファイル名にしたんだけど、後からgit管理下に入れたもんで。 フリーのGitXを使えばOK。
(11)OrganizerのArchivesでアプリのアイコンが表示されない
(12)DistributionのCodeSigningが外れる
ファイルそのものが消えていた。再設定が必要。
しかも、それがArchiveを作るときにはわからず、アップロードするときにわかる。
さらに、そのアップロード時のエラーメッセージも変更されたのでわかりにくい。
(13)[UIColor colorWithPatternImage:]にもバグがあるらしい(未確認)
V4.2.0にあった他のバグの内、大問題だったSettingBundleが編集できないバグはさすがに修正されてるが、他は未確認。
とにもかくにも問題が多すぎて困る。問題が出るたびに調査に時間がかかってしまう。
V4.2.0に戻そうとしたが、Xcode4.2.0(Build 4C199)/4.1.0はLion上では動かない。
仕方ないので、もう1台有るMacのSnowLeopard上に4.2.0で開発環境を再構築することにしたが、メインマシンではないのでいつもそちらで開発するのはつらい。
Appleには猛省をして欲しい。
毎度のことながら、とにかくデバッグが足りなすぎ。いじる理由がないのに、
前のバージョンまで正常に動いてたところが動かなくなるのも多い。
儲かってるんだから、デバッグ要員を増やせ。
一応(10)まではAppleのフィードバック(http://www.apple.com/jp/feedback/)で報告はしておいたが、フィードバックの項目にXcodeがないのはどういうもんだか（OSで報告した)。Xcodeのバグ報告は受け付けないってか？
それともXcodeは全く別の場所にフィードバックがある?→developperのXcodeダウンロードの一番下にあったのね（Submit Bugs to Apple）。出し直した方が良いのか?
また、Xcodeの最新版はまだSnowLopard上でもサポートして欲しい。
Lionには画面共有とかまだ不具合があるから。せめてMountainLionが出て安定するまで。
OSのサポート、およびOS間のアプリ動作互換性はMicrosoftを大いに見習って欲しい。（ほぼ）無意味な下位互換切り捨てはやめてくれ。
が、早速問題が多数出ている。
太字は重大なバグ。
(1)iPadシミュレーターでHOMEボタンが表示されない。
Retinaだと50％表示にしても縦1080でも枠付き表示しきれないからだと思われる。
外枠自体表示されないので、仕様変更であろう。
iOS4.x/5.xどちらも同じになってる。
メニューバーのハードウエア～ホームで押下をシミュレートできるが、
ホームダブルタップによるアプリ切り替えが出来なくて困る。
アプリの削除もやりにくい。
iPhoneシミュレーターはHOMEありで変更なし。
(2)シミュレーター上で[[UIDevice currentDevice]systemVersion]が@"Unknown”を返してくる。
実機では問題ないが、シミュレーターではデバイスまたはOSバージョンを変えても変化なし。
4.2.0まではちゃんとシミュレーターに設定したOSバージョンが返ってきてた。
バージョンチェックして動作を変えている場合、シミュレーター上では問題が出る。
なんかおかしいから調べてみて気がついた。
今のところ回避策が見当たらないので非常に困ってる。
→info.plistに独自キーを追加してそこにバージョンを「毎回打ち込んで」読み込ませることで、
当面回避。
なんていう手間。 やり方は1つ前の記事を参照のこと。早速役立った。
(3)ビルトインマクロ__VERSION__が"4.2.1～"になっている。
だめじゃん。
(4)シミュレーター上動作中でアプリがハングアップして落ちた場合、二度とシミュレーター上でアプリが実行できなくなることがある。
その状態でも実機ではデバッグできた。
シミュレーターのiPhone/iPadおよびバージョンを変えても改善しない。
シミュレーターおよびXcodeを再起動しても だめ。Mac自体を再起動してようやく復帰。
新しいデバッガーlldbのバグかも知れない。
1回だけ発生した。
(5)エディタで編集内容表示が消えてしまうことがある
スクロールすると戻る（ソースそのものには影響なし）。
2～3回発生。
(6)Xcode4.0.xほどではないが、遅くなった。
検索前とかビルド前にマウスカーソルが回る。
(Snapshotはとってないのに。)
せっかくv4.2.0で速くなったのに(4.1.0からだったかも) 。
→Lion自体の問題
(7)writeToFileがエラーを発生することがある
これはXcodeのバグではないが、LionではSnowLeopardとファイルアクセス権限の設定が異なっているため、これが出る。
デバッグ中の中間ファイルが書き出されなくて調べてたらこれとわかった。writeToFile:@"ファイル名だけ"という書き方をしているとまずだめ。
フォルダを厳密に指定し、そこのアクセス権限を読み書き可能に設定していなければならない。
(8)シミュレーターでiOS5.0以上を選択したとき、UITextFieldおよびUITextViewをタップするとEXC_BAD_ACCESSで落ちる
自分のプログラムの問題かと思って調べ、その後Apple提供のサンプル「HelloWorld」で試したらこれも落ちる。そのくせ実機で動作させたらあっさり動いた。丸1日調査してたのがばからしい結果。100％再現する。
重大なバグ。これらを使っている場合、実機でしか動作確認できない状況。
なお、iOS4.xのシミュレーターではINVARID dictionaryというのが出てるが、一応動作には問題ない。
Xcode4.2.0まででは発生していない。
(9)実機をつないでデバッグしているとき、NSLog()の中に日本語があると文字化けする。
シミュレーターでは問題ない。環境設定のフォント設定の間違い、なんてこともない。
これは実機OSが4.3でも5.1でも同じに発生する。
(10)日本語ファイル名があるとgitでcommit出来ない
V4.2.0でも有ったバグ。直されてない。
最初からわかってれば全て英語ファイル名にしたんだけど、後からgit管理下に入れたもんで。 フリーのGitXを使えばOK。
(11)OrganizerのArchivesでアプリのアイコンが表示されない
(12)DistributionのCodeSigningが外れる
ファイルそのものが消えていた。再設定が必要。
しかも、それがArchiveを作るときにはわからず、アップロードするときにわかる。
さらに、そのアップロード時のエラーメッセージも変更されたのでわかりにくい。
(13)[UIColor colorWithPatternImage:]にもバグがあるらしい(未確認)
V4.2.0にあった他のバグの内、大問題だったSettingBundleが編集できないバグはさすがに修正されてるが、他は未確認。
とにもかくにも問題が多すぎて困る。問題が出るたびに調査に時間がかかってしまう。
V4.2.0に戻そうとしたが、Xcode4.2.0(Build 4C199)/4.1.0はLion上では動かない。
仕方ないので、もう1台有るMacのSnowLeopard上に4.2.0で開発環境を再構築することにしたが、メインマシンではないのでいつもそちらで開発するのはつらい。
Appleには猛省をして欲しい。
毎度のことながら、とにかくデバッグが足りなすぎ。いじる理由がないのに、
前のバージョンまで正常に動いてたところが動かなくなるのも多い。
儲かってるんだから、デバッグ要員を増やせ。
一応(10)まではAppleのフィードバック(http://www.apple.com/jp/feedback/)で報告はしておいたが、フィードバックの項目にXcodeがないのはどういうもんだか（OSで報告した)。Xcodeのバグ報告は受け付けないってか？
それともXcodeは全く別の場所にフィードバックがある?→developperのXcodeダウンロードの一番下にあったのね（Submit Bugs to Apple）。出し直した方が良いのか?
また、Xcodeの最新版はまだSnowLopard上でもサポートして欲しい。
Lionには画面共有とかまだ不具合があるから。せめてMountainLionが出て安定するまで。
OSのサポート、およびOS間のアプリ動作互換性はMicrosoftを大いに見習って欲しい。（ほぼ）無意味な下位互換切り捨てはやめてくれ。
2012年3月6日火曜日
info.plistの読み出し方
プログラム名-info.plistの内容は、通常プログラムから明示的に読み出す必要はないが、
ごくまれに必要になることがある。
その全体の読み出しは、
[[NSBundle mainBundle]infoDictionary]
で行える。
個別キーに対応する値の読み出しは、
[[[NSBundle mainBundle]infoDictionary]objectForKey:@"CFBundleDisplayName"];
のように行う。
ただし、InfoPlist.stringsの内容によるローカライズは反映されていない。
キー名は、Xcodeでinfo.plistを表示して、Keyの桁で右クリック～Show Raw Keys/Vakuesにチェックして表示されるKey名を使う。
ごくまれに必要になることがある。
その全体の読み出しは、
[[NSBundle mainBundle]infoDictionary]
で行える。
個別キーに対応する値の読み出しは、
[[[NSBundle mainBundle]infoDictionary]objectForKey:@"CFBundleDisplayName"];
のように行う。
ただし、InfoPlist.stringsの内容によるローカライズは反映されていない。
キー名は、Xcodeでinfo.plistを表示して、Keyの桁で右クリック～Show Raw Keys/Vakuesにチェックして表示されるKey名を使う。
2012年3月1日木曜日
Windows7 64bitで正常動作するソフト
Windows7 64ビットで動作するソフトについても一応記録。
現行版ではないもののみ。
・・・2013/04/12追記
WindowsXPの公式サポートがあと1年ということで、これから7もしくは8への移行を考える人も多いと思う。
8はおそらくVista同様MSの黒歴史OSになると思うので全くおすすめしない。
操作性が変わりすぎており、混乱を招くこと必死だ。
意外にもXPのソフトが7の64ビット環境下でもそのまま動く。
ハードウエアドライバーはダメなことも多いが、すでに多くのソフトが対応版を出しているので、
入れ替えだけでいけることが多い。
万が一動かなければ、7のPro以上なら仮想XP環境を構築できるので、その上で走らせればよい。
ではあっても、異なるOS、というより別のPCに環境を移行することは、かなり難しい。
特にアプリケーションのライセンスや設定を移行するのは手間がかかる。
引っ越しツールというのもあるが、私はそれで成功した試しがない。
移行後に何かしらの問題が発生するため、手動でやったほうがよほどまし、という結果になったことがほとんど。
専門家に任せるか、時間をかけて、手動で徐々に行うのが吉。
現行版ではないもののみ。
- XM6 v2.06
X68000エミュレーター。意外にも(失礼?)一発動作。
- 楽々はがき2009(JustSystem)
- アレンジOK!素材集(JustSystem)
- はがき さくっとファイリング(コクヨ)
・・・2013/04/12追記
WindowsXPの公式サポートがあと1年ということで、これから7もしくは8への移行を考える人も多いと思う。
8はおそらくVista同様MSの黒歴史OSになると思うので全くおすすめしない。
操作性が変わりすぎており、混乱を招くこと必死だ。
意外にもXPのソフトが7の64ビット環境下でもそのまま動く。
ハードウエアドライバーはダメなことも多いが、すでに多くのソフトが対応版を出しているので、
入れ替えだけでいけることが多い。
万が一動かなければ、7のPro以上なら仮想XP環境を構築できるので、その上で走らせればよい。
ではあっても、異なるOS、というより別のPCに環境を移行することは、かなり難しい。
特にアプリケーションのライセンスや設定を移行するのは手間がかかる。
引っ越しツールというのもあるが、私はそれで成功した試しがない。
移行後に何かしらの問題が発生するため、手動でやったほうがよほどまし、という結果になったことがほとんど。
専門家に任せるか、時間をかけて、手動で徐々に行うのが吉。
2012年2月29日水曜日
UIKitの隠れた仕様
UIFontの情報を得ようと次のようなプログラムを書いた。
が、これが実行時にエラーを出す。
調べると、main()の中に書いているとfontWithNameまたはsystemFontOfSizeでエラーを発生する。
UIApplicationMain()以降に呼び出されるメソッド内、たとえばapplication:didFinishLaunchingWithOptions:の中だと問題ない。
main()中ではインスタンスを作ることそのものがだめなのかと思いきや、NS*では問題ない。
UIKitのインスタンスメソッドはだめなのかも知れない。
まあ、通常main()内に記述することはないはずだが、念のため。
NSLog(@"smallSystemFontSize=%f" ,[UIFont smallSystemFontSize]); NSLog(@"systemFontSize=%f" ,[UIFont systemFontSize]); NSLog(@"buttonFontSize=%f" ,[UIFont buttonFontSize]); NSLog(@"labelFontSize =%f" ,[UIFont labelFontSize]); // この処理をmain()に置くと、なぜか↓がエラーを発生する // UIFont *font = [UIFont systemFontOfSize:96]; UIFont *font = [UIFont fontWithName:@"Times New Roman" size:96]; NSLog(@"capHeight =%f",font.capHeight); NSLog(@"ascender =%f",font.ascender); NSLog(@"descender =%f",font.descender); NSLog(@"lineHeight=%f",font.lineHeight); NSLog(@"pointSize =%f",font.pointSize); NSLog(@"xHeight =%f",font.xHeight);
が、これが実行時にエラーを出す。
調べると、main()の中に書いているとfontWithNameまたはsystemFontOfSizeでエラーを発生する。
UIApplicationMain()以降に呼び出されるメソッド内、たとえばapplication:didFinishLaunchingWithOptions:の中だと問題ない。
main()中ではインスタンスを作ることそのものがだめなのかと思いきや、NS*では問題ない。
UIKitのインスタンスメソッドはだめなのかも知れない。
まあ、通常main()内に記述することはないはずだが、念のため。
2012年2月26日日曜日
MacとWindowsのフォルダの違い
MacでもWindowsでも、ファイルシステムにおける階層化構造のことを「フォルダ」と呼ぶ。
もともとWindows、というかDOSでは「ディレクトリ」と読んでいたが、いつの頃からか「フォルダ」と呼ばせるようになった。Windows95からだったか。
この呼び名の変更は明らかにMacを意識したものだと思われる。
GUI化するとき、「アイコンがフォルダの方が作りやすい」とも、まことしやかに囁かれているが、多分それはこじつけ。
しかし、この２つのOSにおける「フォルダ」の意味合いは大きく異なる。
Windowsにおけるフォルダは単に「ディレクト」の名称変更に過ぎず、機能的差異は全くない。フォルダを１つのファイルとして扱うことはできない。
ところが、Macではフォルダは１つのファイルとして扱うことも出来る。まさしくファイルを束ねる「フォルダ」である。OSまたはアプリによって認識されている特殊フォルダに関しては、通常の方法ではその下のファイルを見ることができなくも出来る。
例えば、Macのアプリケーション実行ファイル名は*.appだと思われがちだが、
実はこれはファイル名ではなくフォルダ名である。CTRL+クリックまたはマウスの右クリックで「パッケージの内容」を選ぶと、その中に入っている実際のファイルが見える。
Macではアプリケーションの削除は.appの削除だけでいいと言われるが、それは実はフォルダごと消せるからである。
このように、１ファイルのように見えるフォルダはXcodeのSettings.bundleなどを初め、いくつも存在する。
Windowsでは既存フォルダと同名フォルダをコピーした場合、フォルダ内のファイルは両方が交じって存在するようになる。
Macでは同じ事をすると、古いフォルダの内容は全て消え、新しいフォルダの内容のみになる。これは、WindowsからMacに移ってきた人が、かならず一度はハマる罠だと思う。
これもフォルダの性格の違いから来ることである。Macにとってはフォルダは複数のファイルを束ねて出来た新しいファイルとほぼ同等であり、上書きはその内容の改変ではなく、フォルダそのものの置き換えを意味するからである。
ということで、どちらかというとWindows側の名称がその実態に合っていないのが問題なので、ここは１つ「ディレクトリ」に戻して欲しいと思う今日この頃。
WindowsとMacではファイルに対する認識も大きく異なると思っているが、それについては後日またまとまったら。
・・・2012/03/09追記
Lionでは「フォルダの結合」と「両方のファイルを保持する」というのが加わった。Windowsと同等になるのは前者。大迷惑OS Lionでの数少ない「改良」と言える項目かと。
もともとWindows、というかDOSでは「ディレクトリ」と読んでいたが、いつの頃からか「フォルダ」と呼ばせるようになった。Windows95からだったか。
この呼び名の変更は明らかにMacを意識したものだと思われる。
GUI化するとき、「アイコンがフォルダの方が作りやすい」とも、まことしやかに囁かれているが、多分それはこじつけ。
しかし、この２つのOSにおける「フォルダ」の意味合いは大きく異なる。
Windowsにおけるフォルダは単に「ディレクト」の名称変更に過ぎず、機能的差異は全くない。フォルダを１つのファイルとして扱うことはできない。
ところが、Macではフォルダは１つのファイルとして扱うことも出来る。まさしくファイルを束ねる「フォルダ」である。OSまたはアプリによって認識されている特殊フォルダに関しては、通常の方法ではその下のファイルを見ることができなくも出来る。
例えば、Macのアプリケーション実行ファイル名は*.appだと思われがちだが、
実はこれはファイル名ではなくフォルダ名である。CTRL+クリックまたはマウスの右クリックで「パッケージの内容」を選ぶと、その中に入っている実際のファイルが見える。
Macではアプリケーションの削除は.appの削除だけでいいと言われるが、それは実はフォルダごと消せるからである。
このように、１ファイルのように見えるフォルダはXcodeのSettings.bundleなどを初め、いくつも存在する。
Windowsでは既存フォルダと同名フォルダをコピーした場合、フォルダ内のファイルは両方が交じって存在するようになる。
Macでは同じ事をすると、古いフォルダの内容は全て消え、新しいフォルダの内容のみになる。これは、WindowsからMacに移ってきた人が、かならず一度はハマる罠だと思う。
これもフォルダの性格の違いから来ることである。Macにとってはフォルダは複数のファイルを束ねて出来た新しいファイルとほぼ同等であり、上書きはその内容の改変ではなく、フォルダそのものの置き換えを意味するからである。
ということで、どちらかというとWindows側の名称がその実態に合っていないのが問題なので、ここは１つ「ディレクトリ」に戻して欲しいと思う今日この頃。
WindowsとMacではファイルに対する認識も大きく異なると思っているが、それについては後日またまとまったら。
・・・2012/03/09追記
Lionでは「フォルダの結合」と「両方のファイルを保持する」というのが加わった。Windowsと同等になるのは前者。大迷惑OS Lionでの数少ない「改良」と言える項目かと。
登録:
投稿 (Atom)