Naoya Murakami
visio****@gmail*****
2013年 9月 20日 (金) 20:01:39 JST
お世話になっております。村上です。 早速のご回答、わざわざ、再現のご確認、対応しやすいように ソースに手を加えてまでいただいてどうもありがとうございます！ どうしても、too long sentenceが回避できない場合は、ご提案いただいた 改行または<BR>ごとに分割してやるというのをヒントにして、 too long sentenceがでない程度の長さでまず分割して、 そこを起点に近くの「、」、「。」、「>」等の文の区切りとなるものを探して みてみようかなぁとか考えています。 C言語で、区切り文字でざくざく切るのは、大変で計算量が多そうだなぁという イメージです（あまり、詳しくないのでたんなるイメージです。） >今回の入力は改行を越えて意味が繋がっていないんですよね。 今回のケースは、そうですが、古のデータになってくると、そうじゃない ケースもあるかもしれません。まぁ、ある程度は、あきらめてたり。。 >ただ、問題があって。。。 >NormalizerAutoは改行を削除するので正規化後は改 >行があった位置 がわからなくなるのです。 あ、そうなんですね。 normalize_stringの中身みたときは、NormalizerMySQLUnicodeCIExcept〜だったかな。。 再現データは、一般化するために、NomalizerAutoにしておきましたが、 実際にMecabでトークナイズさせるのは、 NormalizerMySQLUnicodeCIExceptKanaCIKanaWithVoicedSoundMark をベースにカタカナ、かな小文字化の正規化を抑制させたものを使おうとしてます。 https://github.com/naoa/groonga-normalizer-customized >mecabコマンドのソースをながめてみたところ、mecabコマンドでは >改行毎にmecab_sparse_tostr2()相当の処理をしていました。その >ため、「too long sentence.」なエラーにはならないのだと思います。 説明不足ですいません。inputbufferは、大きくして試してました。 ・mecab -Owakati -b100000000 < mecab_too_long_sentense_CRchar.sql（改行コードではなく、\r） または、 mecab -Owakati -b100000000 < mecab_too_long_sentense_LFchar.sql（改行コードではなく、\n） では、 too long sentence. となるのに対し、 mecab -Owakati -b100000000 < mecab_too_long_sentense_CR.sql（こっちは、改行コード） または、 mecab -Owakati -b100000000 < mecab_too_long_sentense_LF.sql では、 too long sentence.はでません。 このことから、きちんとmecabが改行と解釈できるものを渡せば、too long sentence.が でないことがわかります。 それなにもかかわらず、groongaのトークナイザではでちゃうのはなぜかなーという と思ってました。 NormalizerAutoの場合は、改行をとばすということなので、それが原因だと思われます。 今、debugメッセージ埋め込んでnomalized_stringみるとたしかに、改行がありませんでした。 今、再度、NormalizerMySQLUnicodeCIExceptKanaCIKanaWithVoicedSoundMark の場合も試しました、やはり、normalized_stringをみると改行がありませんでした。 あれー、、朝はあったようにみえたんですが。。 なんにせよ、この改行コードまわりが解決のヒントになりそうです。 NormalizerAutoが改行を削除するという情報が非常にありがたかったです！ ちょっとノーマライザや改行コードの渡し方等いろいろな組み合わせで試してみようと 思います。 進展がありましたら、また、報告させていただきます。 どうもありがとうございました！ 以上、よろしくお願いします。
