備忘録 - 最新エントリー
もう4、5年前に以下のページにてデザインパターンという物を知った。
AppleScript とデザインパターン
知ったと言ってもデザインパターンという言葉を覚えたというだけで、それ以上では全くない。
上のページはざっくり読んだけど、基本としてデザインパターンに関しての予備知識が無いので、何とも理解が出来なかった。
で、AppleScriptがAppleScript Objective-Cというのになったということで、やっと何となく試し始めているのだけれど、そんなこんなで、何とか楽が出来ないかと、今一度基本的な事から感が手見ている。
その一つの端緒がデダインパターン。・・・なのかもしれないな、と。
遅ればせながら、以下も購入してた。
オブジェクト指向における再利用のためのデザインパターン
デザインパターンとともに学ぶオブジェクト指向のこころ
自炊して、買ったばかりのiPadに投げ込んでみようかな。
今度こそ、ちゃんと理解しましょう。
今度こそ、ちゃんと取り組みましょう。
決意を込めて。
AppleScript とデザインパターン
知ったと言ってもデザインパターンという言葉を覚えたというだけで、それ以上では全くない。
上のページはざっくり読んだけど、基本としてデザインパターンに関しての予備知識が無いので、何とも理解が出来なかった。
で、AppleScriptがAppleScript Objective-Cというのになったということで、やっと何となく試し始めているのだけれど、そんなこんなで、何とか楽が出来ないかと、今一度基本的な事から感が手見ている。
その一つの端緒がデダインパターン。・・・なのかもしれないな、と。
遅ればせながら、以下も購入してた。
オブジェクト指向における再利用のためのデザインパターン
デザインパターンとともに学ぶオブジェクト指向のこころ
自炊して、買ったばかりのiPadに投げ込んでみようかな。
今度こそ、ちゃんと理解しましょう。
今度こそ、ちゃんと取り組みましょう。
決意を込めて。
RTXにはもう随分長い間お世話になっている。
設定もいろいろといじくっているし、VPNの恩恵は絶大。
なのに、基本的なことまできちんと理解ししているかとなると、ちょっと自身が無い。
いじくるのは年に1、2度なので、ちょっと読んでも理解まで行かないからか、直ぐに忘れる。
でさっき別の情報を拾っていて以下を発見。
舞い込みジャーナルの【連載】ヤマハルータでつくるインターネットVPN
時間が出来たらちゃんと読もうと、メモメモ。
設定もいろいろといじくっているし、VPNの恩恵は絶大。
なのに、基本的なことまできちんと理解ししているかとなると、ちょっと自身が無い。
いじくるのは年に1、2度なので、ちょっと読んでも理解まで行かないからか、直ぐに忘れる。
でさっき別の情報を拾っていて以下を発見。
舞い込みジャーナルの【連載】ヤマハルータでつくるインターネットVPN
時間が出来たらちゃんと読もうと、メモメモ。
ちょっと名言を。
本日我が家の愚息がお使いにいって、おつりを全部忘れてきました。
じつは今年に入って5回目。眼鏡、自分の財布、ポケモンカード、外出した際に買ってやったお土産。そして今日のおつり。
もちろん宿題も含めるなら数知れず・・・。
なので、何とか心に届いてほしいと名言にすがってみようと思って、うろ覚えなので検索。
目的の言葉は以下でした。
心が変われば態度が変わる。
態度が変われば行動が変わる。
行動が変われば習慣が変わる。
習慣が変われば人格が変わる。
人格が変われば運命が変わる。
運命が変われば人生が変わる。
ヒンズー教の教えなのだそうです。
でその時に検索に引っかかったのが以下のサイト。
http://www.fesh.jp/utterer_145_1_1.html
稲盛和夫の名言集
言わずと知れた、京セラやKDDiを作り、最近では日航の立て直しを行っているまだ存命の数少ない伝説の経営者ですね。
さすが含蓄の有るお言葉の数々です。
何度言っても反省の無い我が愚息の心にも少しは響いてくれるといいのですが。
よろしければ、皆様も心打たれてくださいまし。
本日我が家の愚息がお使いにいって、おつりを全部忘れてきました。
じつは今年に入って5回目。眼鏡、自分の財布、ポケモンカード、外出した際に買ってやったお土産。そして今日のおつり。
もちろん宿題も含めるなら数知れず・・・。
なので、何とか心に届いてほしいと名言にすがってみようと思って、うろ覚えなので検索。
目的の言葉は以下でした。
心が変われば態度が変わる。
態度が変われば行動が変わる。
行動が変われば習慣が変わる。
習慣が変われば人格が変わる。
人格が変われば運命が変わる。
運命が変われば人生が変わる。
ヒンズー教の教えなのだそうです。
でその時に検索に引っかかったのが以下のサイト。
http://www.fesh.jp/utterer_145_1_1.html
稲盛和夫の名言集
言わずと知れた、京セラやKDDiを作り、最近では日航の立て直しを行っているまだ存命の数少ない伝説の経営者ですね。
さすが含蓄の有るお言葉の数々です。
何度言っても反省の無い我が愚息の心にも少しは響いてくれるといいのですが。
よろしければ、皆様も心打たれてくださいまし。
前回のAppleScript-保存のフォーマットは、この伏線。
いろいろとAppleScriptを書いていると、使い回したくなってくるもの。
で、私はよく使いそうな物をある程度のカテゴリーに分けて保存して、それを読み込んで使っている。
で、いまちょっとライブラリを整理していて、ついでにGit、diff、findとかでちゃんと引っかかるようにしたい。しかもXCode4.0ではGitが標準で使えるって話しだし。ということでライブラリを整理しながら、全部テキスト形式に替えてみようかと試していたのです。
ところが、直した物が読み込まない。
あれ、ということで確認してみると、どうやらテキストで保存した物は読み込まないのですね・・・。
Script Debuggerだとテキスト保存はBOM付きの UTF-8でAppleScriptエディターだとMacRomanなので一応両方試してみたけど、やっぱりテキストはダメみたいですね。
え〜〜じゃあGit使えない〜〜。
テキストで読み込んで Runしてという事も考えたけど、中には試し用のコードも書いてあったりするので、そいつが動いてしまうのは何ともはやなので、この案は没。
で、ふと思うのはXCodeでライブラリ管理用にプロジェクトを作って、ライブラリの修正時にはこれをコンパイル。で、出来上がったソースを読み込むようにする。
これならXCode内でのGitも検索や置き換えにも使えるし、ライブラリのXcodeでの使用の試しも組み込める。
新しいXCodeって有料になったのですよね。
落ち着いたら早速試してみます。
でも差し当たりコンパイルしたスクリプトに戻さなくちゃ・・・。
いろいろとAppleScriptを書いていると、使い回したくなってくるもの。
で、私はよく使いそうな物をある程度のカテゴリーに分けて保存して、それを読み込んで使っている。
で、いまちょっとライブラリを整理していて、ついでにGit、diff、findとかでちゃんと引っかかるようにしたい。しかもXCode4.0ではGitが標準で使えるって話しだし。ということでライブラリを整理しながら、全部テキスト形式に替えてみようかと試していたのです。
ところが、直した物が読み込まない。
あれ、ということで確認してみると、どうやらテキストで保存した物は読み込まないのですね・・・。
set LibFolerPath to "MacHD:AppleScript:ASLibrary:load_script:"
set LibFileNameList to {}
set end of LibFileNameList to "LoadedScript_Compiled_Bundle.scptd"
set end of LibFileNameList to "LoadedScript_Compiled_Datafork.scpt"
set end of LibFileNameList to "LoadedScript_Compiled_ResourceFork.scpt"
set end of LibFileNameList to "LoadedScript_Application_Bundle.app"
set end of LibFileNameList to "LoadedScript_Application_Carbon.app"
set end of LibFileNameList to "LoadedScript_text.applescript"
set end of LibFileNameList to "ASEditer-text.applescript"
repeat with LibFileName in LibFileNameList
set LoadScriptPath to LibFolerPath & LibFileName
try
set LoadScript to load script file LoadScriptPath
on error errmsg number ErrNum
log errmsg & "(" & ErrNum & ")"
end try
end repeat
load script file "MacHD:AppleScript:ASLibrary:load_script:LoadedScript_Compiled_Bundle.scptd"
--> set ScriptType to "Bundle"
load script file "MacHD:AppleScript:ASLibrary:load_script:LoadedScript_Compiled_Datafork.scpt"
--> set ScriptType to "Text"
load script file "MacHD:AppleScript:ASLibrary:load_script:LoadedScript_Compiled_ResourceFork.scpt"
--> set ScriptType to "ResourceFork"
load script file "MacHD:AppleScript:ASLibrary:load_script:LoadedScript_Application_Bundle.app"
--> set ScriptType to "ResourceFork"
load script file "MacHD:AppleScript:ASLibrary:load_script:LoadedScript_Application_Carbon.app"
--> set ScriptType to "ResourceFork"
load script file "MacHD:AppleScript:ASLibrary:load_script:LoadedScript_text.applescript"
(*Script doesn’t seem to belong to AppleScript.(-1752)*)
load script file "MacHD:AppleScript:ASLibrary:load_script:ASEditer-text.applescript"
(*Script doesn’t seem to belong to AppleScript.(-1752)*)
Script Debuggerだとテキスト保存はBOM付きの UTF-8でAppleScriptエディターだとMacRomanなので一応両方試してみたけど、やっぱりテキストはダメみたいですね。
え〜〜じゃあGit使えない〜〜。
テキストで読み込んで Runしてという事も考えたけど、中には試し用のコードも書いてあったりするので、そいつが動いてしまうのは何ともはやなので、この案は没。
で、ふと思うのはXCodeでライブラリ管理用にプロジェクトを作って、ライブラリの修正時にはこれをコンパイル。で、出来上がったソースを読み込むようにする。
これならXCode内でのGitも検索や置き換えにも使えるし、ライブラリのXcodeでの使用の試しも組み込める。
新しいXCodeって有料になったのですよね。
落ち着いたら早速試してみます。
でも差し当たりコンパイルしたスクリプトに戻さなくちゃ・・・。
AppleScriptの保存の時にいろいろとフォーマットを選択できる。
選択できるのだから何かしら違いが有るのだろう・・・多分。
でもよく知らないのでちゃんと知っておこう。
例えば、OSX10.6のAppleScriptエディターで保存を選ぶと選べるフォーマットは以下の四つ。
・スクリプト
・スクリプトバンドル
・アプリケーション
・テキスト
Script Debuggerだと以下の六つ。
・Compiled Script(Data fork)
・Compiled Script(Bundle)
・Compiled Script(Resource Fork)
・Application (Carbon)
・Application (Bundle)
・Text
私は大抵Script Debuggerを使用しているので、先ずはそちらに関して。
基本的には以下に詳細がでていた。
・Compiled Script
・Application
・Text
あとはこの辺にも何か書いてあるような。
・AppleScript. The Definitive Guide
で早速翻訳を試みる。・・・もちろん翻訳サイトで・・・しかも更に意訳・・・くれぐれも出典を参照されます事。
Compiled Scriptでの保存
・Compiled Script (Data Fork)
データフォークにコンパイルされたバイトコードがあるファイル。
これは、アップルのScript Editorの最新版によって作成された省略時書式です。
これはMac OS Xのすべてのバージョンと、非常に古いMac OS9のAppleScriptに互換性があります。
拡張子:scpt
タイプ:'osas'
・Compiled Script (Bundle)
コンパイルされたバイトコードがデータフォークに収められているスクリプトファイルがバンドルパッケージに含まれている形式。
この形式は、Panther(Mac OS X10.3)で導入され、それ以前のシステムに互換性がありません。
またバンドルパッケージ内に付随するファイルを保存できるという利点がありますが、いくつかのアプリケーションがこの形式を理解していないことに注意してください。
拡張子:scptd
・Compiled Script(Resource Fork)
コンパイルされたバイトコードがリソースフォーク内に含まれるファイル。 これは、最も古い形式であり、すべてのMacintosh systemsのすべてのバージョンのAppleScriptと互換性があります。
しかし、リソースフォークにバイトコードを含めるのは、非常に危険な形式です。
例えば、非HFSファイリングシステム(本当のUnix、またはWindows)の上にコンパイルされたスクリプトファイルを保存する、メールでそれを圧縮せずにそれを送る、または何らかのお粗末なスクリプトエディタアプリケーションでそれを開く、などリソースフォークが分離してしまうアクシデントに見舞われるかもしれないからです。
拡張子:scpt
タイプ:'osas'
警告: デバッグモードで保存されたコンパイルされたスクリプトは、他の環境(アップルのScript Editorでは開く事さえできない)正常に実行されないでしょう。
それが意図的なものでないなら、デバッグし終わっているときには、必ず通常モードのスクリプトとして保存してください。
Applicationでの保存
アプレットとして伝統的に知られている、アプリケーションとしてコンパイルされたスクリプトとして保存されます。
アプレットはスタンドアロンのアプリケーションです。 Finderで開かれると、スクリプトは稼働しています。
Script DebuggerではFileメニューから開くか、またはScript DebuggerのDockかFinderアイコンにドラッグ&ドロップすることで編集できます。
アプレットとしてスクリプトを保存して、Script Debuggerでスクリプトを開いた状態のまま、Finderからスクリプトをテストし、またそれを編集することができます。
Script Debuggerには、アプレットとして保存するつもりのスクリプトをテストするのを助けるため、アプレット内の個々のハンドルをテストでき、実行中にアプレットのデバッグが出来ます。
・Application (Carbon)
この形式はMac OS XとCarbonLibを使用する以前のシステムの古いバージョンと互換性があります。
・Application (Bundle)
この形式は、Panther(Mac OS X10.3)で導入されて、それ以前のシステムと互換性がありません。
バンドルパッケージ内に付随するファイルを保存できるという利点があります。
「Classic applet」フォーマットのアプレットは、Mac OS X以前のシステムとAppleScriptのバージョンとの互換性のあるフォーマットが使用されています。
そのため、Mac OS X ネイティブなものとしては実行できません。
Mac OS X10.5(Leopard)以降ではClassic実行環境が無くなったので、そのようなアプレットは全く稼働できません。
Script Debugger4.5はClassicアプレットを開くことはできますが、保存はできないので、別の形式のコンパイルを選ばざるを得ないでしょう。
Classicアプレットを保存する必要があるなら、Script Debuggerの旧バージョンを使用してください。
警告: デバッグモードで保存されたアプリケーションは、正常に実行されないでしょう。
それが意図的なものでないなら、デバッグし終わっているときには、必ず通常モードのアプリケーションとして保存してください。
Textでの保存
コンパイルされていない普通のテキストファイル (BOM付きの UTF-8 文字コード)としてスクリプトを保存できます。
また改行コードも指定できます。
なるほど、なるほど。
ところでAppleScriptエディターのテキスト保存は文字コードが違っているみたい。
保存されているのはShift_JISというか、MacRomanどうやら言語環境の設定で日本語を選択しているとStringはMacRomanになるらしいのだけど、きっとこのあたりもそれに倣っているのかもしれない。
これはこれで厄介だな。
XCodeはファイル毎に指定できるけど・・・。
選択できるのだから何かしら違いが有るのだろう・・・多分。
でもよく知らないのでちゃんと知っておこう。
例えば、OSX10.6のAppleScriptエディターで保存を選ぶと選べるフォーマットは以下の四つ。
・スクリプト
・スクリプトバンドル
・アプリケーション
・テキスト
Script Debuggerだと以下の六つ。
・Compiled Script(Data fork)
・Compiled Script(Bundle)
・Compiled Script(Resource Fork)
・Application (Carbon)
・Application (Bundle)
・Text
私は大抵Script Debuggerを使用しているので、先ずはそちらに関して。
基本的には以下に詳細がでていた。
・Compiled Script
・Application
・Text
あとはこの辺にも何か書いてあるような。
・AppleScript. The Definitive Guide
で早速翻訳を試みる。・・・もちろん翻訳サイトで・・・しかも更に意訳・・・くれぐれも出典を参照されます事。
Compiled Scriptでの保存
・Compiled Script (Data Fork)
データフォークにコンパイルされたバイトコードがあるファイル。
これは、アップルのScript Editorの最新版によって作成された省略時書式です。
これはMac OS Xのすべてのバージョンと、非常に古いMac OS9のAppleScriptに互換性があります。
拡張子:scpt
タイプ:'osas'
・Compiled Script (Bundle)
コンパイルされたバイトコードがデータフォークに収められているスクリプトファイルがバンドルパッケージに含まれている形式。
この形式は、Panther(Mac OS X10.3)で導入され、それ以前のシステムに互換性がありません。
またバンドルパッケージ内に付随するファイルを保存できるという利点がありますが、いくつかのアプリケーションがこの形式を理解していないことに注意してください。
拡張子:scptd
・Compiled Script(Resource Fork)
コンパイルされたバイトコードがリソースフォーク内に含まれるファイル。 これは、最も古い形式であり、すべてのMacintosh systemsのすべてのバージョンのAppleScriptと互換性があります。
しかし、リソースフォークにバイトコードを含めるのは、非常に危険な形式です。
例えば、非HFSファイリングシステム(本当のUnix、またはWindows)の上にコンパイルされたスクリプトファイルを保存する、メールでそれを圧縮せずにそれを送る、または何らかのお粗末なスクリプトエディタアプリケーションでそれを開く、などリソースフォークが分離してしまうアクシデントに見舞われるかもしれないからです。
拡張子:scpt
タイプ:'osas'
警告: デバッグモードで保存されたコンパイルされたスクリプトは、他の環境(アップルのScript Editorでは開く事さえできない)正常に実行されないでしょう。
それが意図的なものでないなら、デバッグし終わっているときには、必ず通常モードのスクリプトとして保存してください。
Applicationでの保存
アプレットとして伝統的に知られている、アプリケーションとしてコンパイルされたスクリプトとして保存されます。
アプレットはスタンドアロンのアプリケーションです。 Finderで開かれると、スクリプトは稼働しています。
Script DebuggerではFileメニューから開くか、またはScript DebuggerのDockかFinderアイコンにドラッグ&ドロップすることで編集できます。
アプレットとしてスクリプトを保存して、Script Debuggerでスクリプトを開いた状態のまま、Finderからスクリプトをテストし、またそれを編集することができます。
Script Debuggerには、アプレットとして保存するつもりのスクリプトをテストするのを助けるため、アプレット内の個々のハンドルをテストでき、実行中にアプレットのデバッグが出来ます。
・Application (Carbon)
この形式はMac OS XとCarbonLibを使用する以前のシステムの古いバージョンと互換性があります。
・Application (Bundle)
この形式は、Panther(Mac OS X10.3)で導入されて、それ以前のシステムと互換性がありません。
バンドルパッケージ内に付随するファイルを保存できるという利点があります。
「Classic applet」フォーマットのアプレットは、Mac OS X以前のシステムとAppleScriptのバージョンとの互換性のあるフォーマットが使用されています。
そのため、Mac OS X ネイティブなものとしては実行できません。
Mac OS X10.5(Leopard)以降ではClassic実行環境が無くなったので、そのようなアプレットは全く稼働できません。
Script Debugger4.5はClassicアプレットを開くことはできますが、保存はできないので、別の形式のコンパイルを選ばざるを得ないでしょう。
Classicアプレットを保存する必要があるなら、Script Debuggerの旧バージョンを使用してください。
警告: デバッグモードで保存されたアプリケーションは、正常に実行されないでしょう。
それが意図的なものでないなら、デバッグし終わっているときには、必ず通常モードのアプリケーションとして保存してください。
Textでの保存
コンパイルされていない普通のテキストファイル (BOM付きの UTF-8 文字コード)としてスクリプトを保存できます。
また改行コードも指定できます。
なるほど、なるほど。
ところでAppleScriptエディターのテキスト保存は文字コードが違っているみたい。
保存されているのはShift_JISというか、MacRomanどうやら言語環境の設定で日本語を選択しているとStringはMacRomanになるらしいのだけど、きっとこのあたりもそれに倣っているのかもしれない。
これはこれで厄介だな。
XCodeはファイル毎に指定できるけど・・・。
英語は赤点だったのです・・・といって逃げ回っているため、いつどんな変更が施されているのかきちんと把握していない有様。で、いざという時に引っかかる。
セウゾーさんの翻訳を読んで初めて知ることも多々。
まぁ頼ってばかりもなんなので、探してみると、OSXのバージョンごとにまとめられているのがあるのですね。
NotesIntroduction to AppleScript Release
さぁ、読みましょう・・・時間のあるときに・・・。
セウゾーさんの翻訳を読んで初めて知ることも多々。
まぁ頼ってばかりもなんなので、探してみると、OSXのバージョンごとにまとめられているのがあるのですね。
NotesIntroduction to AppleScript Release
さぁ、読みましょう・・・時間のあるときに・・・。
先日書いた中で『カッコ付きの株だのローマ数字だののいわゆる機種依存文字を含んだShiftJIS(CP932)のファイルを変換してみたら中身が空っぽのファイルが出来ただけだった・・・。』と書いたのだけど、何となく嘘っぽい。
何となく私が悪かったような気がする。
もう一度という事で、先日と同じファイルを使って、AppleScriptでOSX10.6に入っているiconvで扱えることになっている文字コードで片っ端から変換してみた。
それにしても420もあるのですね。中には同じ物の別の名前での登録が有るようですが(UTF-8とUTF8みたいな)何と何が同じかも判断のつかない、というかそんな文字コードも有るのか、なものも結構有るので、もうとにかく片っ端から・・・。
でもって、成功してるよ、のものは確認のためmiで開いてみただけで、しかも自動判別で開いてみただけ。なので、miで対応してない物はちゃんと表示しないし、表示しても意味不明になっているので、判別不能。ちゃんと開いているように見える物もちらっと眺めただけでの判断。そもそも元ファイルがテストの為に適切かも分からない。まぁ『cannot convert』となった物は明らかなのだけど。それ以外もあまり信用せずに自分で確認してくださいませ。
一応iconvが変換したよと行ってきたものが39/420。ダメよが380/420。・・・・あれ一つ足りない。もうログを読むのが面倒なのでまぁいいか。・・・いいのか。
リストが長いので先に雑感。
1Byte系の物はちゃんと変換できなくて当然だし、アラビア後だの何とか後だのはちゃんと変換できなくて当然ですね。Unicode関連は何となくうまく行っているような。
で、MACROMANがNGなのがなんとも・・・。あれ、そうかこれを試してたのかな。もう忘れてるし。
OKのもの。
ダメよのもの。
何となく私が悪かったような気がする。
もう一度という事で、先日と同じファイルを使って、AppleScriptでOSX10.6に入っているiconvで扱えることになっている文字コードで片っ端から変換してみた。
それにしても420もあるのですね。中には同じ物の別の名前での登録が有るようですが(UTF-8とUTF8みたいな)何と何が同じかも判断のつかない、というかそんな文字コードも有るのか、なものも結構有るので、もうとにかく片っ端から・・・。
でもって、成功してるよ、のものは確認のためmiで開いてみただけで、しかも自動判別で開いてみただけ。なので、miで対応してない物はちゃんと表示しないし、表示しても意味不明になっているので、判別不能。ちゃんと開いているように見える物もちらっと眺めただけでの判断。そもそも元ファイルがテストの為に適切かも分からない。まぁ『cannot convert』となった物は明らかなのだけど。それ以外もあまり信用せずに自分で確認してくださいませ。
一応iconvが変換したよと行ってきたものが39/420。ダメよが380/420。・・・・あれ一つ足りない。もうログを読むのが面倒なのでまぁいいか。・・・いいのか。
リストが長いので先に雑感。
1Byte系の物はちゃんと変換できなくて当然だし、アラビア後だの何とか後だのはちゃんと変換できなくて当然ですね。Unicode関連は何となくうまく行っているような。
で、MACROMANがNGなのがなんとも・・・。あれ、そうかこれを試してたのかな。もう忘れてるし。
OKのもの。
CP932 => C99 => OK => 数字以外が\u2116\u33cd\u2121\u32a4な感じで判断不能
CP932 => CP932 => OK => miではshift_JIXX0213として開き、何カ所か文字が化けてます。まぁ変換する必要ない物を変換している訳ですしね。
CP932 => CP943 => OK => miではshift_JIXX0213として開き、何カ所か文字が化けてます。これもCP932と同じかな。
CP932 => CSUCS4 => OK => 00100200300400500あ00い00う、な感じで判断不能
CP932 => CSUNICODE => OK => miだとUTF-16で開いた。うまく行っているようです。
CP932 => CSUNICODE11 => OK => miだとUTF-16で開いた。うまく行っているようです。
CP932 => CSUNICODE11UTF7 => OK => miだとUTF-8で開いた。数字以外が+MEIwRDBGMEgwSiEWな感じで判断不能
CP932 => EUC-JISX0213 => OK => miだとEUC-JPで開いた。うまく行っているようです。
CP932 => GB18030 => OK => miだとwindows-1252で開いた。数字以外が¡í9ê2©Y9Í29Í39Í49Í59Í6©Z9Á9な感じで判断不能
CP932 => ISO-2022-JP-3 => OK => miだとUTF-8で開いた。数字以外が+MEIwRDBGMEgwSiEWな感じで判断不能
CP932 => ISO-10646-UCS-2 => OK => miだとUTF-16で開いた。うまく行っているようです。
CP932 => ISO-10646-UCS-4 => OK => 00100200300400500あ00い00う、な感じで判断不能
CP932 => JAVA => OK => 数字以外が\u2116\u33cd\u2121\u32a4な感じで判断不能
CP932 => SHIFT_JISX0213 => OK => miだとShift_JISで開いた。うまく行っているようです。
CP932 => UCS-2 => OK => miだとUTF-16で開いた。うまく行っているようです。
CP932 => UCS-2-INTERNAL => OK => miだとUTF-16で開いた。㈀㌀㐀㔀㘀㜀㠀㤀 ㈀㌀㐀㔀㘀㜀㠀㤀 なのが続いてるので判断不能
CP932 => UCS-2-SWAPPED => OK => miだとUTF-16で開いた。うまく行っているようです。
CP932 => UCS-2BE => OK => miだとUTF-16で開いた。うまく行っているようです。
CP932 => UCS-2LE => OK => miだとUTF-16で開いた。㈀㌀㐀㔀㘀㜀㠀㤀 ㈀㌀㐀㔀㘀㜀㠀㤀 なのが続いてるので判断不能
CP932 => UCS-4 => OK => miだとUTF-16で開いた。00100200300400500あ00い00う、な感じで判断不能
CP932 => UCS-4-INTERNAL => OK => miだとUTF-16で開いた。00㈀00㌀00㐀00㔀00㘀00㜀00㠀、な感じで判断不能
CP932 => UCS-4-SWAPPED => OK => miだとUTF-16で開いた。00100200300400500あ00い00う、な感じで判断不能
CP932 => UCS-4BE => OK => miだとUTF-16で開いた。00100200300400500あ00い00う、な感じで判断不能
CP932 => UCS-4LE => OK => miだとUTF-16で開いた。00㈀00㌀00㐀00㔀00㘀00㜀00㠀、な感じで判断不能
CP932 => UNICODE-1-1 => OK => miだとUTF-16で開いた。うまく行っているようです。
CP932 => UNICODE-1-1-UTF-7 => OK => miだとUTF-16で開いた。うまく行っているようです。。数字以外が+MEIwRDBGMEgwSiEWな感じで判断不能
CP932 => UNICODEBIG => OK => miだとUTF-16で開いた。うまく行っているようです。
CP932 => UNICODELITTLE => OK => miだとUTF-16で開いた。㈀㌀㐀㔀㘀㜀㠀㤀 ㈀㌀㐀㔀㘀㜀㠀㤀 なのが続いてるので判断不能
CP932 => UTF-7 => OK => miだとUTF-16で開いた。数字以外が+MEIwRDBGMEgwSiEWな感じで判断不能
CP932 => UTF-8 => OK => miだとUTF-8で開いた。うまく行っているようです。
CP932 => UTF8 => OK => miだとUTF-8で開いた。うまく行っているようです。
CP932 => UTF-8-MAC => OK => miだとUTF-8で開いた。半濁音とかの表示が乱れるのは逆にうまく行ってる証拠?。たぶん。
CP932 => UTF8-MAC => OK => miだとUTF-8で開いた。半濁音とかの表示が乱れるのは逆にうまく行ってる証拠?。たぶん。
CP932 => UTF-16 => OK => miだとUTF-16で開いた。うまく行っているようです。
CP932 => UTF-16BE => OK => miだとUTF-16で開いた。うまく行っているようです。
CP932 => UTF-16LE => OK => miだとUTF-16で開いた。㈀㌀㐀㔀㘀㜀㠀㤀 とかになってたけど、これは知ってるのでUTF-16LEで開いたら大丈夫そう。こんなふうになるとこは・・・。
CP932 => UTF-32 => OK => miだとUTF-16で開いた。00100200300400500あ00い00う、な感じで判断不能
CP932 => UTF-32BE => OK => miだとUTF-16で開いた。00100200300400500あ00い00う、な感じで判断不能
CP932 => UTF-32LE => OK => miだとUTF-16で開いた。00㈀00㌀00㐀00㔀00㘀00㜀00㠀、な感じで判断不能
ダメよのもの。
CP932 => ANSI_X3.4-1968 => NG
CP932 => ANSI_X3.4-1986 => NG
CP932 => ASCII => NG
CP932 => CP367 => NG
CP932 => IBM367 => NG
CP932 => ISO-IR-6 => NG
CP932 => ISO646-US => NG
CP932 => ISO_646.IRV:1991 => NG
CP932 => US => NG
CP932 => US-ASCII => NG
CP932 => CSASCII => NG
CP932 => CP819 => NG
CP932 => IBM819 => NG
CP932 => ISO-8859-1 => NG
CP932 => ISO-IR-100 => NG
CP932 => ISO8859-1 => NG
CP932 => ISO_8859-1 => NG
CP932 => ISO_8859-1:1987 => NG
CP932 => L1 => NG
CP932 => LATIN1 => NG
CP932 => CSISOLATIN1 => NG
CP932 => ISO-8859-2 => NG
CP932 => ISO-IR-101 => NG
CP932 => ISO8859-2 => NG
CP932 => ISO_8859-2 => NG
CP932 => ISO_8859-2:1987 => NG
CP932 => L2 => NG
CP932 => LATIN2 => NG
CP932 => CSISOLATIN2 => NG
CP932 => ISO-8859-3 => NG
CP932 => ISO-IR-109 => NG
CP932 => ISO8859-3 => NG
CP932 => ISO_8859-3 => NG
CP932 => ISO_8859-3:1988 => NG
CP932 => L3 => NG
CP932 => LATIN3 => NG
CP932 => CSISOLATIN3 => NG
CP932 => ISO-8859-4 => NG
CP932 => ISO-IR-110 => NG
CP932 => ISO8859-4 => NG
CP932 => ISO_8859-4 => NG
CP932 => ISO_8859-4:1988 => NG
CP932 => L4 => NG
CP932 => LATIN4 => NG
CP932 => CSISOLATIN4 => NG
CP932 => CYRILLIC => NG
CP932 => ISO-8859-5 => NG
CP932 => ISO-IR-144 => NG
CP932 => ISO8859-5 => NG
CP932 => ISO_8859-5 => NG
CP932 => ISO_8859-5:1988 => NG
CP932 => CSISOLATINCYRILLIC => NG
CP932 => ARABIC => NG
CP932 => ASMO-708 => NG
CP932 => ECMA-114 => NG
CP932 => ISO-8859-6 => NG
CP932 => ISO-IR-127 => NG
CP932 => ISO8859-6 => NG
CP932 => ISO_8859-6 => NG
CP932 => ISO_8859-6:1987 => NG
CP932 => CSISOLATINARABIC => NG
CP932 => ECMA-118 => NG
CP932 => ELOT_928 => NG
CP932 => GREEK => NG
CP932 => GREEK8 => NG
CP932 => ISO-8859-7 => NG
CP932 => ISO-IR-126 => NG
CP932 => ISO8859-7 => NG
CP932 => ISO_8859-7 => NG
CP932 => ISO_8859-7:1987 => NG
CP932 => ISO_8859-7:2003 => NG
CP932 => CSISOLATINGREEK => NG
CP932 => HEBREW => NG
CP932 => ISO-8859-8 => NG
CP932 => ISO-IR-138 => NG
CP932 => ISO8859-8 => NG
CP932 => ISO_8859-8 => NG
CP932 => ISO_8859-8:1988 => NG
CP932 => CSISOLATINHEBREW => NG
CP932 => ISO-8859-9 => NG
CP932 => ISO-IR-148 => NG
CP932 => ISO8859-9 => NG
CP932 => ISO_8859-9 => NG
CP932 => ISO_8859-9:1989 => NG
CP932 => L5 => NG
CP932 => LATIN5 => NG
CP932 => CSISOLATIN5 => NG
CP932 => ISO-8859-10 => NG
CP932 => ISO-IR-157 => NG
CP932 => ISO8859-10 => NG
CP932 => ISO_8859-10 => NG
CP932 => ISO_8859-10:1992 => NG
CP932 => L6 => NG
CP932 => LATIN6 => NG
CP932 => CSISOLATIN6 => NG
CP932 => ISO-8859-11 => NG
CP932 => ISO8859-11 => NG
CP932 => ISO_8859-11 => NG
CP932 => ISO-8859-13 => NG
CP932 => ISO-IR-179 => NG
CP932 => ISO8859-13 => NG
CP932 => ISO_8859-13 => NG
CP932 => L7 => NG
CP932 => LATIN7 => NG
CP932 => ISO-8859-14 => NG
CP932 => ISO-CELTIC => NG
CP932 => ISO-IR-199 => NG
CP932 => ISO8859-14 => NG
CP932 => ISO_8859-14 => NG
CP932 => ISO_8859-14:1998 => NG
CP932 => L8 => NG
CP932 => LATIN8 => NG
CP932 => ISO-8859-15 => NG
CP932 => ISO-IR-203 => NG
CP932 => ISO8859-15 => NG
CP932 => ISO_8859-15 => NG
CP932 => ISO_8859-15:1998 => NG
CP932 => LATIN-9 => NG
CP932 => ISO-8859-16 => NG
CP932 => ISO-IR-226 => NG
CP932 => ISO8859-16 => NG
CP932 => ISO_8859-16 => NG
CP932 => ISO_8859-16:2001 => NG
CP932 => L10 => NG
CP932 => LATIN10 => NG
CP932 => KOI8-R => NG
CP932 => CSKOI8R => NG
CP932 => KOI8-U => NG
CP932 => KOI8-RU => NG
CP932 => CP1250 => NG
CP932 => MS-EE => NG
CP932 => WINDOWS-1250 => NG
CP932 => CP1251 => NG
CP932 => MS-CYRL => NG
CP932 => WINDOWS-1251 => NG
CP932 => CP1252 => NG
CP932 => MS-ANSI => NG
CP932 => WINDOWS-1252 => NG
CP932 => CP1253 => NG
CP932 => MS-GREEK => NG
CP932 => WINDOWS-1253 => NG
CP932 => CP1254 => NG
CP932 => MS-TURK => NG
CP932 => WINDOWS-1254 => NG
CP932 => CP1255 => NG
CP932 => MS-HEBR => NG
CP932 => WINDOWS-1255 => NG
CP932 => CP1256 => NG
CP932 => MS-ARAB => NG
CP932 => WINDOWS-1256 => NG
CP932 => CP1257 => NG
CP932 => WINBALTRIM => NG
CP932 => WINDOWS-1257 => NG
CP932 => CP1258 => NG
CP932 => WINDOWS-1258 => NG
CP932 => 850 => NG
CP932 => CP850 => NG
CP932 => IBM850 => NG
CP932 => CSPC850MULTILINGUAL => NG
CP932 => 862 => NG
CP932 => CP862 => NG
CP932 => IBM862 => NG
CP932 => CSPC862LATINHEBREW => NG
CP932 => 866 => NG
CP932 => CP866 => NG
CP932 => IBM866 => NG
CP932 => CSIBM866 => NG
CP932 => MAC => NG
CP932 => MACINTOSH => NG
CP932 => MACROMAN => NG
CP932 => CSMACINTOSH => NG
CP932 => MACCENTRALEUROPE => NG
CP932 => MACICELAND => NG
CP932 => MACCROATIAN => NG
CP932 => MACROMANIA => NG
CP932 => MACCYRILLIC => NG
CP932 => MACUKRAINE => NG
CP932 => MACGREEK => NG
CP932 => MACTURKISH => NG
CP932 => MACHEBREW => NG
CP932 => MACARABIC => NG
CP932 => MACTHAI => NG
CP932 => HP-ROMAN8 => NG
CP932 => R8 => NG
CP932 => ROMAN8 => NG
CP932 => CSHPROMAN8 => NG
CP932 => NEXTSTEP => NG
CP932 => ARMSCII-8 => NG
CP932 => GEORGIAN-ACADEMY => NG
CP932 => GEORGIAN-PS => NG
CP932 => KOI8-T => NG
CP932 => CP154 => NG
CP932 => CYRILLIC-ASIAN => NG
CP932 => PT154 => NG
CP932 => PTCP154 => NG
CP932 => CSPTCP154 => NG
CP932 => MULELAO-1 => NG
CP932 => CP1133 => NG
CP932 => IBM-CP1133 => NG
CP932 => ISO-IR-166 => NG
CP932 => TIS-620 => NG
CP932 => TIS620 => NG
CP932 => TIS620-0 => NG
CP932 => TIS620.2529-1 => NG
CP932 => TIS620.2533-0 => NG
CP932 => TIS620.2533-1 => NG
CP932 => CP874 => NG
CP932 => WINDOWS-874 => NG
CP932 => VISCII => NG
CP932 => VISCII1.1-1 => NG
CP932 => CSVISCII => NG
CP932 => TCVN => NG
CP932 => TCVN-5712 => NG
CP932 => TCVN5712-1 => NG
CP932 => TCVN5712-1:1993 => NG
CP932 => ISO-IR-14 => NG
CP932 => ISO646-JP => NG
CP932 => JIS_C6220-1969-RO => NG
CP932 => JP => NG
CP932 => CSISO14JISC6220RO => NG
CP932 => JISX0201-1976 => NG
CP932 => JIS_X0201 => NG
CP932 => X0201 => NG
CP932 => CSHALFWIDTHKATAKANA => NG
CP932 => ISO-IR-87 => NG
CP932 => JIS0208 => NG
CP932 => JIS_C6226-1983 => NG
CP932 => JIS_X0208 => NG
CP932 => JIS_X0208-1983 => NG
CP932 => JIS_X0208-1990 => NG
CP932 => X0208 => NG
CP932 => CSISO87JISX0208 => NG
CP932 => ISO-IR-159 => NG
CP932 => JIS_X0212 => NG
CP932 => JIS_X0212-1990 => NG
CP932 => JIS_X0212.1990-0 => NG
CP932 => X0212 => NG
CP932 => CSISO159JISX02121990 => NG
CP932 => CN => NG
CP932 => GB_1988-80 => NG
CP932 => ISO-IR-57 => NG
CP932 => ISO646-CN => NG
CP932 => CSISO57GB1988 => NG
CP932 => CHINESE => NG
CP932 => GB_2312-80 => NG
CP932 => ISO-IR-58 => NG
CP932 => CSISO58GB231280 => NG
CP932 => CN-GB-ISOIR165 => NG
CP932 => ISO-IR-165 => NG
CP932 => ISO-IR-149 => NG
CP932 => KOREAN => NG
CP932 => KSC_5601 => NG
CP932 => KS_C_5601-1987 => NG
CP932 => KS_C_5601-1989 => NG
CP932 => CSKSC56011987 => NG
CP932 => EUC-JP => NG
CP932 => EUCJP => NG
CP932 => EXTENDED_UNIX_CODE_PACKED_FORMAT_FOR_JAPANESE => NG
CP932 => CSEUCPKDFMTJAPANESE => NG
CP932 => MS_KANJI => NG
CP932 => SHIFT-JIS => NG
CP932 => SHIFT_JIS => NG
CP932 => SJIS => NG
CP932 => CSSHIFTJIS => NG
CP932 => ISO-2022-JP => NG
CP932 => CSISO2022JP => NG
CP932 => ISO-2022-JP-1 => NG
CP932 => ISO-2022-JP-2 => NG
CP932 => CSISO2022JP2 => NG
CP932 => CN-GB => NG
CP932 => EUC-CN => NG
CP932 => EUCCN => NG
CP932 => GB2312 => NG
CP932 => CSGB2312 => NG
CP932 => GBK => NG
CP932 => CP936 => NG
CP932 => MS936 => NG
CP932 => WINDOWS-936 => NG
CP932 => ISO-2022-CN => NG
CP932 => CSISO2022CN => NG
CP932 => ISO-2022-CN-EXT => NG
CP932 => HZ => NG
CP932 => HZ-GB-2312 => NG
CP932 => EUC-TW => NG
CP932 => EUCTW => NG
CP932 => CSEUCTW => NG
CP932 => BIG-5 => NG
CP932 => BIG-FIVE => NG
CP932 => BIG5 => NG
CP932 => BIGFIVE => NG
CP932 => CN-BIG5 => NG
CP932 => CSBIG5 => NG
CP932 => CP950 => NG
CP932 => BIG5-HKSCS:1999 => NG
CP932 => BIG5-HKSCS:2001 => NG
CP932 => BIG5-HKSCS => NG
CP932 => BIG5-HKSCS:2004 => NG
CP932 => BIG5HKSCS => NG
CP932 => EUC-KR => NG
CP932 => EUCKR => NG
CP932 => CSEUCKR => NG
CP932 => CP949 => NG
CP932 => UHC => NG
CP932 => CP1361 => NG
CP932 => JOHAB => NG
CP932 => ISO-2022-KR => NG
CP932 => CSISO2022KR => NG
CP932 => CP856 => NG
CP932 => CP922 => NG
CP932 => CP1046 => NG
CP932 => CP1124 => NG
CP932 => CP1129 => NG
CP932 => CP1161 => NG
CP932 => IBM-1161 => NG
CP932 => IBM1161 => NG
CP932 => CSIBM1161 => NG
CP932 => CP1162 => NG
CP932 => IBM-1162 => NG
CP932 => IBM1162 => NG
CP932 => CSIBM1162 => NG
CP932 => CP1163 => NG
CP932 => IBM-1163 => NG
CP932 => IBM1163 => NG
CP932 => CSIBM1163 => NG
CP932 => DEC-KANJI => NG
CP932 => DEC-HANYU => NG
CP932 => 437 => NG
CP932 => CP437 => NG
CP932 => IBM437 => NG
CP932 => CSPC8CODEPAGE437 => NG
CP932 => CP737 => NG
CP932 => CP775 => NG
CP932 => IBM775 => NG
CP932 => CSPC775BALTIC => NG
CP932 => 852 => NG
CP932 => CP852 => NG
CP932 => IBM852 => NG
CP932 => CSPCP852 => NG
CP932 => CP853 => NG
CP932 => 855 => NG
CP932 => CP855 => NG
CP932 => IBM855 => NG
CP932 => CSIBM855 => NG
CP932 => 857 => NG
CP932 => CP857 => NG
CP932 => IBM857 => NG
CP932 => CSIBM857 => NG
CP932 => CP858 => NG
CP932 => 860 => NG
CP932 => CP860 => NG
CP932 => IBM860 => NG
CP932 => CSIBM860 => NG
CP932 => 861 => NG
CP932 => CP-IS => NG
CP932 => CP861 => NG
CP932 => IBM861 => NG
CP932 => CSIBM861 => NG
CP932 => 863 => NG
CP932 => CP863 => NG
CP932 => IBM863 => NG
CP932 => CSIBM863 => NG
CP932 => CP864 => NG
CP932 => IBM864 => NG
CP932 => CSIBM864 => NG
CP932 => 865 => NG
CP932 => CP865 => NG
CP932 => IBM865 => NG
CP932 => CSIBM865 => NG
CP932 => 869 => NG
CP932 => CP-GR => NG
CP932 => CP869 => NG
CP932 => IBM869 => NG
CP932 => CSIBM869 => NG
CP932 => CP1125 => NG
CP932 => BIG5-2003 => NG
CP932 => ISO-IR-230 => NG
CP932 => TDS565 => NG
CP932 => ATARI => NG
CP932 => ATARIST => NG
CP932 => RISCOS-LATIN1 => NG
本当にお世話になりっぱなしのmiというエディタ。
長年使わせていただいていて、それなりにつかいこんでいたつもり。
AppleScriptからのアクセスだっていくつか作ってみたりしていた。
きちんとドキュメントなどを読まないというのは結局自分の労苦を増やす事でしかないと改めてしみじみ。
表題のmiのAppleScriptの概要というのがあるのですね。
これらをきちんと知っていると、なんだかいろいろと楽が出来るように作れそう。
さらに、今まで作っていたものの何とも無駄な事をやていそうなことがくっきり。
やれやれです。
長年使わせていただいていて、それなりにつかいこんでいたつもり。
AppleScriptからのアクセスだっていくつか作ってみたりしていた。
きちんとドキュメントなどを読まないというのは結局自分の労苦を増やす事でしかないと改めてしみじみ。
表題のmiのAppleScriptの概要というのがあるのですね。
これらをきちんと知っていると、なんだかいろいろと楽が出来るように作れそう。
さらに、今まで作っていたものの何とも無駄な事をやていそうなことがくっきり。
やれやれです。
AppleScriptで扱える文字に関してごにょごにょする為に久しぶりにバイナリを弄れるエディターを検索。
以前からHexEditを使わせていただいているのですが、何か他にいいのが有るかな、との浮気心から。
するとTORQUES LABSさん所にちゃんとまとめられていたので、おしまい。
こちらでも最終的にHexEditに落ち着いているようなので、新しいのを落としてきてよしとしよう。
まぁいずれ試す事もという事で、メモだけ。
HexEdit Japanese
ありがとうございます。
以前からHexEditを使わせていただいているのですが、何か他にいいのが有るかな、との浮気心から。
するとTORQUES LABSさん所にちゃんとまとめられていたので、おしまい。
こちらでも最終的にHexEditに落ち着いているようなので、新しいのを落としてきてよしとしよう。
まぁいずれ試す事もという事で、メモだけ。
HexEdit Japanese
ありがとうございます。
元々はOSX10.4で使っていたAppleScriptでWIndowsから受け取る固定長のファイルからリストに切り出し、カッコ株だのローマ数字の1だのを片っ端から変更し、埋め文字を削除してということをやらせていたのだけど、これが10.6でちゃんと動かない事から始まったのですが。
いろいろと弄っていて、もうパニック。
あちこち眺めていても知らない言葉ががさがさでてくる。
そもそもいったい文字コードってのはいくつ在るんだ〜〜〜。
叫んで遠い目をしそう。
思い直して先ずはちょっと整理。
ちゃんと調べて理解すべきだろうけど、もうげっそりなので、かなりおおざっぱで不正確かもしれない。
まぁ取りあえず、ということで。
さて文字コードの種類。何ともはやいろいろと在って書き抜くのも面倒なので、Wikipediaの文字コードを参照してください。
でもって私が当面の問題としているのがWindowsの機種依存文字を含んだ固定長のリストをAppleScriptで取り込んで処理して、書き出すという処理に関わる部分。
なので対象は以下。
・Shift_JIS X0213
・MacRoman(Mac版Shift_JIS)
・UTF8
・UTF16
多数の応募の中からの選考基準はAppleScriptで扱えそうな物と、扱う必要の在る物ということで。
AppleScript 2.0リリースノート(Mac OS X version 10.5)を市川せうぞーさんが訳してくれている物に詳しいのですが、AppleScript2.0は内部において扱う文字は全てUnicodeに統一されたのだと言う。
いまいちピンと来ていなかったのですが、ダイアローグ入力したりShiftJISのファイルから読み込んだりしても取り込まれると全部中ではUnicodeにされて扱われるという事のようだ。
なので、今まで「string」と「Unicode text」を使い分ける事で、Shift_JISの文字コードとUnicodeの文字を変換しながら使っていたけど、こういう事はしなくていい、というより出来なくなってしまうことになる。
で、「string」と「Unicode text」はAppleScript 2.0以前との互換性のために残してるだけだよ、ということのよう。となると、互換性を考えなければ『as text』を使いなさいという事なのでしょうか?。
さらに「ASCII character」と「ASCII number」のレガシーコマンドも動作はしますが、すべてのユニコード範囲をカバーしません。ともある。
確かに、今まで例えば『あ』を作る場合、
上を実行すると
まぁ『あ』なら何のコードでもきちんと扱えさえすればいいのだけど、困るのはWindowsからもらったファイルを取り込むとき。
例えばカッコの付いた株の時などは、Windowsから持ってきた住所録には結構な数が入っている。
OSX10.4までは、カッコ株は
そもそもAppleScriptのUnicodeってなに?。
どうやら、世界で使われる全ての文字を共通の文字集合にて利用できるようにしようという考えで作られコード体系との事。
すばらしい、MacだWinだ機種依存文字だのなんだかんだ・・・結構うんざりなので、この精神に拍手拍手。
ところがふたを開けてみるとUnicodeの中にもUTF7、UTF8、UTF16、UTF32だのがあって、その下にもなんだかんだあるような・・・。
崇高な精神はどこいった!!。文字コードが増えただけかい!!。
とはいっても少しはいい方向へ行ってるのかな。
今、Web系はどんどんUTF8に修練していっているように思う。じゃないと韓国語だの中国語だのが混じったHPは作れないのだからそうならざる得ない。
ではWinやMacは。
こちらもMacはOSXになってから、Winも98から対応していたのがVista以降IMEの変換候補にUnicodeの文字が表示されるようになって、積極的に対応せざる得なくなってきているような感じらしい。
話を戻して、AppleScriptのUnicodeはそんなUnicodeのどれ?。ということで調べてみる、結論としてはUTF-16のビックエンディアンというやつらしい。
さて早速UTF-16なのにビックエンディアンとリトルエンディアンの2つに分かれた。やれやれ。
例えば、『あ』で違いを見てみると、ShiftJISならASCII numberの130と160の組み合せになるわけだけど、この『130』と『160』を16進数に変換すると、それぞれ『82』と『A0』になる。だからShift_JISで書き出されたファイルをバイナリーエディタなどを使ってみて見ると、『ああああ』なら『82A082A082A082A0』と並んでいることになる。
ではUnicodeのUTF-16のビックエンディアンの場合はどうか。同じように『あ』と書き込んで保存してバイナリーエディタで見てみると『4230』となっている。これはどういう数字なのだろうか。
AppleScript2.0で
エディタでみた、『4230』と『12354』を16進数にした『3042』。なんか似てる。なんだか『30』と『42』を逆さまにしたもののようだ。実はこのコードを16進数にしたのがビックエンディアンというものらしい。で逆さまにしないのがリトルエンディアン。なんでまた逆さまに、とも疑問に思うが、深みにはまるので後はUnicode ~エンディアンとBOM~辺りを読んでみてください。
でもうちょっとAppleScriptで見てみると・・・
ID を使うのはまぁいいとして、«data utxtXXXX»で直接Unicodeの文字を作らせてみると、やっぱりビックエンディアンで見ているのだな、となんとなく納得。
で、さっきも書いた通り、ASCII characterで作れなくなったので、直接«data TEXT82A0»でshift_JISのあを作らせてみると、この方法なら作る事は出来るらしい。
ただ、その後Logで書き出すと『あ』とはなっているけど、as Unicode Textでダメだと起こられる。AppleScript2.0からは内部の文字コードは全部Unicodeのはずだからas Unicode Textで変換するという事自体が出来なくなっているのかもしれない・・・。
まぁどうしてもの時は使えそうな事だけでも分かってよかった。
まぁ、何となく内部ではUnicode text というか、UTF-16 のビックエンディアンで統一されたというのが分かったような気になれたので、取りあえず・・・。
いろいろと弄っていて、もうパニック。
あちこち眺めていても知らない言葉ががさがさでてくる。
そもそもいったい文字コードってのはいくつ在るんだ〜〜〜。
叫んで遠い目をしそう。
思い直して先ずはちょっと整理。
ちゃんと調べて理解すべきだろうけど、もうげっそりなので、かなりおおざっぱで不正確かもしれない。
まぁ取りあえず、ということで。
さて文字コードの種類。何ともはやいろいろと在って書き抜くのも面倒なので、Wikipediaの文字コードを参照してください。
でもって私が当面の問題としているのがWindowsの機種依存文字を含んだ固定長のリストをAppleScriptで取り込んで処理して、書き出すという処理に関わる部分。
なので対象は以下。
・Shift_JIS X0213
・MacRoman(Mac版Shift_JIS)
・UTF8
・UTF16
多数の応募の中からの選考基準はAppleScriptで扱えそうな物と、扱う必要の在る物ということで。
AppleScript 2.0リリースノート(Mac OS X version 10.5)を市川せうぞーさんが訳してくれている物に詳しいのですが、AppleScript2.0は内部において扱う文字は全てUnicodeに統一されたのだと言う。
いまいちピンと来ていなかったのですが、ダイアローグ入力したりShiftJISのファイルから読み込んだりしても取り込まれると全部中ではUnicodeにされて扱われるという事のようだ。
なので、今まで「string」と「Unicode text」を使い分ける事で、Shift_JISの文字コードとUnicodeの文字を変換しながら使っていたけど、こういう事はしなくていい、というより出来なくなってしまうことになる。
で、「string」と「Unicode text」はAppleScript 2.0以前との互換性のために残してるだけだよ、ということのよう。となると、互換性を考えなければ『as text』を使いなさいという事なのでしょうか?。
さらに「ASCII character」と「ASCII number」のレガシーコマンドも動作はしますが、すべてのユニコード範囲をカバーしません。ともある。
確かに、今まで例えば『あ』を作る場合、
set Str_A to (ASCII character 130)&(ASCII character 160)
とすることで、2Byte文字を作り出す事ができが、これが出来なくなっている。上を実行すると
try
set Str_A to (ASCII character 130) & (ASCII character 160)
on error errmsg number errnum
log errmsg
log errnum
end try
Can’t make some data into the expected type. -1700
となってしまう。まぁ『あ』なら何のコードでもきちんと扱えさえすればいいのだけど、困るのはWindowsからもらったファイルを取り込むとき。
例えばカッコの付いた株の時などは、Windowsから持ってきた住所録には結構な数が入っている。
OSX10.4までは、カッコ株は
set Str_KakkoKabu to (ASCII character 135) & (ASCII character 138)
で作れて、それをStringで読み込んだ文字(ShiftJISのまま)から置き換えて、ということが出来たのだけれど、それが出来なくなってしまう。そもそもAppleScriptのUnicodeってなに?。
どうやら、世界で使われる全ての文字を共通の文字集合にて利用できるようにしようという考えで作られコード体系との事。
すばらしい、MacだWinだ機種依存文字だのなんだかんだ・・・結構うんざりなので、この精神に拍手拍手。
ところがふたを開けてみるとUnicodeの中にもUTF7、UTF8、UTF16、UTF32だのがあって、その下にもなんだかんだあるような・・・。
崇高な精神はどこいった!!。文字コードが増えただけかい!!。
とはいっても少しはいい方向へ行ってるのかな。
今、Web系はどんどんUTF8に修練していっているように思う。じゃないと韓国語だの中国語だのが混じったHPは作れないのだからそうならざる得ない。
ではWinやMacは。
こちらもMacはOSXになってから、Winも98から対応していたのがVista以降IMEの変換候補にUnicodeの文字が表示されるようになって、積極的に対応せざる得なくなってきているような感じらしい。
話を戻して、AppleScriptのUnicodeはそんなUnicodeのどれ?。ということで調べてみる、結論としてはUTF-16のビックエンディアンというやつらしい。
さて早速UTF-16なのにビックエンディアンとリトルエンディアンの2つに分かれた。やれやれ。
例えば、『あ』で違いを見てみると、ShiftJISならASCII numberの130と160の組み合せになるわけだけど、この『130』と『160』を16進数に変換すると、それぞれ『82』と『A0』になる。だからShift_JISで書き出されたファイルをバイナリーエディタなどを使ってみて見ると、『ああああ』なら『82A082A082A082A0』と並んでいることになる。
ではUnicodeのUTF-16のビックエンディアンの場合はどうか。同じように『あ』と書き込んで保存してバイナリーエディタで見てみると『4230』となっている。これはどういう数字なのだろうか。
AppleScript2.0で
set StrID to id of "あ"
=> 12354
という形でUnicodeの文字が割り当てられたID番号が返ってくる。『い』なら『12356』。『愛』なら『24859』となる。これを16進数にしてみると、『12354』は『3042』となる。エディタでみた、『4230』と『12354』を16進数にした『3042』。なんか似てる。なんだか『30』と『42』を逆さまにしたもののようだ。実はこのコードを16進数にしたのがビックエンディアンというものらしい。で逆さまにしないのがリトルエンディアン。なんでまた逆さまに、とも疑問に思うが、深みにはまるので後はUnicode ~エンディアンとBOM~辺りを読んでみてください。
でもうちょっとAppleScriptで見てみると・・・
--IDを使って文字を操る
set ChkStr to "あ"
set StrID to id of ChkStr
log "ChkStr(" & ChkStr & ") => StrID(" & StrID & ")"
--> ChkStr(あ) => StrID(12354)
set IDStr to character id StrID
log "StrID(" & StrID & ") => IDStr(" & IDStr & ")"
--> StrID(12354) => IDStr(あ)
--16進数に変換して・・・
set UTFText to <<data utxt4230>> --UTFTextを生成
log "UTFText => " & UTFText
--> UTFText => 䈰
set UTFText to <<data utxt3042>> --UTFTextを生成
log "UTFText => " & UTFText
--> UTFText => あ
--ついでにShiftJISも試す
set SJISText to (ASCII character 130) & (ASCII character 160) --SJISTextを生成
--> Can’t make some data into the expected type. -1700
set SJISText to <<data TEXT82A0>> --SJISTextを生成
log SJISText
--> あ
log ("SJISText => " & SJISText) as Unicode text
--> Can’t make <<data TEXT82A0>> into type Unicode text. -1700
ID を使うのはまぁいいとして、«data utxtXXXX»で直接Unicodeの文字を作らせてみると、やっぱりビックエンディアンで見ているのだな、となんとなく納得。
で、さっきも書いた通り、ASCII characterで作れなくなったので、直接«data TEXT82A0»でshift_JISのあを作らせてみると、この方法なら作る事は出来るらしい。
ただ、その後Logで書き出すと『あ』とはなっているけど、as Unicode Textでダメだと起こられる。AppleScript2.0からは内部の文字コードは全部Unicodeのはずだからas Unicode Textで変換するという事自体が出来なくなっているのかもしれない・・・。
まぁどうしてもの時は使えそうな事だけでも分かってよかった。
まぁ、何となく内部ではUnicode text というか、UTF-16 のビックエンディアンで統一されたというのが分かったような気になれたので、取りあえず・・・。
