とりあえず問題点は明らかになったので明日続きやろう…

wchar_t使ってると、もうUnicodeで良くね？って気分にはなりますねー

一応kakasiってUTF-8食えるってことになってたはずなんだが…コマンドラインなら動くけどlibkakasiじゃダメとかそういう話だったりする？

日本語ウェブコーパス2010→libkkcの辞書作成は一旦終わろうと思っていたのですが、変換候補に読み仮名を振る際にkakasiではなくMeCabを使ったらどうだろう→MeCabならUTF-8で処理できるからEUC-JPへの変換テーブル要らないよね→MeCab/kakasiの比較もしたいし→あーkakasiはUTF-8食わせるとダメかー、という流れで色々面倒なことになってます。

自分の雑な理解なんですが…kakasiもMeCabも形態素解析なツールなんですが、MeCabは辞書レベルでUTF-8に対応している（のでUTF-8な文字列を食わせてもちゃんと動く）のに対し、kakasiはEUC-JPな辞書そして入出力の部分でUTF-8←→EUC-JP変換を行っているのでUTF-8→EUC-JPへ変換できない要素があるとおかしくなるとかそんな話なんだと思います。

[Kakasi-dev 236] Re: U+8535で失敗 (09-Dec-2019) https://www.mail-archive.com/kakasi-dev@namazu.org/msg00196.html

「KAKASIのUTF-8対応はかなり強引で、元の設計が古いこともあってEUC-JP, SJISにない文字については考慮していません。」

mecab同様にkakasiにUTF-8な文字列を食わせるとハングするという現象に遭遇しているんだけど（ダメそうな文字をある程度はじいていてもダメっぽい）、当初行っていたUnicode→EUC→Unicodeな処理を復活させる必要を感じている。

おお、これは良い
Gitで過去に削除したファイルを検索、復元させる方法(2017/Oct/01) https://rcmdnk.com/blog/2017/10/01/computer-git/

なんかkakasiの挙動が怪しい気がするんだけど…EUCで処理させた方が安全とか、なんかバッドノウハウあったりしませんか？