うーん、なんとなくだけどktermで使え、という気がするんだよな。あるいはkon。fbtermはds/fsのエントリ無し。

ktermのUTF-8版とか、あるはずだと思うんだけど普及(?)してるのかなあ。

/etc/termcap、
xterm+sl|access X title line and icon name:\
:hs:\
:ds=\E]0;\007:fs=^G:ts=\E]0;:TS=\E]0;:
なんてのがあるくらいなのでおそらくデフォルトのxtermはステータスライン(ds/fs)は非対応。ktermはds/fs装備済なのでってことで。

ふーむ、buffer modeにおけるカーソル/BSの挙動が全般的に怪しげ、という理解。

GoogleブックスのLinux日本語環境、xclipboardのスクリーンショットの中にもkanjihandの名前が出てるんだけど（ってGoogleさんそこ認識するんですか…！） https://books.google.co.jp/books?id=0uTiYB_rMDQC&pg=PA215&printsec=frontcover&dq=kanjihand&newbks=0&hl=ja&ovdme=1&redir_esc=y#v=onepage&q=kanjihand&f=false
当時の日本語環境の歴史を知る上で、この本を押さえておくべきなんだろうか。

BSD256倍本買っといて正解だったかも。KanjiHandとかWorld21なる、日本語表示環境があることを知ることができたから。とはいえ、ぐぐったところで
http://x68000.q-e-d.net/~68user/unix/pickup?KanjiHand
http://x68000.q-e-d.net/~68user/unix/pickup?World21
http://ukai.jp/Articles/1993/sd-pc98unix.txt
その存在があったことくらいしか知ることはできないようだ。

「神奈川県のアレ」って何を指してるんだろう。なんか色々ありすぎて…

b.の採用もなくはないか…4byte目までデコードしたけどそこで打ち切り、次から表示ね、という動きになるなら。

問題は不正なコードを食らった場合の処理なんだけど、どうすれば良いんだろう。6byteで1文字を構成するとして…4byte目が不正だったら…

a. 1～3byte目を棄却して4byte目から吐き出す
b. 1～4byte目を棄却して5byte目から吐き出す
c. 6byte全部を棄却する
d. 6byteを丸ごと吐き出す

※棄却した場合は〓とか表示して異常があったことを示す

のどれかにはなりそうなんだけど。

（a.は4byte目のデータを信用できる場合、b.は信用できない場合…おそらく多少信用できないデータでもなんか吐いといた方が分るだろうという判断で、b.を採用するケースは低い気がする）

やっぱこの対応が自然ですよねえ。
「4バイト以上の文字は現状のTera Termでは表示できないが、デコードだけでも正しく行うべき。」(2009/6/18)
https://ja.osdn.net/projects/ttssh2/ticket/17228

Oracle寄りだとCESU-8の絡みもあって、UTF-8は6byteでーすと書くしかないんだろうか。
文字化けについて (2023.10.17) https://www.reqtc.com/column/post-11.html

とはいえ、自分のこのポストに対して「CESU-8とUTF-8は違う！💢」と石が飛んできそうだ。
https://www.wdic.org/w/WDIC/CESU-8
https://www.unicode.org/reports/tr26/tr26-4.html

SIMD命令を用いるUTF-8文字列デコード処理の高速化(情報処理学会論文誌 プログラミング Vol.1 No.2 Sep 2008) https://cir.nii.ac.jp/crid/1050564287843900160
ベクタ演算で高速化できるのは良いけど、不正なコード食らわせた場合にどういう動きをするのかは気になるところ。予めクリーニングしてからデコードさせるのかなあ（だとしたらクリーニングのコストはどうなる…）？

日立の（何かの製品の）UTF-8変換だと、未定義というか不正な文字コードに対しては半角スペースなり＃（全角の#）なりを吐き出せるようになってると。 https://itpfdoc.hitachi.co.jp/manuals/3020/3020657500/W5750016.HTM

不正なコードは変換せずスキップというのは…そのまま吐き出す、ってことで良いんだろうか。 https://itpfdoc.hitachi.co.jp/manuals/3020/3020636230/W3620027.HTM

ん－、CESU-8だのRFC2279の5～6byte UTF-8を食らった場合はどう対応するのが適切なんだろう。現在のRFC3629非準拠なものには対応しない、おかしくなっても知らんがな、で良いならそうするけど…その差異をセキュリティホールとして突かれる可能性があるなら、考えないといけないし。

UCS-2←→wchar16_t変換テーブルのジェネレータ、一応こんな感じ。 https://pastebin.com/raw/cZXjnifj
Debianのiconvってなんだかよく分からないんだけどC1 control領域(U+0080～U+009F)に対してよく分からない変換をしてくれるので外しておく必要があるのと、private領域(U+e000～U+f8ff)もなんかよく分からない変換をしてくれるので(ry
サロゲート領域(U+d800～U+dfff)については嫌な予感がしたので最初から変換対象に入れてません。

nwc2010-libkkcを直して（mappingの影響範囲はこんな感じ https://github.com/jg1uaa/nwc2010-libkkc/commit/14f6e66ecd27c04572ebdf1ceb1e4243b1768183#diff-48b245bdedad582320549b593c4a9b59b83f11d116cd81005b46f2ff5764d8c7 ）とりあえずiconv()によるUCS2/JIS変換の評価はおしまい。

これをベースにsj3用のwchar16_t/UCS2変換を作れば良いかな（というかwchar16_t/UCS2変換が先だったりするんだけど）。

JIS0208.TXT(obsolete)なUnicode/JISマッピング対応表を使うのを止めて、iconv()での変換結果から対応表を作ってみたけど、JIS0208.TXTの結果とそう変わらない（\~の部分が若干違う程度な）ので今後はiconv()を使うことにします。

というかフツーiconv()で変換してますよね…？

出先だったんですが、揺れましたねえ。あれで震度３…

そういえば、不正なサロゲートペアの組み合わせってどう処理されるんだろう。たとえば

上位サロゲートの後にサロゲートでないUCS-2が続く
下位サロゲート・上位サロゲート（順番が逆）
下位サロゲートのみ（上位サロゲートが無い）

なんてケースもあるはずで。

こういう時に、不正なので取り除くのか、不正っちゃ不正なんだけどなんかあるので残しておくけど無視するのかというどっちの対応が適切かというのは問われるよね（そして仕様書にはどうすべきか記載があると思うんだ…読めよ＞自分）

ふと思ったけど、iconvでEUC-JP/UCS-2テーブルを作った場合、そのテーブルのライセンスって何になるんだろう。JIS0208.TXTを使った場合はこのテキストに合わせて(?)Unicode-TOUになってるけど…OpenBSDの場合はGNU iconv使っているからやっぱGPLになるんですかねえ？

読み仮名の付与にkakasiを使う時しかこの変換は通らないので、mecab-neologdを使う場合への影響はないと思うけど。

多分これでucs2←→wchar16（sj3の内部コード）変換はできたはず。これだったら…以前作ったnwc2010-libkkcのUCS-2←→EUC-JP変換も古いテーブル(JIS0208.TXT)を使うんじゃなくlibiconvから生成したテーブルを使うようにした方が良いのかも。

もしかして、iconvのTRANSLATEオプションを使うとEUC-CN←→EUC-JPをそれっぽく変換してくれたりするんだろうか

…でもないか？記号類なんかは一応あるように見えなくもない。

むー、UCS-2の範囲だとSS3(3byte EUC)の対応はできないのか。