いづれも「読め無いわけでは無いからそのままでええやん」って感想の人も多いかもしれないですが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（アスキーアート）とかで使うので敢えて入れてません。

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

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

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

サードパーティは切り捨てるしか無いけどクッキーは一週間あるからまあいいかと思ってたら、一部のブログ等でITP2.2からクッキーの有効期限が1日になったという記事を散見したので調査することにしました。

公式の文章を辞書を見ながら確認したところトラッキングの為に他のサイトにデータを送ったりしてる場合は1日なだけでそれ以外はITP2.1から変更無し（1週間）のままのようでした。
https://webkit.org/blog/8828/intelligent-tracking-prevention-2-2/

ITP2.3からlocalstrageに7日の制限がかかってるのも実際試した事はないし、サーバーサイドで保存されたクッキーは規制がかからないとかいう噂も聞くのでこれらを実験してみました。

クッキーやセッションやlocalstrageやindexDBの保存期間チェック

JavascriptのファーストパーティクッキーもlocalstrageもindexDBも実際は一週間で消えることは無かったですが一ヶ月ほど放置したら消えてました。localstrageの仕様的にはアクションがあったら保持期間が伸びるようなので検証の際にリロードしたのをアクションとして保存期間が伸びたのかと思われます。
一方、サーバーサイドクッキーは一ヶ月経っても残ってましたが三ヶ月ほど放置したら消えてました。
サーバーを再起動したら消えるとの書き込みを見たのでサーバーソフトの再起動してみたが消えることは無かったしサーバーOSごと再起動しても消えなかったのでサーバーサイドクッキーが消えた原因が時間的なものか別の要因があるのかは分からないけど永遠に保持されるという訳では無いようだ。

数年前には「ブラウザに長く情報を残したいときはクッキーでは無くlocalstorageを使ってね」みたいな流れでしたが諸条件にもよりますが現時点ではlocalstorageよりサーバーサイドのクッキーの方が長く情報を保持できる可能性が高いです。

※アイキャッチ画像はクッキーとコーヒー – No: 23976149を使っています。

https://tenhp.com/memotion/

今回制作に使ったDropboxのAPIはリファレンスは英語のみで以外と国内の解説が少なく今までなら翻訳サイトと行き来がとてもしんどかったのですがchatGPTがとても役立ちました。今後は日本では人気がないAPIやフレームワークも簡単に使えそうです。

以前作ってたDropboxを使ったタスク管理のWEBアプリ「TASK4BOX」はDropboxのAPIがv1の際に公式のPHP SDKを利用して作っていたのですがDropboxのAPIがv2になった際に公式のPHP版SDKが公開されなくなったので復活に結構な工数がかかってしまうことから断念していました。
それを受けて元々自分用に作り始めてたmemotionをTASK4BOXの代わりに使って頂けるようにと一般公開する事にしました。

タグの管理はフォルダの管理と違って複数のタグが適用できるので先に「仕事」とかのフォルダに入れてしまうとメモが埋もれて仕舞いがちでしたが複数のタグを付けると「仕事」でもあり「INBOX」（作業中的なタグ）のような分類が可能になり目に触れる可能性が増えました。
Reiさんの「メモを極めたエンジニア（弟）の”Notionの中身”が凄いので紹介させて下さい。」がわかりやすいです。

記述方法は元々エディタの設定でタイトルとかは色分けしたりしていたのですがブラウザで編集するにあたりMarkDownを採用しました。MarkDownなら普通に書いてもそれなりに表示出来るのでメモからにちょっと装飾するには都合がいいです。自前で実装するのは面倒なのでMarkedというのを少しいじって実装しました。

他にもvue.jsをベースにしたりアイコンはfontawesomeを使ったりして工数を減らしたつもりですが自分の使い勝手をよくするための一括変換できるようにしたりショートカットを入れたリンクボックスを作ったりブックマークレットを作ったりと小さな修正が以外と多く2週間ほどかかりましたがchatGPTが無かったらと思うとぞっとします。

「FILTER_SANITIZE_STRING」はfilter_inputやfilter_varで利用するフィルターの一つです。
特に「FILTER_SANITIZE_STRING」を多様してた訳では何ですがその名前から「文字を無害化」するというイメージで簡易的に処理したいときには使っていました。
非推奨の知らせを受けて改めて調べてみました。

公式の解説「PHP: 除去フィルタ – Manual」によるとFILTER_SANITIZE_STRINGは下記の様になってます。

タグと、エンコードされたシングルクォート、ダブルクォートを取り除きます。 オプションで、 特殊文字を取り除いたりエンコードしたりします。 クォートをエンコードする動作は、 FILTER_FLAG_NO_ENCODE_QUOTES を設定することで無効に出来ます。

削除の知らせを受けて調べてみたら「100 > <p>”テスト”</p> < 100」みたいな文字は「100 > &#34;テスト&#34; 」と微妙にな結果です。
HTMLの閉じタグはそのままですし、ダブルクォートは消えずにHTMLエンティティされてますし、右側が消えてしまってます。

私が公式の文章を見て想像したのはstrip_tagsでタグを除去してタグの記号やシングルクォート、ダブルクォートが消えた状態です。

私の想像したフィルター処理を書いて見ました。

$sample = filter_input(INPUT_POST, "sample", FILTER_DEFAULT);
if ($sample !== null && $sample !== false) {
  $sample = filter_var($sample, FILTER_DEFAULT, FILTER_FLAG_STRIP_LOW | FILTER_FLAG_STRIP_BACKTICK);
  $sample = str_replace(array('"', "'", "<", ">"), "", strip_tags($sample));
  echo htmlspecialchars($sample, ENT_QUOTES, "UTF-8"));
}

時と場合によりますがfilter_inputではチェックせずにfilter_varでチェックさせる事が多いです。
多少冗長ですが2つに分ける事で数字入力の際に全角数字を入力してしまう方の為に前もって半角数値に変換した後でバリデーションを掛けたりできたりします。
オプションは
FILTER_FLAG_STRIP_LOWはASCIIコードが32未満の文字が除去されます。改行やタブが必要な場合は前処理でエスケープする必要があります。
FILTER_FLAG_STRIP_HIGHはASCIIコードが127より大きいの文字が除去されます。マルチバイト文字を除去したい時に使用します。
FILTER_FLAG_STRIP_BACKTICKはバッククォート文字を除去します。

HTMLエンティティするならFILTER_SANITIZE_SPECIAL_CHARSというのがありますがコチラは8.1でも利用できます。
ただhtmlspecialcharsは「&quot; &gt; &lt;」と文字式ですがFILTER_SANITIZE_SPECIAL_CHARSは「&#34; &#62; &#60;」と数字式なので戻す際には注意が必要です。

SJISだと「¥」(0x5C) を検索すると「表」(0x95 0x5C) にマッチしてしまったり
EUC-JPだと「海」(0xB3 0xA4) を検索すると「ここ」(0xA4 0xB3 0xA4 0xB3) にマッチしてしまったりする。
そのため低速なマルチバイトに対応した関数（mb_）を利用する必要があった。
それがUTF-8が全盛の時代になって文字コード問題に対して配慮する必要が減ったが無くなった訳では無い。

BOM問題

文章ファイルを保存時にBOM（Byte Order Mark）と呼ばれる「0xEF 0xBB 0xBF」の3バイト文字を付けるか付けないかで、BOMありを「UTF-8」としBOMなしを「UTF-8N」と呼んだりする。Linux系のスクリプト（PHP等）ではファイルの先頭の文字にBOMがあると正常に動かないし逆にMicrosoft製のソフトではBOMが無いと正常に動かない。

〜 （波ダッシュ）問題

波ダッシュ – Wikipediaに詳しく書かれてるが古いWindowsのアプリで編集すると〜が消えてしまう。

UTF-8 4バイト問題

UTF-8に対応してると言ってもソフトによっては3バイトまでしか対応していなかったりする。
例えば「辰𠮷𠀋一郎」の𠮷（吉）と𠀋（丈）といった4バイト文字を扱おうとすると、個人的に愛用してる「Mery」も少し前のバージョンは表示できなかったし、人気DB「MySQL」もちょっと前まで未対応だった。MySQLの場合はRDS MySQL5.5.33 で『utf8mb4』(4バイト対応UTF-8文字コードセット)を試してみたを試してみたの通りすると対応出来るらしい。MySQLのバージョンや設定が変えられない場合は該当文字を実体参照にして格納する方法もあります。

function h_simplexml_load_file($url,$timeout=3,$delay=1,$repeat=5) {
	ini_set('default_socket_timeout',$timeout);
	for ($i = 0; !($rss = @simplexml_load_file($url)) && $i < $repeat; ++$i) {
		sleep($delay);
		if ($i == $repeat-1) {
			return false;
		}
	}
	return $rss;
}

ふと、simplexml_load_fileとfile_get_contentsしてからsimplexml_load_stringするのってどっちが早いのだろうと考え試してみた。

function h_simplexml_load_file2($url,$timeout=3,$delay=1,$repeat=5) {
	if (!($buffer = h_file_get_contents($url,$timeout,$delay,$repeat))) return false;
	if (!($rss = @simplexml_load_string($buffer))) return false;
	return $rss;
}
function h_file_get_contents($url,$timeout=3,$delay=1,$repeat=5) {
	ini_set('default_socket_timeout',$timeout);
	for ($i = 0; !($rss = @file_get_contents($url)) && $i < $repeat; ++$i) {
		sleep($delay);
		if ($i == $repeat-1) {
			return false;
		}
	}
	return $rss;
}

適当に某人気アイドルグループのブログ52サイトで調査してみた。

h_simplexml_load_file（simplexml_load_file）
1回目：44.2637
2回目：44.1838
3回目：44.4204

h_simplexml_load_file2（file_get_contentsしてからsimplexml_load_string）
1回目：38.863
2回目：38.7857
3回目：39.8881

意外な事にfile_get_contentsしてからsimplexml_load_stringの方が早かった。

言語ファイルと言えばプログラム業界では「.po」「.mo」といったファイルがよく見られます。（はてなの場合）
これらの言語ファイルをPHPで使うには下記の流れの作業する事になります。

1. 翻訳元の「.pot」ファイルを作成
2. ファイルを元に翻訳元と翻訳後の書かれた「.po」ファイルを作成
3. 「.po」ファイルを「.mo」ファイルにバイナリ変換
4. GetTextというライブラリで翻訳させる。

大規模なシステムだと分業しやすいというメリットはありますが「TASK4BOX」みたいな規模の小さいシステムだと大袈裟なので自前で言語ファイルを作る事にした。

翻訳文が数個なら個数分の定数（define）を設定する事も考えたが、個数が多いのでまとめたい。
そこでコンストラクタ（クラス）で言語ファイルを用意するようにした。

class language {
	const HELLO  = "こんにちは";
}

本体の方から呼び出す場所はグローバルだけで無く関数内で使用する事も想定されるので、下記のような感じで組んでみた。

echo "グローバル：".language::HELLO;
function test(){
	echo "関数内：".language::HELLO;
}
test();

ただこの方法だと変数では無いのでヒアドキュメント（<<<）で{language::HELLO}としても展開されない。
そこで、読み込み用に右から左へ受け流す関数（moody）を用意し、関数内で関数名を変数化（$moody）したものを用意し、変数化した関数を通して展開させた。

function moody($val){return $val;}
function test2(){
	$moody = 'moody';
	print <<<EOF
{$moody(language::HELLO)}
EOF;
}
test2();

このWEBツールを作るに当たってGDで文字を書くようにしました。
サーバー内のフォント一覧を調べるには下記のようにfindというlinuxの検索のコマンドを使います。

find /usr/local/fonts -name "*.ttf"

phpだと下記のようなスクリプトで検出できます。

<?php 
exec('find /usr/local/fonts -name "*.ttf"', $stdout);
print implode("<br>\n",$stdout);
?>

（もしCentOSだと/usr/local/fontsを’/usr/share/fonts’とかすると見つかるかと思います。）

coreserverの場合下記のような結果になりました。
/usr/local/fonts/wadalab-gothic.ttf
/usr/local/fonts/arib____.ttf
/usr/local/fonts/helcbi__.ttf
/usr/local/fonts/heli____.ttf
/usr/local/fonts/timi____.ttf
/usr/local/fonts/helb____.ttf
/usr/local/fonts/timb____.ttf
/usr/local/fonts/helbi___.ttf
/usr/local/fonts/timbi___.ttf
/usr/local/fonts/arir____.ttf
/usr/local/fonts/helcr___.ttf
/usr/local/fonts/starmath.ttf
/usr/local/fonts/kochi-mincho.ttf
/usr/local/fonts/chvor___.ttf
/usr/local/fonts/watanabe-mincho.ttf
/usr/local/fonts/helr____.ttf
/usr/local/fonts/timr____.ttf
/usr/local/fonts/kochi-mincho-subst.ttf
/usr/local/fonts/sazanami-mincho.ttf
/usr/local/fonts/chvr____.ttf
/usr/local/fonts/kochi-gothic-subst.ttf
/usr/local/fonts/kochi-gothic.ttf
/usr/local/fonts/helcb___.ttf
/usr/local/fonts/starbats.ttf
/usr/local/fonts/cogb____.ttf
/usr/local/fonts/helci___.ttf
/usr/local/fonts/sazanami-gothic.ttf
/usr/local/fonts/cogr____.ttf

日本語は8つあります。最近よく見かけるIPAフォントは無いですが十分です。
渡部ゴシック（wadalab-gothic.ttf）
渡部明朝（watanabe-mincho.ttf）
東風ゴシック（kochi-gothic.ttf）
東風明朝（kochi-mincho.ttf）
東風ゴシック代用（kochi-gothic-subst.ttf）
東風明朝代用（kochi-mincho-subst.ttf）
さざなみゴシック（sazanami-gothic.ttf）
さざなみ明朝（sazanami-mincho.ttf）

今回は「さざなみ明朝」にしました。

プログラム的には下記のように毎年画像が生成されるようにしました。

<?php 
$Y = date("Y");

$fname = './icon'.$Y.'.png';
$gengo = '平成';
$nensu = ($Y-1988);
if (!file_exists($fname)) {
	if (!extension_loaded('gd')) {
		exit('GDモジュールが無い。');
	}
	$img = imagecreatetruecolor(256, 256);
	$font = "/usr/local/fonts/sazanami-mincho.ttf";
	$background_color = imagecolorallocate($img, 64, 64, 64);
	imagefilledrectangle($img, 0, 0, 300, 300, $background_color);
	
	$text_color = imagecolorallocate($img, 255, 255, 255);
	imagettftext($img, 66,  0, 38,  95, $text_color, $font, $gengo);
	imagettftext($img, 121, 0, 50, 240, $text_color, $font, $nensu);
	imagepng($img, $fname);
	imagedestroy($img);
}
?>

後は作った画像をapple-touch-icon-precomposedで指定して完成です。

元号アイコン

PHPのパフォーマンス改善(3) | Selfkleptomaniac
という記事にstrncmpを含んだ3つの方法が書かれていたので計5つの方法のベンチを取って比較してみた。
（各秒数は約8万行を検索したしたベンチの10回分の平均値。）

strncmp版（先頭から特定文字数分検索する関数）
if (!strncmp($myvalue, $searchstr, 5)) ～
0.0312 sec

substr版（文字列を部分抽出する関数）
if (substr($myvalue, 0, 5) == $searchstr) ～
0.0447 sec

preg_match版（正規表現を利用した検索）
if (preg_match(‘!^’.$searchstr.’!’, $myvalue)) ～
0.0578 sec

substr_compare版（特定部分から特定文字数分検索する関数）
if (substr_compare($myvalue, $searchstr, 0, 5) == 0) ～
0.0415 sec

strpos版（文字列の開始位置を検索する関数）
if (strpos($myvalue, $searchstr) === 0) ～
0.0297 sec

おっしゃる通り「strncmp」は速く「preg_match」は遅いが「strpos」が予想以上に速く、単純な文字列の検索も今回のような特定位置の文字列検索も「strpos」が最速という結果になった。