残念ながら回答や情報を得られなかったため、自身で調べて解決をいたしました。
細かいニュアンスを伝えるのが難しいので、申し訳ないですが日本語のまま書かせていただきます。
昨今はGoogle翻訳やDeepL翻訳が発達していますので、翻訳してお読みいただければと思います。
日本、もしくは非英語圏の方の参考になりましたら幸いです。
結論から申し上げると、原因はCID Superfectaのバグです。
バグというよりは、ISO-8859-1で表現できない文字を考慮していないプログラムです。
このフォーラムでもドイツの方が似たような問題を報告しているのを見掛けました。
ただ、日本語が文字化けする問題とは少々異なりますが…
まず、superfecta_single.php内の64行目でUTF8のデコード処理が行われています。
$caller_id = $this->_utf8_decode($caller_id);
_utf8_decode関数の内容を見ると、html_entity_decodeを通した後にutf8_decodeを通して値を返しているようです。
function _utf8_decode($string) {
$string = html_entity_decode($string);
$tmp = $string;
$count = 0;
while ($this->isutf8($tmp)) {
$tmp = utf8_decode($tmp);
$count++;
}
for ($i = 0; $i < $count - 1; $i++) {
$string = utf8_decode($string);
}
return $string;
}
html_entity_decodeを通すのはいいとして、なぜUTF8をISO-8859-1にデコードしているのかよくわかりません。
UTF8のままで問題はないかと思いますし、そもそもutf8_decodeはPHP 8.2.0で非推奨となり、今後使用しないことが強く推奨されています。
そして84行目で結果を表示する際に、わざわざISO-8859-1にデコードした結果を一時的にUTF8へ再エンコードして表示するというまた意味の分からない処理を行っています。
さらにここでもutf8_encodeという将来的に非推奨となる関数が使われています。
print "'" . utf8_encode($caller_id) . "'<br>\nresult <i class=\"fa fa-hand-o-up\"></i> took " . number_format(($this->mctime_float() - $start_time), 4) . " seconds.<br>\n<br>\n";
UTF8で受け取ったデータを変換して内部的にISO-8859-1で保持し、表示の際にわざわざUTF8に直すのであれば、最初からUTF8で持っていればいいように思います…
コメントや仕様書を見たわけではないので正直理解に苦しみますが、このような処理が行われているようです。
そして、当然ですがISO-8859-1は日本語を扱えませんので既にここで文字化けします。
次に、stripAccentsを使って入力された文字列から分音記号を削除する処理が入ります。
具体的にはSuperfecta.class.phpの211行目でif文による分岐が入り、IA5文字コードありと判断された場合、
$callerid = $superfecta->stripAccents($callerid);
このような処理が実行されます。
この処理にも正直何の意味があるのかわかりません。
UTF8であれば分音記号を含む文字を正しく表現できます。
さらに言えば、ISO-8859-1でも分音記号を扱うことができます。
分音記号を表現することに不都合があるのであれば別ですが、ドイツ語を使用しないので分かりかねます…
それはともかく、このisCharSetIA5はIA5の文字コードを含むか含まないかを特に判別していないように見えます。
関数の内部を見ると
protected $charsetIA5 = true;
function isCharSetIA5() {
return $this->charsetIA5;
}
でtrueが返って来るだけなので、将来的に判別が必要になったときを考慮して処理を入れるようにしたが、現状英語が処理されても問題ないためすべての結果を処理するようになっているのでしょうか。
ただ、当然日本語は問題で、文字コードがおかしなことになっている状態で通されるので更にめちゃくちゃな文字になって帰ってきます。
また、この関数は内部でhtml_entity_decodeを行っています。
function stripAccents($string) {
$string = html_entity_decode($string);
$string = strtr($string, "äåéöúûü•µ¿¡¬√ƒ≈∆«»… ÀÃÕŒœ–—“”‘’÷ÿŸ⁄€‹›fl‡·‚„‰ÂÊÁËÈÍÎÏÌÓÔÒÚÛÙıˆ¯˘˙˚¸˝ˇ", "SOZsozYYuAAAAAAACEEEEIIIIDNOOOOOOUUUUYsaaaaaaaceeeeiiiionoooooouuuuyy");
$string = str_replace(chr(160), ' ', $string);
return $string;
}
_utf8_decode関数の内部でhtml_entity_decodeを通して、またここでも通しています。
二重に処理をする意味が分かりませんし、正直無駄な気がします。
そして仕上げに、223行目にてこの壊れた文字データをUTF8に再変換するという処理を行っています。
ここではmb_convert_encodingを使用していますが、問題は入力される文字コードがISO-8859-1と決め打ちされています。
既に分音記号の削除処理がされている時点でまともな文字データにはなっていないのですが、それを更にISO-8859-1としてUTF8に直すという処理が行われています。
まとめると、UTF8のデータをISO-8859-1にわざわざデコードし、ラテン文字しか使用できず他は文字化けするように変換し、ブラウザ上にprintするときは一時的にUTF8でエンコードしてから表示させ、そこから分音記号の削除処理をされ、今度はそれをUTF8に直すというめちゃくちゃな処理を行っています。
これがCID Superfectaが日本語を正しく処理できない原因です。
というより、日本語どころかISO-8859-1で表現できない文字は全て扱えない、文字化けするかと思います。