いづれも「読め無いわけでは無いからそのままでええやん」って感想の人も多いかもしれないですがWindowsのファイル名にUTF-8-MACを使うと一部のソフトで不都合が起きたりスクリプトで検索の際に別の文字なのでヒットしないという問題が発生しますので、マックユーザー向けにファイルアップロード機能を付けるときやPDFの内容をコピペする可能性の高いフォームでは有用かと思います。

言語はJavascript版とPHP版を用意しています。
中味はWikipedia等で情報を集めて置換してるだけですが、最初にテキストに該当箇所が無ければ変換処理をしないので負荷は低いかと思います。

Javascriptの方はnormalizeという関数が用意されていて
UTF-8-MAC問題だけなら.normalize(“NFC”)、康熙部首も変換したいなら.normalize(“NFKC”)と実行すると変換可能でネイティブな分処理的には速いのですが
多言語用の不必要な文字も変換されてしまうのに、CJK部首補助が変換されないという
濁音半濁音だけでなく全ての言語を正規化するので結果負荷が多めなので自前で用意しています。

PHPの方もNormalizer::normalize()があり、php-intlをインストールするか有効化すると使えるが
Javascriptnormalize関数と同様に多言語対応のライブラリで冗長なので自前で変換テーブルを用意して変換しています。

Githubとかいいから使ってみたいって方のためにお試し版も用意してます。
https://uda2.com/github/jpnormalizer_sample.php

※UTF-8-MAC（NFD）の問題はMacのファイルシステムがHFS+からAPFSになってかなり減ってます。
※NFCの変換するなら半角→全角も組み込んでも良さそうですがAA（アスキーアート）とかで使うので敢えて入れてません。

まず、各コンテンツの概要をChatGPTに送ってキャラ設定の案を作成。それを叩き台にして実際の設定を固めました。下記のように動物の種別でグループ分けしています。

• 画像変換系 → 犬
• フォント系 → ネコ
• ソート系 → 鳥
• テキスト変換系 → 爬虫類

キャラ設定がまとまったら、再びChatGPTにプロンプト作成を依頼。日本語でも良かったのですが、今回はレトロカートゥーン風ということもあり、英語でのプロンプトを採用しました。（ただし、プロンプトは荒ぶることも多いので、手直しは必須です）

画像生成はGoogle Geminiにお願いしました。Geminiはカートゥーン調のイラストが得意で、しかも生成回数も多いのが魅力。
もちろん、実際には色の塗り直しや合成、サイズ調整、不自然な文字や描き込みの削除など多少の修正は必要です。それでも、15体ものキャラクターを一日で作れてしまうなんて、本当にすごい時代になったもんだ。

• schema.sql（CREATE TABLEを全部書いたDDL（最終仕様のソース））
• tables.md（テーブル定義書（上記の表形式でMarkdown化））
• erd.png（ER図のスクショ）

schema.sqlは｀mysqldump -u ユーザー名 -p --no-data データベース名 > schema.sql｀でみたいな形で簡単に書き出せる。
erd.pngはtables.mdがあればdbdiagram.ioのようなWEBツールで作成できる。

あとはschema.sqlをtables.mdに変換しできれば最低限の形が整うのですが変換ツールが見つからなかったので作ってみた。
https://tools.uda2.com/sql2md.html

とはいえ、コアな部分はAI（Claude）に作ってもらったので特に書くことは無い。
（しかも、今回のこの記事はカバー画像もAI（chatGPT）に作ってもらった。）
私がしたのは軽い修正とウダツールスのパッケージに収めただけです。

大抵のブラウザでWebpの表示はできるようになったが流石に生成は無理だろうからPythonでもいいから作ってくれないかと思ってChatGPTに聞いたらさくっとブラウザで動作するものを作ってくれた。昨今のブラウザは表示はもちろんで作成もできるるらしい。
そこから、見た目を他のツールと統一感を持たせて、操作感をいい感じに整えるのに半日ほどかけて調整。AIのおかげで個人的に使う分にはすぐに作成できるけど、公開するレベルのものとなるといまだ時間はかかってしまう。

そんな中、ChatGPTが「AVIF形式にも対応できますよ」と提案してきたので試してみた。けれど、いざ実行するとPNGに変換されたり、拡張子だけAVIFに変えて実体はPNGのままだったりと、おかしな挙動が出てきた。修正を頼んでもうまくいかず、Geminiにも相談してみた。

Geminiの方は「canvas.toBlob(…, ‘image/avif’)」によるAVIF出力の対応状況を尋ねても、「Safari以外の主要ブラウザではサポートされています」と返ってくる。けれど、実際にはうまく動かない。出力対応と表示対応を混同していたり、ソースを出しても「表示」対応の話ばかり。Geminiとは1時間近くやり取りしてもハレーションがひどくなる一方で埒が開かない。

結局もう一度ChatGPTに戻って聞き直してみたところ、「現時点では、主要ブラウザはAVIFの表示には対応しているが、canvas.toBlob(…, ‘image/avif’)による出力には未対応」との結論に。真偽は不明だけど、自分の環境でも正常に出力できなかったので「現時点でAVIFの出力に対応したブラウザは無い」という事にした。

代替手段としてChatGPTが提示してきたのが、avif.js（@jsquash/avif）というライブラリ。これはGoogle製のAVIFエンコーダー「libavif」をWebAssembly（WASM）化したもので、クライアントサイドだけでAVIF変換を行うことが可能らしい。

ただし、これも一筋縄ではいかない。最初に提案されたCDNバージョンはすでに開発が終了していたようで見つからず、現行のNPMパッケージの方にはCDN版が用意されていない。ChatGPTがjsDelivrにある古いバージョンを勧めてきたが、CORS（クロスオリジン）の制限や外部依存が気になり、最終的に自分のサーバーにインストールすることに。

ところが、パッケージはNode.js用のモジュール形式（CommonJS/ESM）で、そのままではブラウザでは動かせない。ChatGPTの指示に従ってビルド済みのJS（avif.min.js）を生成したが、WASMファイル（avif_enc.wasm）は自動で出力されなかった。インストールフォルダ内にあったWASMを手動でコピーしたところ、なんとか動作するようになった。

とはいえWASMはネイティブアプリではないため、AVIFへの変換処理は正直言って遅い。それでも、クライアントだけでAVIFを生成できる手段としては現状これが一番実用的かもしれない。

このファイルの差分を確認する機能のあるFTPクライアントソフトをFileZilla、WinSCP、Yummy FTP、ForkLift と渡り歩いてました。
WindowsはFileZillaを使ってたのですがGumblarのニュースを見てより安全とのふれこみのWinSCPに切り替えてから今も満足してるのです。ただMacの方は有償のYummyを使ってたのに開発中止になり数年で使用不能になりForkLiftも有償ですが使えてたのですがいつの間にか差分ソフトの起動ができなくなり最新版にしようと思ったらバージョンが上がって月額払わないと使えなくなりました。

ChatGPTやGoogle検索で差分が見れるMac用FTPクライアントソフトを探したが無償や買い切りで良さそうなのは見つけられませんでした。

代替え案としてリモートのファイルをプレビューする機能とかは付いてるものが多いので一時フォルダにダウンロードする機能は多くのFTPクライアントソフトに備わってる。そこで比較ソフトに送れないかと考えた。

FTPクライアントソフトは普段使ってるTransmit（有償）を使うとして、差分を確認するツールは以前はXcodeを使ってたのでFileMergeで差分を表示してたのですがXcodeを長らく使ってないので他のツールを探すためChatGPTに聞いたがおすすめされたMeldとDiffuseは開発が止まってるのかHomebrewでインストールできなくなってたので以前使ったことがあるCompareMerge2の無料版を使う事にした。

具体的な手順は下記のような感じ。
1. Transmitで接続しリモートのファイルを選択。
2. 右クリックから「このアプリケーションから開く」からCompareMerge2を選択。（又はDockのCompareMerge2にドラッグ）
3. すると一時ファイルにダウンロードされたリモートファイルが入る。
4. 比較対象のもう一つの枠にローカルのファイルをドラッグ＆ドロップする。

手数が多いですが他のFTPソフトが対応するまでこの方式で我慢します。

まず、ライトはamazonとかで売ってる紐に添わせるタイプのライトを買いました。（私は白が欲しかったのでアリエクで買いました。）

付属の紐だとバンドの方向の問題でうまくハーネスに固定できないのでハーネスの中央の紐を切ります。
（デザインカッターで縫い目を拡げながら糸を切ると簡単に取れます。）

そしてキャンドゥでゲットした「リュック肩ズレ防止ベルト」のベルト1本と留め具2個を拝借します。
ベルトを図のように通して固定します。（ライトの穴が小さいので強引に入れないと入らないです。）

しばらく使ってたのですが電池が1個から2個になった事もありペンダント型と比べ明るくなったのはいい事だが一週間ぐらいで電池切れるので金銭的にも環境的にも負荷が大きい。そこで充電式ボタン電池を使うことにした。
充電式にしたらすごく明るくなる反面1.5日くらいで切れるようになった。
電気に詳しくは無いが充電池は直列につなげたら放電し続けるのかもしれない。

よく調べると充電ボタン電池のLIR2032が3.7Vで使い捨てのボタン電池CR2032が3Vなので試しにボタン1個でやってみたら意外と明るかったのでボタン電池一個で収まるようにしていきます。
ボタン電池サイズの金属があればいいのですが見つからなかったので近しいサイズの1円玉を挟みつつ、反対のフタ側からグラつきを抑えるため100均の少しクッションの付いた滑りどめを小さく切って貼り付けました。接点が小さくなるので不安はありましたが特に問題無く点灯しています。
ボタン1個でも4日ほど保っています。

差異のある文字をピックアップしたアスキー表を作成しました。（全文字コードはコチラ）

デコードは概ね問題無いが「+」を絡めると誤変換が起こる。
例えばサーバー側でrawurlencode()やurllib.parse.quote_plus()を使ってエンコードした文字列をブラウザのrawurlencodeでデコードすると誤変換が起こる。
なのでサーバーでもクライアントでも使うなら「+」を使わないdecodeURIComponent()・urllib.parse.quote()・rawurldecode()がオススメです。

なお変換するならURLエンコードとデコード -UDA TOOL-を用意しております。