WADA さん、いろいろとご指摘ありがとうございました。

Thunderbird に限った話ではありませんが、"用語や見た目につまずく" ことはよくある話なので、NFD(decomposed form) と NFC(composed form) の違いや、書き換え対象とされている mailbox://nobody@Feeds/%E3%83%96%E3%83%AD%E3%82%B0 のような記述が何を意味しているのかを、直観的に受け止めてもらえる説明や、自分で簡単に試せる方法を示せないかとシロウトなりに考えたのですが、調子に乗って見当違いなことを書いていたら申し訳なかったです。

あとは、Mac ユーザーと専門的な対処のできる方々にお任せいたします。

_________________
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0

現象自体は大体はわかってきたんですが、原因となるとよくわからず、最新のパッチで変える場所を見て、msgFolder.URIを直接使っているコードを見て、ようやく、msgFolder.URIの食い違いに起因している、ということがわかったばかりです。
デベロッパーがフィード関係の人だから、メールフォルダーのコードのcreateLocalSubfolder()のバグだなんて口が裂けても言えない(^^)
で、その、つい最近わかった原因の報告をかねて、UnicodeのNFC/NFDのデータに固執するのはもう止めましょう、と言ったまで。

meeyar さんが提示した手順を見てわかるとおり、ユーザーに対するガイドでは、ユニコードのデータやNFC/NFDといったものについては、極力避けるようにしています。
基本は、(a) ファイル名を英数字(or濁音・半濁音がないもの)に変えさせる、(b) ファイル名を英数字のものに変えさせて、URIの%エンコードもヘキサデシマル文字列もでないようにして、feeds.rdf内のmailbox URLを書き換えさせる、だけです。
mailbox://.../Feeds/SlashDot のように書き換えさせるだけだから、回復手順でユニコードのデータに言及する必要はなく、現象・問題の簡単な説明も書いた時に、多少言及する程度。

Mac OS Xユーザーでないと出来ないのは、NFD(Decomposed Form)のデータが入った実際のmailbox URIのデータの提示、再現テストや追加のテスト、パッチのテスト、です。
パッチのテストはomni.jaの直接の変更がいるから、meeyar さんにお願いするしかないんだけど、データの提示とか追加テストなども、feeds.rdfの中身なんて見る気にもならない方々ばかりのようで、こっちも、meeyar さんにおんぶに抱っこ。
ユーザーに対するガイドの作成を、meeyar さんにだけ押し付けることの無いように、お願いします。

このトピックを見ている全てのMac OS Xユーザーの方へのお願い。

以下のデータを提示していただけますか？
1. 新規にフィードアカウントを作る(メッセージの保存先=.../Mail/Feed-N)
2. そこで、問題の起こるフィードを新規に購読
　　(アップル、スラド、Mozillazineブログ、がわかっています。スラドが文字列が短くて楽)
　 この時点で、feeds.rdf内には、NFC(Composed Form)のデータでmailbox URIが書かれます。
3. このフィードアカウントに対してメッセージフィルターを定義し、
　　コピー先/移動先を、新規に作ったフィードのフォルダーにする。
　　ルール自体は、「無効」にしておく。
4. .../Mail/Feed-N/msgFilterRules.datをテキストエディターで見る。

msgFilterRules.datでは、どちらの形式のmailbox URIが書かれますか？

5. 新規に作ったフィードアカウントを削除し、.../Mail/Feed-Nというディレクトリーを消す。

最新のパッチで行おうとしていることは、(2)の時点のmsgFolder.URIを使わず、(3)の時点のmsgFolder.URIを使って、feeds.rdfにmailbox URIを書く、というものです。

[追記]
で、この時気になるのが、nsIMsgFolderのインスタンスの実体は一つのC++オブジェクトだけで、フィードがフォルダーを作ってオープンしている状態でオブジェクトを参照していると、他のパスからアクセスしても、フィードがフォルダーをクローズするまでは、結局msgFolder.URIの値は更新されないのではないか、ということです。

最新のパッチでは、購読した時にフォルダーを作るけれども、オープンしている・参照している状態にはしないで、作ったはずのフォルダーを探しに行くので、こういったことは無いはずですが、ちょっと気になるので、Mac OS X ユーザーの方、確認をお願いします。
[追記おわり]

3の時点での新規につくったフィードのフォルダが書かれている。

初期状態
version="9"
logging="no"

ルールを作った後「abc」という名のフォルダを作成
version="9"
logging="no"
name="件名 に次を含む: "
enabled="no"
type="17"
action="Move to folder"
actionValue="mailbox://nobody@Feeds-2/abc"
condition="AND (subject,contains,)"

作業はこれでいいのかな。

久しぶりに見たら嫌味連発ですね。
俺はソースコードを見てデバッグしているわけではないから「〜のようだ」なんだよ。
コードをデバッグしてないのに真実がわかるか。
そんな程度で物事を言い切って断言するほど無礼ではないつもりなんだがな。
真意が伝わらなくて残念だ。

_________________
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Firefox/42.0

???
良くない。それじゃ、意味なし。
feeds.rdfの中の、「mailbox://nobody@Feeds-2/ほげほげ」と、
msgFilterRules.datの中の、actionValue=「"mailbox://nobody@Feeds-2/ごにょごにょ"」について、
「ほげほげ」は、NFC(compose form)ということは既にわかっているから、
「ほげほげ」=「ごにょごにょ」なのか、「ごにょごにょ」がNFD(decomposed form)になっているのか、を確認して欲しい、ということです。

先に「スラド」というフォルダーを作り、再起動してからスラドのフィードを購読した場合には、
「ほげほげ」=「ごにょごにょ」であって、「ほげほげ」=「ごにょごにょ」=NFD(decomposed form)、ということは、
meeyar さんの的確なデータの提示によって、既に判明しています。


誰も、コードを見ろ、なんて言ってやしません。
せめて、他の人が苦労して問題のありかを突き止めようとして、その結果書いたコメントなんだから、最低限、それをちゃんと読んで、
少なくとも三人が、feeds.rdf内のデータが関係している、と書いているんだし、
SimpleTextとかのテキストエディター程度を、別に全然使えないわけじゃないんだし、
実際のデータくらいは確認してよ～、です。

こっちこそ、Mac OS X上のどんなデータを提示して欲しいのかが全然伝わっていないようで、非常に残念です。

指示した手順通りしたつもりなんだけどなあ。
どう作業して、どの時点でのどういう情報が必要かちょっとわかりにくいので、
作業の手順の違いを教えてくないかな？
その時点のファイルもまだ残っているし、わかればもう一度やりますよ。

＋
何が残念だよ。自分の書いた事は省みてはくれないのか？何でも人のせいにしやがってw
一般人はこのような事に費やす時間がそれほど多くないんだよ。何でもかんでもそちらに合わせられないんだよ。
WADAさんも少しはわかっておくれ。本当に感謝してますよ。

_________________
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Firefox/42.0

なんか殺伐としていて微妙に「書いていーのか」な雰囲気ですが、一応調べました。

Bug 121904のattachment 8683313適用済み＋新規プロファイルです。
msgFilterRules.datの中身。
Mailbox URIはNFD(Decomposed Form)の記載ですね。

また、この時のfeeds.rdfは

なので、NFC(composed form)で書かれています。

具体的な作業方法は次便に書きますね。
（追記）下書きのプレビュー時点で既に返信があったのを発見。
なるべく具体的に書いておきますので、わからないところがあれば聞いてください。

_________________
Thunderbirdの基本を書いています(ずっと発展途上)　とりかごとなり。
基本の操作(画像あり)：バージョン確認　/ セーフモード / 新規プロファイル作成

【作業方法の詳細】
WADAさんからのお願い
viewtopic.php?f=3&t=15721&start=75#p56458
にある作業方法が今ひとつわからない、という方のために、一応自分がやったことを書いておきます。

当方はBug 121904のpatch適用後に作業していますが、patchの当て方は
viewtopic.php?f=3&t=15721&start=45#p56406
にとりあえず書きました。
（果たしてこれで合ってるのか、という不安はありますが）
（追記）
上記リンク先は、以前のpatchなので

引用:

中に含まれるFeedUtils.jsm、feed-subscriptions.js、feed-subscriptions.xulについてpatchを適用

こんなこと書いていますが、今回のpatchは適用されるファイルが一部異なります。念のため。

patchコマンドの詳細は長くなるので、ここではそれ以降の

に絞って書いておきます。
patch周りはとりあえず置いておいて、上記引用部分のみ行っていただけると助かります。

1. Thunderbirdを起動
2. メニューのアカウント設定orフィード画面の新規アカウント作成のうち、「フィード」より、新しくフィードアカウントを作ります。
   問題となるフィードを新規に購読します。
   このあたりの解説は
   viewtopic.php?t=15755&p=56424#p56424
   の1.2.3.あたりも参考にしてください。
   （4.以降を行う必要はありません）
3. 予めプロファイルフォルダを開いておく（メニューのヘルプ→トラブルシューティング情報から）
   ここに、Mail/FeedsとかMail/Feeds-N(Nは数字）フォルダがあるはずです。
   更新日時が直近のものが、新しく作成したフィードのアカウントですから、この中をwatchしておいてください。
   WADAさんの文章では「(メッセージの保存先=.../Mail/Feed-N)」と書かれているところですね。
   
   フィードを新しく購読した時点で、このフォルダの中に
   feeditems.rdf
   feeds.rdf
   msgFilterRules.dat
   Trash
   Trash.msf
   （フィードの名前）
   （フィードの名前）.msf
   のファイルがあるはずです。
   あとでこの中身を確認するので、フォルダを開いたままにしておきます。
4. この後に、メッセージフィルタを新規に作成するのですが、
   
   引用:
   コピー先/移動先を、新規に作ったフィードのフォルダーにする。
   
   この意味についてです。
   「新規に作ったフィードのフォルダ」は、先ほど新規で購読したフィードのフォルダです。当方はスラドのRSSで試したので、添付画像の赤枠部分のフォルダに相当します。
   （再起動したらただのフォルダに・・・）
   添付ファイル:
   コメント: フィードのフォルダを移動/コピー先に指定します
   
   target.png [ 11.88 KiB | 表示数: 8906 回 ]
   

メッセージフィルタのコピー先/移動先を、上記のようにしておくと、msgFilterRules.datには問題となるフィードのフォルダ名が

のように書かれます。
この（エスケープされた文字列）が、NFD(Decomposed Form)になるのかNFC(composed form)になるのか教えて下さい、というのがWADAさんのリクエストと思うので、一連の作業を行った後のmsgFilterRules.datの中身を提示してください、と意味と判断しました。

・・・でいいんですよね？
違っていたら遠慮なくつっこんでください。

_________________
Thunderbirdの基本を書いています(ずっと発展途上)　とりかごとなり。
基本の操作(画像あり)：バージョン確認　/ セーフモード / 新規プロファイル作成

ルールとしてはおかしな事ですが、移動元は新しく購読した「Ａ」だけれど、移動先も同じ「Ａ」でルールを作って
提示はmsgFilterRules.datの中身ということで良いのでしょうか？
他の情報も必要でしたら言ってください。

_________________
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Firefox/42.0

はい、その理解で良いかと思います。
WADAさんより「ルール自体は、「無効」にしておく。」とある通り、フィルターを用いることが目的ではないのです。
フィルターの設定を行った時にMailbox URIの文字列がどうなっているか、というのが知りたいことなので、「AのRSSについて、フィルターによる移動先もAにする」という書き方でも良いと思います。自分もそのようにしました。

前便の添付画像でのフォルダ名は、RSSのタイトルがそのまま自動的に入るはずですから、フィルターの設定ファイル（msgFilterRules.dat）にも問題となっている部分の文字列が反映されるはず、と解釈しています。

_________________
Thunderbirdの基本を書いています(ずっと発展途上)　とりかごとなり。
基本の操作(画像あり)：バージョン確認　/ セーフモード / 新規プロファイル作成

私の環境はpatchは導入していませんがいいのでしょうか

長い方で申し訳ないんですが、「アップル - ホットニュース」で行った結果です
msgFilterRules.dat
actionValue="mailbox://nobody@Feeds-3/%E3%82%A2%E3%83%83%E3%83%97%E3%83%AB%20-%20%E3%83%9B%E3%83%83%E3%83%88%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9"

比較用に
feeds.rdf
<fz:destFolder RDF:resource="mailbox://nobody@Feeds-3/%E3%82%A2%E3%83%83%E3%83%97%E3%83%AB%20-%20%E3%83%9B%E3%83%83%E3%83%88%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9"/>

ということで良いのでしょうか。違っても文句言わないでくださいね

_________________
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Firefox/42.0

やっと、バグを開いてくれたKTBN さんが、feeds.rdfの中身を見てくれた...(^^)
パッチがあたっていない、素のThunderbrd 38での結果が重要。
で、長くなって見づらいから、「スラド」って言ったのにぃ...


「%20-%20%」の前が「アップル」に対応するから、そこだけを抜き出して並べると、
feeds.rdfのfz:feedの下のfz:destFolder RDF:resourcemsgFilterRules.datのactionValue
%E3%82%A2 = 「ア」のutf-8の%エスケープ
%E3%83%83 = 「ッ」のutf-8の%エスケープ
%E3%83%97 = 「プ」のNFC(composed form)のutf-8の%エスケープ
%E3%83%AB = 「ル」のutf-8の%エスケープ
再起動すると、HFS+に書かれているNFD(decomposed form)のファイル名を元にセットされたmsgFolder.URIで検索するので、NFC(composed form)で書かれているfeeds.rdfの中のエントリーを見つけられない、というのが、このトピックの問題なんですが、
msgFolder=this.server.rootMsgFolder.QueryInterface(Ci.nsIMsgLocalMailFolder).createLocalSubfolder(this.folderName);
のようにして、作ったフィードのフォルダーをオープンした状態にするので、
メッセージフィルターを作る時にも、NFC(composed form)のmsgFolder.URIが使われて、
そのために、再起動するとメッセージフィルターが動かなくなる、ということも起こりそうですね。
通常のメールフォルダーのメッセージフィルターの場合にどうなるかは、フィードのフォルダーのデータだけでは、不明ですけど。
フィードのfeeds.rdfのfz:feedのエントリーの検索は、mailbox URIの形式で表した「文字列」である「検索のためのキー」での検索ですが、
メッセージフィルターなどの「メッセージフォルダー」のアクセスでは、「mailbox URI」という、「フォルダーの実体」をある文字列で表現した「メッセージフォルダーへのポインター」を使っての「メッセージフォルダー」のアクセス、という違いがあります。

パッチをあてたmeeyar さんのデータだと、この「再起動後にメッセージフィルターでも問題が起こるはず」ということが見えなくなってしまうので、パッチがあたっていない、現在の素のThunderbrd 38での結果が重要なんです。
meeyar さんのパッチをあてた後のデータを見ると、
パッチをあてた後は、作ったフィードのフォルダーをオープンした状態にはしないので、
メッセージフィルターにおいて、msgFilterRules.datにはNFD(decomposed form)のmailbox URIが書かれるから、
「msgFilterRules.datにNFC(composed form)のmailbox URIが書かれているために、再起動後には、NFD(decomposed form)のmailbox URIでアクセスするのでメッセージフィルターでも再起動後に問題が起こるはず」という方は解消するけれど、
新規に購読した時にフォルダーを作ると、パッチをあてた後でもfeeds.rdfにはNFC(composed form)の方が書かれて、再起動後にfz:feedのエントリーが見つからない、という問題の方は、まだ解決しないようですが。

またまた的確なデータの提供、ありがとうございます、

パッチによって、this.folder=...createLocalSubfolder("スラド") ⇒ ...createLocalSubfolder("スラド") に変えてあるので、createLocalSubfolderで作られた、Tbのグローバルなオブジェクト内の”スラド"というフォルダーのnsIMsgFolderオブジェクトへの参照は行われなくて、
それで、メッセージフィルターがフォルダーを見に行った時には、ある程度時間が経っているので、参照されていないそのオブジェクトは消えていて、nsIMsgFolder.URIは、ファイルシステムのファイル名からセットされていた、という感じですね。
しかし、フィードがfeeds.rdfにセットするために、createLocalSubfolder("スラド") の直後にthis.folder = this.server.rootMsgFolder.getChildNamed("スラド");を行った時点では、nsIMsgFolder.URIがNFC(composed form)のnsIMsgFolderオブジェクトから作られたオブジェクトが渡された、という感じがします。

バグにも書いたんですが、
this.server.rootMsgFolder.QueryInterface(Ci.nsIMsgLocalMailFolder).createLocalSubfolder(this.folderName);
⇒ this.server.rootMsgFolder.createSubfolder(this.folderName);
に書き換えると、どうなりますか？
createLocalSubfolderはnsIMsgFolderオブジェクトを返すので、ファイルを作った後にグローバルオブジェクト内にオブジェクトを作りますが、
createSubfolderはnsIMsgFolderオブジェクトを返さないので、ファイルを作った後にグローバルオブジェクト内にオブジェクトを作らない、といった違いがあるはずです。

杞憂かもしれないですが。

フォルダーペインでの普通のメッセージフォルダーの作成などでも、NewFolder=ParentFolder.createLocalSubfolder(NFCのフォルダー名);が使われているので、
Mac OS X上のTb 38で、"スラド"のようなメッセージフォルダーを作ったすぐ後に、再起動を挟まず、"スラド"をメッセージフィルターのコピー先・移動先のフォルダーに指定したり、検索フォルダーの検索対象のフォルダーに指定したりすると、
msgFilterRules.datやvirtualFolders.datの中にNFC(composed form)のmaibox URIが書かれ、
再起動すると、nsImsgFolderでは、HFS+上のNFD(decomposed form)のファイル名から作られたnsImsgFolder.URIがセットされているので、フォルダーが見つからず、
フィルタールールが無効化されたり、検索フォルダーがなくなる可能性があります(最後の検索対象フォルダーが無くなると、検索フォルダーが消される)。
Mac OS Xで、フォルダー名にウムラウトなどがある文字が使われているときのバグ報告の一部は、こういった問題かもしれません。

KTBNさん、meeyarさん、余裕がある時に、確認しておいてください。

試行しました。
すぐ再起動してもフィルターに引っかかるメールはないので、メッセージフィルタウィンドウ内で「今すぐ実行」を押した結果です。

画像がペーストされてないかもしれないので、メッセージボックスの内容を
警告：「スラドフォルダが見つからなかったので、このフォルダに関連付けられたフィルタは無効になります。フォルダが存在しており、フィルタが有効な対象フォルダを指している事を確認してください。」

予想どおりだと思います。

_________________
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Firefox/42.0