2016年12月30日金曜日

CompositionEventを利用してフリガナを取得する(その2)

中身や仕様は全く違うけど、一応はautoKana.jsの改変バージョンと言う事でautoKana2.jsとしてみた。(^_^;)

目的


JavaScriptでWindows APIのImmGetCompositionStringの取得結果になるべく近づけること。
.NETでのコーディング例はこちら
# 汎用性を考えたらTextBoxを継承したカスタムコントロールを作った方が簡単な気もするけど、その辺は好き好きで。

動作仕様

  1.  autoKana.jsとI/F互換
  2. 日本語IMEの各種入力モード(ひらがな、全角カタカナ、全角英数、半角カタカナ)で入力されたIME変換前の文字列をフリガナとして取得する。
  3. キーボードから入力可能な英数字記号をそのままフリガナとして取得する。
  4. IEおよびEdgeでEnter以外のIME確定時にcompositionendイベントが発生しない不具合に対応。
    (例)やまだ と入力してIME変換後にEnterを押下せず たろう と入力
  5. IEおよびEdgeで全角SPを入力時にcompositionupdateイベントが発生しない仕様に対応。
  6. IE11およびEdgeでMS-IMEでIME確定前に入力中のテキストボックスをクリックした際にIMEが確定しない不具合に対応。
  7. 日本語から英数字記号に変換した場合は最初の日本語をフリガナとして取得する。
    (例1)いち と入力して 1 に変換した場合、フリガナは いち として取得
    (例2)かっこ と入力して ()に変換した場合、フリガナは かっこ として取得
  8. 末尾のNの不足の自動補正する。
    (例)にっさnと入力して変換した場合、フリガナは にっさん として取得する
  9. MS-IMEのNとMタイプミスの自動補正された場合、blur時にアラートを表示する。
    (例)かせmじき と入力して 河川敷 に変換した場合
  10. MS-IMEのIME変換後の確定前でのBSキーによる削除を検出した場合、blur時にアラートを表示する 。
    (例)やまだ と入力して変換キーを押下してIME未確定状態の 山田 が表示されている際にBSキーを押下して 田 を削除した場合
  11. Chrome 55.0.x のcompositionupdateイベントで取得出来る入力文字列が1文字づつになった事に対する暫定対応(2017/1/3)
  12. Opera 42.0の挙動がChrome 55.0.xと同じなので同様に対応。
    と言うか今は同じエンジン使ってるんですね。(汗)(2017/1/5)
  13. IEとMS-IMEの組み合わせで文字列を入力し変換や確定前にBSキーで削除を行ってから変換せずに確定するとcompositionendイベントのイベント引数で入力された文字列が取得できない問題に対応。(2017/1/6)
  14. FirefoxとMS-IMEの組み合わせで文字列を入力し、IME変換前の状態で入力した文字列をクリックした場合に、compositionendイベントが発生した後に、compositionstart、compositionupdate、compositionendが発生して入力が確定する問題に対応。(2017/1/7)

動作確認


jQuery 1.10.x以降(2.x系でも動作します)

Windows 7
IME:MS-IME(10.1.7601.0) / MS Office IME 2007(12.0.6670.5000)SP3 / Google 日本語入力(2.20.2750.0) / ATOK 2016 for Windows
ブラウザ:IE10 / IE11 / Firefox 50.1.0 / Chrome 54.0.x / Chrome 55.0.x / Chrome 56.0.x / Chrome 57.0.x / Chrome 58.0.x / Opera 42.0.x / Safari 5.1.7

Windows 10
IME:MS-IME
ブラウザ:IE11 / Edge

Mac OS Yosemite
ブラウザ:Safari 8.0.3
IME:標準IME / Google 日本語入力(2.20.2700.1)

macOS Sierra
ブラウザ:Safari 10.0.2 / Firefox 50.1.0 / Chrome 54.0.x / Chrome 55.0.x
IME:標準IME(ライブ入力オフ) / Google 日本語入力(2.20.2700.1)

iOS 10.2 (iPad mini4 / iPhone SE)
ブラウザ:Safari 10.0/ Firefox 5.3 / Chrome 54.0.x 以前 / Chrome 55.0.x / Opera mini 14.0

Android 4.1.2 (富士通 ArrowsX F-02E)
ブラウザ:Firefox 50.0 / Chrome 54.0.x 以前 / Chrome 55.0.x

Android 5.1(Huawei MediaPad T2 7.0 Pro LTE)
ブラウザ: Chrome 43.0.x

New ニンテンドー 3DS LL
ブラウザ: Mobile NintendoBrowser 1.8.10156.JP

上記以外の環境で動作確認が取れた場合は、御一報頂けると助かります。 IMEはAtokなども試して貰えると嬉しいです。

非対応ブラウザ

動作確認をして動作しなかった環境とブラウザを列挙しています。
Windows Chrome 55.0.x
macOS Chrome 55.0.x
Android 4.1.2 Chrome 55.0.x
Android 4.1.2 / 5.1 Opera mini 21.0.x (Prestoエンジンは未対応)
Android 4.1.2 標準ブラウザ
Android 5.1 ドルフィンブラウザ 11.6.4

※Chrome 55.0.xは個別に対応しました。55.0以降のバージョンはリリースされ次第挙動を確認します。(2017/1/3)
56.0のβを試した限りでは改善されてませんでした。
一応、Chromeの「問題を報告」とリリースノートの記事に問題を指摘しましたが反映される事はあるのかな。。。(2017/1/6)
開発版の57.0を試したら改善されていました。(嬉) (2017/1/6)


非対応IME


Mac OS X El Capitan以降の標準IMEのライブ入力

非対応

  1. 予測変換でのIME確定
    #これが出来るならmacOSのライブ入力も対応出来る訳で。。。
  2. iOSデバイスとAndroidデバイスでの文節変換
    (例)「やまに」と入力して変換候補で「山」で確定した場合、「山に」と確定せず「に」だけが未確定状態で残るため、「やま」と入力して「山」と変換して確定してから「に」と入力した場合との判別が不能のため。

動作せず


iOS Safari(Bloggerのモバイルバージョン)
 #この記事のbodyにscriptタグを書いてるせい?

参考サイト

  1. autoKana.js
  2. jquery.autoKana.jsで自動カナ入力する 
  3. JavaScriptでカタカナをひらがなに変換する(その逆も) 
  4. Kana.js  
  5. JavaScriptでUserAgentを使った判別をする 
  6. ブラウザのバージョンを調べる2 
  7. 2016年新機能! GitHubのmasterブランチをWebページとして公開する手順
  8. MITライセンスってなに?どうやって使うの?商用でも無料で使えるの?

メモ

  1. autoKana.jsの手法とI/Fをパクリしました。
  2. 全角変換はKana.jsの半角変換を参考にした際の逆仕様で独自実装しています。
    半角/全角変換は色々と見たんですが、JIS X0201の文字とJIS X0208との変換で0xFEE0を足したり引いたりしているかと思うんですが、シングルクォートとダブルクォートって違う文字になりません?(汗)
    少なくともIME入力をしてF8/F9で半角←→全角変換をした際に出て来る文字では無いと思うので円マークと共に別処理にしました。
    と言うかFEE0を足して変換されるFF02とFF07ってShift-JISだとFA57とFA56なので外字IBM拡張漢字ですよね?
  3. 処理中に片仮名に寄せて判定しているのは、ヴ ヵ ヶの対象となる平仮名が環境依存文字である事と、通常入力では ゔ は出せてもゕゖ は出せない(コード入力と辞書登録以外で出す方法があったら教えて下さい)と思ったので片仮名に寄せてます。

デモ


jQuery2.2.4を使用
フリガナ取得デモ(このページで動作しない場合はデモページで試して下さい)
漢字
ルビ
るび

ソース


https://github.com/VeryPinch/autoKana2

デモページ


jQuery.1.11.1を使用
https://verypinch.github.io/autoKana2/

ライセンス


MITライセンス

Usage


autoKana.jsと同じです。(^_^;)
$.fn.autoKana2(kanjiElement, rubyElement, option);

Sample

<script type="text/javascript" src="js/jquery-latest.min.js"></script>
<script type="text/javascript" src="js/jquery.autoKana2.js"></script>
<script type="text/javascript">
  $(function(){
    $.fn.autoKana2('#kanji', '#ruby1', { katakana : true});
    $.fn.autoKana2('#kanji', '#ruby2');
  });
</script>
<input type="text" id="kanji" style="width: 300px;" />
<input type="text" id="ruby1" style="width: 300px;" />
<input type="text" id="ruby2" style="width: 300px;" />

連絡先


もし万が一、このページに辿り着いてしまった上に連絡したいなんていう変な気持ちになったら、の話ですが。(^_^;)
一応、ソースに記載してありますが、あまりメールは見ないので、ここにコメントを付けて貰えると助かります。(^_^;)
GitHubの方は更に見ないと思います。(汗)
もっとも、ここにコメントを貰っても気が付くのに数日掛かる事もありますが。

今後の予定


そもそもが仕事でautoKana.jsを使ってフリガナ対応して欲しいと依頼されて、その通りにしたのに結果的に要求仕様を満たさなかった事が発端なので、現在の成果物を仕事先に反映した結果、何か指摘されれば反映するかも。
#客先に凄腕の打鍵者が居て、何度もバグ出しされると言う羞恥プレイ状態なので、きっとフィードバックがあるはず。(^_^;)
(仕事先では別ロジックで実装したんですが今の実装よりもアレなソースなので差し替え予定)
Chromeは55.0.x以降のバージョンも挙動が変わらない場合は、もうちょっと頑張ってみようかな、程度。
気が向いたら対応を試みようかとは思いますが、先日調べた限りでは英字に未対応とするか1文字づつ入力をチェックする事になりそうなのが面倒なので。。。
(と言うか、仕事先でやったアレな実装が1文字づつ入力をチェックする方式なので1周回ってしまうし)
と思ってたんですが、突然パッと閃いたのでChrome 55.0.x に対応しました。(^_^;)
一度、離れると駄目な思考から抜け出せる、って感じで。
macOSの標準IMEのライブ入力のフリガナはどうにもならないかと。(^_^;)
入力でいきなり漢字が表示されちゃうんで無理ゲーです。
あとグシャグシャっとキーボードを適当に打鍵した際に途中からフリガナが取得出来なくなる事がありますが、対応する気は殆どありません。
フリガナ取得の対象となる記号の設定が甘かった為に発生している問題だったので修正しました。(^_^;)

その他


とある方の信者なのでAtokは持ってません。(冗)
入れるとMacの調子が悪くなるそうなので。
上記までの文章とソース内のコメントで半角とか全角とか書いてある場合は、「いわゆる」を補完して下さい。(^_^;)
具体的には、JIS X0201の文字を半角、JIS X0208の文字を全角と呼称しています。
それとWebプログラマでは無いので色々と間違ってる箇所があると思いますので、都度指摘して頂けると助かります。

関連記事


Webでフリガナ取得
autokana.jsを改修する
CompositionEventを利用してフリガナを取得する(その1)

2016年12月29日木曜日

CompositionEventを利用してフリガナを取得する(その1)

モダンブラウザであれば、Compositionイベントを利用することが出来る事を知ったので、これを利用する事にした。
Compositionイベントは、IME入力が始まるとcompositionstartイベントが発火し、IME入力中はcompositionupdateイベントが、IMEが確定するとcompositionendイベントがそれぞれ発火すると言うもの。

autokana.jsは対象のテキストボックスにフォーカスが当たるとsetIntervalでテキストボックスの値を調べるという手法だが、モダンブラウザに限定してしまえば、compositionイベントを利用する方が良いように思った。
また値のチェックでフリガナ(と言うかルビ)を取得した文字列以外を正規表現で削除した結果をフリガナ(と言うかルビ)とする、と言う手法は利用させて頂く事にした。

さて、composition系のイベントだが、現在動作確認しているIEでは下記の問題が発生する事を確認し、それを回避するコードが必要になる。

1. Enter以外の方法でIMEを確定した場合、compositionendが発火しない

例えば「やまだ」と入力してスペースキーなどで変換候補を出した後にEnterを押下せずに「たろう」と続けて入力した場合である。

2.Windows 8.1のIEと標準のMS-IMEの組み合わせでIME入力中に入力中のテキストボックスをクリックしてもIMEが確定しない。

Windows8のIE10と標準のMS-IMEだったり、Windows 8.1のIE11とgoogle日本語入力だったりすると、この操作を行った場合はIMEが確定するが、上記の組み合わせの場合のみ以下の現象が発生する。
要は一旦は確定したのに、また未確定状態に戻ってしまうのである。

具体的には やまだたろう と入力してIME未確定状態で入力中のテキストボックスをクリックすると

compositionendが発火 ← これはOK
compositionstartが発火 ← ここからが余計な挙動
compositionupdateが発火

そしてcompositionstartイベントで取得出来るIME入力文字列として やまだたろう が取得出来る。
(通常の入力でいきなり複数文字が取得出来ることは無い)

また、choromeの54.0.xでは、compositionupdateイベントでは入力中の文字列が取得出来るのだが、最新バージョンの55.0.x にアップデートしたところ正常に動作しなくなった。。。orz

具体的な挙動は、例えば 山田太郎 と入力する場合、54.0.xでは


やm
やま
やまd
やまだ
山田


たr
たろ
たろう
太郎
とcompositionupdateで取得出来るが、55.0.xでは






山田





太郎
と取得するようになってしまった。
恐らくバグだと思うのでchromeの55.0.xには対応しない方針で。(^_^;) (2017/1/3 対応しました)
上記の挙動はOpera 42.0でも同様だったことを確認。(2017/1/5)

あと全角SP入力での挙動が各ブラウザでまちまちなので、ここでまとめておく。(2017/1/5)

ブラウザ compositionstart compositionupdate compositionend
Firefox 50.1
IE 11
×
Edge
×
Chrome 55.0
×
×
×
Opera 42.0
×
×
×
Safari 5.1.2
×
×
Safari 10.0.2
×
×
×


そもそもcomposotionupdateイベントは入力による発火なのか変換による発火なのかを判別するフラグがあっても良いと思うのだが。(^_^;)

2016年12月11日日曜日

2016/12/11 武蔵野園 雑魚

今日は実家のある東京の杉並に家族3人で行くことになった。
実家の都合で中途半端な時間だったので、その前に釣り堀に行く事にした。
最近、子供が「船乗って釣りに行きたい」とか言ってたのでクリスマスには山中湖のドーム船でワカサギ釣りをする事にしていたのだが、冬晴れでマッタリと時間を潰すには良い場所だし、食事も出来るので、大宮八幡宮の近くにある釣堀「武蔵野園」に寄り道。

この釣堀、実は自分の釣りの原点みたいなところで、幼稚園児の時から父親に連れられて何度も来た事がある。
実は2年くらい前に、やはり実家に寄る前に1回子供を連れて来た事があるのだが、全く釣りにならなかったので記事にはしなかった。
かれこれ40年前は、金魚、雑魚、鮒、鯉、ヘラ鮒と分かれていたのだが、金魚と雑魚の堀が埋め立てられて無くなり、鮒の堀も半分くらい埋められて食堂が拡張されている。
ビニール張りのオープンテラス風で、割りと客が入って繁盛していた。
釣り客もボチボチ居たのだが、殆ど誰も連れてない。(^_^;)

昔は釣りメインで食事がオマケ的な感じだったのだが、最近では食事がメインで釣りがオマケになったようだ。

うちの子供は、どうも集中力が無いのか、ジッとしてウキを見ることがまだ難しいようで、アタリがあってウキが消し込んでも見て無いので釣りにならない。(^_^;)

結局、竿は嫁さんが握って釣る事になった。
周囲を見渡すとやはり親子連れが多いが、自前の道具を持って来てヘラ仕掛けで釣りをしている人が何人か居た。
が、その方々は全く釣れていない中、いきなり嫁さんがヒット。
アッサリとヘラ鮒を釣る。
子供は大喜び。
そして、その直後に今度は自分のウキも消し込んだので合わせると30cmくらいの鯉をゲット。
その後、周囲が全く釣れていないなか、空気を読まず釣り続ける夫婦。
周囲が完デコの中、2人で6~7匹は釣って終了。

子供がもうちょっと釣りが出来るようになったら沖釣りに連れていこうかな。
いや、その前に海釣り公園か。

ヘラx2
鯉x5


2016/12/3 かみや マダコ

船宿:かみや(出船7:30沖上がり15:00)
船長:淳ちゃん船長
ポイント:京浜港〜海ほたる〜大黒沖
潮回り:中潮(満潮7:29干潮12:59満潮18:10)
天気:晴れ
タックル:タコテンヤ50号

お正月用のタコを確保するためにH氏とI氏との釣行。
だが、しかし、例によってI氏は仕事が終わらずに来れなくなった。(^_^;)
毎度毎度の事で「やっぱりね」と思った。
I氏に限った事では無いが、飲み会に必ず遅れて来る人とかって仕事の負荷のコントロールが出来てないのか、傍から見て「なんかいつも忙しそう」な人が多いような気がする。
その辺のコントロールが出来る人は「行ける」「行けない」の回答がハッキリしているし、ドタキャンなんかも突発的な事故じゃ無い限りは無いと思う。(^_^;)

さて、6:30前にかみやに到着すると第一駐車場の最後の枠に滑り込みで止めることが出来た。
車の鍵は受付で預けてと言われたので、受付した時に渡してしまったのだけど、荷物を下ろして無いじゃん。(汗)
慌てて受付に戻って鍵を受け取り、荷物を下ろしてると
「今度は、乗船券忘れるってのが有る有るパターンだから」
と言われたので、しっかりと船バッグに収納。

完全防寒装備にしようかと思ったけど予報では気温も上がるようなので、レインウェアの下はフリースのパーカーだけにしてダウンジャケット、首巻きなどは船バッグに入れて船上で様子を見て着る事にした。
受付で鍵を渡して桟橋に行くとH氏が前よりに座席を確保していてくれたが、名簿に名前を書いたのは2番目だったのに、既に場所取りされてた模様。
そして、この場所取りが、この日の明暗を分けるなるとは、この時は思いもしなかった。
舳2番を譲られたが、万が一波っけがあった場合、船酔いするので3番に入れて貰う。
これまた、この時は、残念な結果になるとは思いもよらず。。。

ここ最近のマダコの釣果は低調で、直近2日に至っては客が来なかったので出船すらして無かった。
そんな状況だったのに9人も客が居た事には驚いた。
もっとも一番最後に来た人は、本当はカワハギ船に来たのだけど間に合わずマダコ船に来たそうで、連れがカワハギ船に乗って無かったら帰ってたんじゃ無いだろうか。(汗)

京浜港の最初の方の流しで、自分の2人隣の人がいきなり良型をゲット。
そして、同じくらいのサイズを立て続けにゲット。
艫よりの人も徐々にゲットしているが、自分の左隣の人から舳の人までは全くかすりもせず。

そんな中、自分にもノリが来た!
が、焦ったせいか即バレ。
手応え的には1kg超えだったような気もするが、こう書くとH氏に
「いつも大物をバラしたって書くよねー」
と言われるのが癪だが「昔から逃した獲物はデカイ」って言うんだから仕方ない。(^_^;)

そうこう居ている内に何とか1杯目をゲットして坊主を逃れる。
が、H氏にはまだ乗りが来ない。

そして淳ちゃん船長が大移動を決意する。
移動先は海ほたる周辺。
この夏にH氏が4.8kgの大ダコを釣り上げたH氏は相性の良いポイントだ。

何回か入れ替えをした後にH氏に初ノリが来た。
自分が釣ったのよりも良型でちょっと羨ましい。
そして、暫くすると、このポイントを見切って、またもや大移動をして本牧沖から大黒沖へ。

だが、どこのポイントに行っても好調なのは艫よりの3人と自分の2人隣の人。
舳の常連さんにも1回ノリが来たけど痛恨のバラし。
自分の左隣に入ったカワハギ釣りに来た人は、ノリが無かったようだ。
そうこうしている内に無念のタイムアップ。

自分は小型を1杯追加して計2杯。
舳の人から4人でフリーダイアル0120を完成させた。(^_^;)





autokana.jsを改修する

実際問題、当初から「やまだした」問題には気がついていた。
自分は通常はFirefoxを使用しておりIEは滅多に使用しないのだが、autokana.jsのデモサイトを確認したのはIEでは無くFirefoxだった。

少しややこしいのだが、客先では持ち込みPCと客先貸与のPCの2台があり、客先貸与PCでも申請すればインターネット接続は可能なのだが、セキュリティな面から申請はしておらずブラウザもOS標準のIEのみがインストールされている状態である。
一方、持ち込みPCの方はイーモバイルを利用してインターネット接続も可能だし、ブラウザもFirefoxやChrome、Safariなど各種インストールしている。

顧客からautokana.jsを提案された際に確認したブラウザはFirefoxだった。
「jQueryプラグインだし、当然の事ながらマルチブラウザでの動作は保証されているよね」
と言う思い込みから「やまだだ」問題には気が付かなかった。
そしてautokana.jsを取得して貰い客先貸与PCで動作確認を行なった際に「やまだした」問題に気が付いて「このような問題がある」と報告したが、そのままautokana.jsの採用は決定された。(^_^;)

と言った経緯があったのに障害票を切られるのは、青天の霹靂くらいの勢いである。
とは言え、現実問題として要求仕様を全く満たして居ないのだから使い物にならないと言うのは当たり前の話なので改修に着手する。(^_^;)
「何があっても改修はしないですよ」と断っておいたハズなのだが。。。

autokana.jsの原理は、IMEがオンになっている場合、keydownイベントで得られるキーコードは常に229であり何が押されたのか解らない。
だが、IME入力中の文字列は、setTimeoutを使用するとテキストとして取得する事が出来るとの事で、これを利用して取得し、取得した文字列から平仮名以外の文字を削除する、と言うものである。

この時点では、まだ「やまだだ」問題には気が付いておらず、ひとまず住所入力の際の数字の救済を考えた。
これは許容する文字列に数字を追加しただけで解消したと記憶している。
そして英字なのだが、これは許容文字に入れてしまうと母音が確定する前の子音が、フリガナとなってしまう。
IMEの設定で英字の変換前も半角にすると設定してあれば問題無いのだが、デフォルトは全角になっているので、そんな設定をしている人は滅多に居ないだろうし設定を変えさせるのも無理だった。
そこで、IMEが平仮名モードの際に英字を入力するのはShiftキーを押下する事に目をつけて、keydown時にShiftキーが押下されている場合は英字入力と見做すようにした。
最後に記号だが、これも許容する文字列の中に入れる事で解消したように思う。(^_^;)

だが以前として「やまだした」問題があるのと、新たに指摘された最終文字に「ん」を入力する際に「nn」では無く「n」で変換した際にフリガナが「ん」では無く「n」になる問題だ。
例えば「はっしn」と入力して変換した場合、「発信」やら「発進」などに変換出来る。
WindowsアプリでIMEのAPIを叩いて取得すると「はっしん」となるため、これもバグだと指摘された。(^_^;)

正直な話『知らんがな』だ。
取りたいのは「ふりがな」だ。(汗)

そしてダメ押しで「やまだだ」問題が発覚した。
完全にお手上げである。orz
更に、この記事を書いてて気が付いたのだが、旧字の「ゐ」「ゑ」を入力すると「うぃゐ」「うぇゑ」となってしまう。
これはMacOS上でのsafariで確認。
気になったのでWindows上でIEで試してみたが「うぃ」と入力して「ゐ」に変換した場合は問題無いのだが変換候補をグルグル1周回してから「ゐ」に変換すると「うぃゐ」になるようだ。
尚、MacOS上のsafariで同じように変換候補をグルグル回していると「うぃうぃうぃうぃうぃ」と回した分だけフリガナが取れる模様。(^_^;)

こうしてみると元の発想はとても良いのだけど、テストが足りてない気がする。

取り敢えず、客先では社内システム向けと言う事が救いで、キッティングされたPCはWin8.1でIE11とブラウザは限定可能なので、ここでフルスクラッチに舵を切った。
これは「やまだだ」問題どーしよー、と思いながら淡々と泳いでいた時に決心した。

こうしてWebでフリガナを取る1日目は終わったのである。
とは言え、プールに行くので定時上がりだった訳ではあるのだが。(^_^;)

2016年12月10日土曜日

Webでフリガナ取得

何をもって「フリガナ」と言うのかだけど、現在の客先では「IMEの確定時までに入力した文字列が「フリガナ」と言う事になっている。

WindowsアプリではIMEが確定するとWM_IME_COMPOSITIONと言うウィンドウメッセージが対象のテキストボックスに送信されてくる。
テキストボックス側では、このメッセージを受信した時にIMEのAPIを使用して確定前の文字列を取得する事で「フリガナ」として扱っていた。

が、まぁ、この方式だとアルファベットやら数字や記号などを入力しても、それらが「フリガナ」として取得されることになる。
でも、それって厳密に言うと「フリガナ」じゃ無いよね。(^_^;)
例えば「A」と入力したら「フリガナ」的には「えー」または「えい」となるのが正しいと思われる。
同様に「1」と入力したら「フリガナ」的には「いち」となるべきなのだが、上記の手法でIME確定時に入力された文字を取得すると「A」と入力したら取得出来るのは「A」だし「1」と入力したら「1」となる。(^_^;)

で、このWindowsアプリで実現している機能をWeb化しても同じように利用したい、と言うのが顧客ニーズ。
そして当初は「WindowsアプリではWindows APIを使用して取得しているので無理です」と断って居たのだけど、お客さんから「autokana.jsを使用して何とかならないか?」と言われ「不具合があっても対応しなくても良いのなら」と条件付きで採用した。

が、このプラグインは、そもそも「ひらがな」のみ対応なので、顧客要求を満たすには力不足だった。
さらにIE11では「やまだだ」問題が発生した。
Firefoxやchromeでは発生しないのだが、顧客指定のIE11では「やまだ」と入力した後に変換候補で漢字と平仮名の混ぜ書きである「山だ」で変換すると「フリガナ」は「やまだだ」になってしまう。(^_^;)
その他には「やまだした」問題もあった。
これはFirefoxとChromeとIE11では挙動が異なるなのだが、「やまだ」と入力して変換候補を出した後にBSキーで変換をキャンセルして更に「だ」を削除して「した」を入力して変換を確定させるとFirefoxでは「やまだ」、 chromeやIE11では「やまだした」となる問題である。

また住所の入力で「フリガナ」を取得しようとすると英数記号が不対応のため、「5番地」と入力すると「フリガナ」は「バンチ」となってしまう。(^_^;)
同様に「D号室」と入力すると「フリガナ」は「ゴウシツ」となる。

で、まぁ、これらを障害だと言われるのはかなりキツイのだが。。。(^_^;)

こうして3日間に渡るWebでの「フリガナ」取得問題との格闘が始まったのであった。