Naganoya指定フォルダ以下のすべてのファイル名とフォルダ名から絵文字を除去するAppleScriptです。StanleyのremoveEmojiルーチンを使っています。10.14.1で絵文字が大幅に追加されたため、これらの絵文字をファイル名に用いていた場合には10.14.1以下のバージョンのOS環境にそのままファイルを持っていくことができません。コピーできない(エラー)という状態になります。絵文字自体に害はないのですが、規格がコロコロ変わる(追加される)ことで、ファイル名に用いるのには問題があるということでしょう。▲もともとのファイル名、フォルダ名。絵文字を大量に使用している(普段はファイル名に絵文字は使っていません)▲本Scriptで一括で処理したファイル名、フォルダ名。pathを用いて指定フォルダ以下すべてをリネームするようなScriptは組んでいなかったので、ちょっと考えさせられました。10.13.6の環境に持っていけました。絵文字がないと寂しい感じがします指定フォルダ以下のファイル/フォルダを一括取得するのに、今回はあえてSpotlightを使っていません。ファイルサーバー上のファイル/フォルダを処理する可能性がありそうなのと、外部ライブラリを使わないほうがよいと考え、このような構成になっています。Stanleyから投稿してもらった(いただいた)実用レベルの絵文字削除ルーチンです。いろんな方面からツッコミが入って、徐々に実用レベルに到達するのではないかと予想していた絵文字削除ルーチン、いきなり最終兵器的なルーチンの登場により、「これでいいでしょ?」と思えるレベルに到達しました。そこは一応「すべての絵文字」を入力して試しておく必要を感じるところ。手作業でぽちぽちキーボードから(絵文字バレットから)絵文字を入力しまくって本ルーチンで処理してみたところ、どうも文字コード上の「飛び地」にあるとおぼしき絵文字が消えません。削除テーブル部分に「消えなかった絵文字のコード」をこれでもかと追加しまくり、削除対象文字テーブルを強化してみました。一部、対象文字よりもひろめに削除範囲が指定されている箇所もありますが、本ルーチンは主にファイル名に対して使用された絵文字を除去してファイルの後方互換性を確保すること(最新のOSよりも古いバージョンのOSとファイルを安全に交換すること)が目的なので、そんなマイナー記号類が削除されても気にしないことにします。すべての絵文字が削除されたわけではないといいますか、絵文字っぽい文字でなくなっただけで残っていたりもするのですが、今度はこれらの文字を消すと実害もありそうなので、現状ではこのぐらいでよいかと思われます。CotEditorのメニューに突っ込んで、選択範囲の絵文字を削除できるようにしておきました。NaganoyaNumbersで選択範囲のセルから数字以外の文字を除去するAppleScriptです。Webブラウザ上で表示中の表データからNumbersなどの表計算ソフトにデータをコピー&ペーストして再利用することがあります。この際に、Webブラウザ上で選択中のDOM構造などを取得できると便利なのですが、いろいろ調べてみてもなかなか方法が見つかりません(自分が設計していたら、絶対に実装してるんですけれども)。そこで、表データをWebブラウザから表計算ソフト上にコピー後にデータ加工することを考えることになります。ExcelやNumbers上に表データをペーストして、その後で加工することをよく行います。手動で行うとかったるいので、選択範囲のセルを順次加工するScriptを日常的に作ってはストックしてあります(セル内の改行文字を削除するとか、いろいろ)。v6.1で検証してあります。Menuに入れて呼び出して利用しています。Numbersのセル書き換え速度はそれほど速くないので、数百セルとか数千セルを一気に書き換えるような用途は考慮していません。いう用途には、書き換えたデータをCSV書き出しして、CSVのファイルをNumbersでオープンするといった処理になると思います。NaganoyaNumbersの表のカラムを表現するアドレス文字列(26進数)と数値の間のエンコーダーおよびデコーダーのAppleScriptです。2004/2008で採用されたカラムアドレス形式に対処するためのScriptでした。Excel上のセルのアドレス(場所)を指し示す方法は、「R1C1」(行とカラムを数値指定)形式、あるいはAppleScriptの行オブジェクトとセルオブジェクトで指定する形式でした。そこへ新たに「A1」形式......画面上で表記されている行、カラムと親和性の高い形式が採用されることになりました。当初は相互変換のための関数なども用意されていなかったと記憶しています(間違っていたらご指摘ください)。そのため、Scripterが自力でこのA1形式に対応する必要が出てきました。そんな中、Excel書類にAppleScriptを埋め込んで実行するAppleScriptを開発。本ルーチンはそのScript開発のために作成したものです。2008でVBAの処理系が外されてMac上のVBA的なマクロ処理はAppleSctiptに一本化されるという話になっていたため(当時の話)、これを好機ととらえ、マイクロソフトのご担当にデモして、US本社で紹介していただくということになりました。その会議上でVBAの復活プランが発表され、自分の提案したプランは廃案に(まさか当時のREALbasicのコンパイラの開発者を引き抜いてきてVBAの処理系をスクラッチで書かせるとは思いませんでしたわー)。2011でVBAの処理系が復活。本ルーチンも割とHDDの肥やしとして絶賛在庫状態になっておりました。2011でVBAの処理系が復活したことを知らない方がいて、「VBAで動いているマクロをAppleScriptに移植してほしい」という問い合わせがあるのですが、「Excelの最新版を購入してください。VBAがありますよ」とお返事しています。最新のExcelが動く環境を購入する費用よりも安く仕事としてお受けすることは困難なので。そこから年月が流れ、AppleがNumbersをリリース。2004/2008と同じ形式になっているために、しまいこんでいたルーチンをふたたび引っ張り出してきた次第です。一応、条件つきで使えるものの、作りが古い(やっつけ仕事な)点が気になります。誰かがもっといいルーチンを作って使っているに違いありません。一応、本ルーチンでは1〜1351の範囲での動作を確認しています。改良したいところではあります。実用上は、Numbersでそこまで大きなデータは扱わない(はず)ので、問題はあまりないものと思われます。IDを抽出するAppleScriptです。Naganoya青空文庫のテキストのルビタグをすべて削除するAppleScriptです。CotEditorでオープン中の青空文庫のテキストからルビタグを削除し、元のドキュメントに置換結果を反映させます。テストに使用したのは、夏目漱石の「こころ」のテキストです。上記ページの「テキストファイル(ルビあり)」をダウンロードして、Zipアーカイブを展開して使用しました。囲われたエリアをすべて削除するという、AppleScriptにはあからさまに不得意そうな処理で、最初に書いたAppleScriptでは1分半以上かかっていました。内容は、おおよそ常識的なサブルーチンを組み合わせてループで回しただけです。遅くなるように組んだりはしていません。これを、(1)CotEditorからの文章テキストの取得(2)置換当該箇所のリストアップ(3)文字置換(4)CotEditorへの文章テキストの転送の4つのステージに分け、それぞれ処理時間を計測。すると、(1)、(2)、(4)については1秒かかるかかからないかぐらいの速度で実行していることが判明。圧倒的に(3)文字置換の処理に時間がかかっていました。delimitersを用いるサブルーチンを使用していました。これ以上、この方向に頑張っても速く処理することはできません。delimitersを作成し一括処理できないか試してみたものの、さすがに処理系のキャパシティを超過しているようで処理が戻ってきません(迷走状態)。delimitersによる処理をやめ、メモリ管理効率がよくないAppleScriptのstring型のデータで保持することをやめ、置換のたびにAppleScriptのstring型に変換(cast)することをやめ、置換中は最初から最後までNSMutableStringで管理するようにしました。このように大幅に書き換えたところ、トータルで3.58秒で処理終了するようになりました。すべての置換が終了したあとにNSMutableStringをAppleScriptのstringに変換し、CotEditorの最前面のドキュメントに結果を転送しています。List(配列)に入れた文字要素を文字種類で該当するものだけ抽出するAppleScriptです。文字種類でデータ抽出する、という用途はけっこう多いので、単体で使えるようにしておきました。英字:”A”半角記号:”$”ひらがな:”ひ”カタカナ:”カ”漢字:”漢”で文字種類を指定します。以前のバージョンではありもののルーチンを組み合わせただけなので、全体的に無駄があって処理速度についてはあまり感心できないレベルだったので、若干の高速化を図りました(繰り返し処理部分で無駄な演算を省略)。「ひらがな+カタカナは許容する」というふうに、複数の文字種を許可する例が多いので、これではまだ実用レベルには達していないと思います。