遅ればせですが、横から失礼します。
サーバー（リモート）上に存在するデータではなく、クライアント（ローカル）上に取り込んだ（ダウンロードした）データに対しての検索（[メッセージを検索] / [Ctrl] + [Shift] + [F]）は、IMAP であれ、POP であれ、ローカルに保存されているメッセージの実体ファイルの中にあるテキスト（文字列）を検索します。
ご存知のように、Thunderbird のメッセージデータは mbox 形式のフォーマットを持っていて、Thunderbird 上のひとつのフォルダ内に存在する複数のメッセージを、システム上はひとつのファイルとして管理しています。
例えば、[受信トレイ] の実体は、プロファイル内にある Inbox という拡張子のないファイルです。このファイルは単純なテキスト形式です。
[メッセージを検索] は、この拡張子のない実体ファイルを検索対象にしていることになります。
（「特定フォルダ」とおっしゃっているのはユーザーが任意に作成したもので、この実体はプロファイル内にある "「特定フォルダ」と同名のファイル" になります。）
通常、Thunderbird は受信したメッセージが指定している条件を自動的に判別して、文字エンコーディングの処理をおこないます。
単純化していいますと、[受信トレイ] に２つのメッセージが存在するなら、実体である Inbox ファイルにはこの２つのメッセージのデータがまとめて格納されています。
メッセージ A が、
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
で定義されていたとすると、このメッセージは ISO-2022-JP の文字コードで書き込まれます。
そのあと受信したメッセージ B が、
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
で定義されたメッセージだったなら、このメッセージは UTF-8 の文字コードで書き込まれます。
（ここで、先に存在したメッセージ A のデータが、UTF-8 に変換されることはありません。）
この状態の Inbox ファイルを、文字コードを指定できるテキストエディタで開いてみるとわかりますが、ISO-2022-JP の文字コードで開くと、メッセージ A はきちんと読める状態で表示されますが、メッセージ B は文字化けした状態で表示されます。逆に、UTF-8 の 文字コードで開くと、メッセージ A は文字化けした状態で表示され、メッセージ B はきちんと読める状態で表示されます。
このことは、個々のメッセージの文字エンコーディングには様々な形式がありえても、それらは互いに干渉し合わず、個別に独立しており、それぞれに指定された条件で処理されることを意味しています。
この状態のフォルダに対して [メッセージを検索] を実行すると、通常は個々のメッセージの指定に応じた文字エンコーディングを自動的に処理して、検索文字を適切に探し出してくれます。
例えば、ISO-2022-JP で書かれたメッセージに含まれる「質問」という文字列も、UTF-8 で書かれたメッセージに含まれる「質問」という文字列も、等しく拾い上げてくれるはずです。
それが「特定フォルダのみ本文検索ができない」ということは、そのフォルダの実体であるファイルの内部構成が、Thunderbird の自動的な文字エンコーディング処理を阻害するような状態になっている疑いがあると考えられるのではないでしょうか。
いささか強引な事例ですが、実体ファイルをテキストエディタで開いたあと不用意に上書き保存すると、そのときのテキストエディタで指定されていた文字コードで一律に上書きされますから、内部にある個々のメッセージの全部または一部が、その指定と食い違った文字コードで置き換えられてしまいます。その結果、[メッセージを検索] をはじめ、正常な文字処理ができなくなってしまうことがあります。
このようなケースなら、検索機能それ自体の問題というよりは、検索対象の実体ファイルに問題が起こっていると考えたほうがいいかと思われます。
そのあたりを点検するための簡単なテストとして、その「特定フォルダ」を対象に、半角英数文字（ASCII 文字）だけで [メッセージを検索] を実行するとどうなりますか。
例えば、本文内に書かれている URL に含まれる "http" の文字列で本文を検索するといった条件で検索結果が正しく出るなら、さしあたって検索機能に本質的な問題があるとは考えにくくなります。
実際に検索できなかったキーワードが何かわかりませんが、ASCII 規格以外の文字コードで扱われるものだと想像されます。差し支えのない範囲で、実際に検索できなかったキーワードを例示していただくと、このフォーラムを見ているみなさんに tbユーザー さんのところの事情が、今よりは見えてくるのではないでしょうか。
kiki さんや WADA さんからもアドバイスがありますが、問題が起こっている「特定フォルダ」のメッセージを他のフォルダにコピーして、元の実体ファイルから切り離した状態で検索の動作をチェックして正常・非正常の条件を切り分けられれば、今よりは問題の在り処が見えてくるかもしれません。
（補足１）
「特定フォルダ」の実体ファイルに予期しない矛盾が起こるという観点から、質問文の中で疑問に感じた点を挙げてみます。
tbユーザー さんが書きました:
IMAPアカウントのサーバ上(Web上のGmail)にA・B・X・Yがあります。
フォルダ構成は「INBOX/A-B-X・Y」で、INBOX/Aは受信トレイと同階層にあります。
ローカルのThunderbird側は「受信トレイ-フォルダA-フォルダB-フォルダX・Y」です。
※以前「受信トレイ-フォルダA-フォルダB-フォルダC-フォルダX/Y」と書きましたが、階層が1つ少なかったです。申し訳ありません。
IMAP サーバー上のフォルダ構成はこういうことでしょうか？
┬ [Inbox]
│ ├ [B]
│ └ [X]
│ └ [Y]
└ [A]
Thunderbird 上のフォルダ構成はこういうことでしょうか？
┬ [受信トレイ]
├ [A]
├ [B]
└ [X/Y]
検索に関してフォルダの階層構造はとくに影響はないと思いますが、気になるのは「フォルダX/Y」という記述と「フォルダX・Y」という記述の違いです。
IMAP 上のフォルダは [X] [Y] の２つあり、Thunderbird 上ではこれを [X/Y] という１つのフォルダにまとめている、といった意味合いなのでしょうか？
同期というのは、基本的に１対１の関係で成り立つものなので、このあたりをどのような方法で運用しているかによっては、Thunderbird 上の [X/Y] という１つのフォルダ、すなわちプロファイル内にある１つの実体ファイルに何らかの問題を起こす一因になっている可能性も考えられるのでは、と思いました。
実際のところはよくわかりませんので、tbユーザー さんがおこなっておられるサーバー・クライアント間の同期関係をできるだけ正確に説明していただけると、他のユーザーさんから新たなアドバイスが寄せられるかもしれません。
（補足２）
tbユーザー さんが書きました:
グローバル検索では見つけることができました。
[グローバル検索] は、[メッセージを検索] とは仕組みが違います。
[グローバル検索] は、実体ファイルにあるメッセージデータが、global-messages-db.sqlite というデータベース形式のファイルに取り込まれたものの内部を検索していますから、検索対象が根本的に異なっています。
[メッセージを検索] は、個々の実体ファイルを対象としています。
「特定フォルダ」の実体ファイルに障害が発生したとしても、それ以前に global-messages-db.sqlite に取り込まれた内容が問題なければ、[グローバル検索] の結果は正常に出るはずです。
逆にいえば、[グローバル検索] で適正な検索結果が出るのに、[メッセージを検索] では問題があるのなら、実体ファイルに何らかの不具合が起こっている疑いが濃厚だといえるかもしれません。
とりあえず気になったことを書かせていただきました。的外れな、あるいは役に立たない話だったらすみません。
ログイン
ユーザー登録
FAQ
検索
