もう一つ追加。

最初から自力でそこまで調べろ、なんて、誰も言ってやしない。

問題に遭遇したら、ユーザーにとってはミステリーで、手の出しようがない。
だって、フィードを削除してやり直そうと思っても、「既にある」と言うだけで、何も教えてはくれないんだから。
たとえ、アカウントを作ってそこで購読するなりしてなんとか一時的に購読しなおすことができたとしても、再起動が入れば元の木阿弥で、無間地獄。

困って、ググルなりして、なんとか辿り着いた場所に、
「SimpleTextでfeeds.rdfを覗いてみましょう。dc:title=スラドと書いてあるエントリーはどうなっていますか？」
と書いてありさえすれば、この問題がどうかが一発でわかるんだから、
そういったことを一切調べさせずに、「～のようだ」をベースにした、闇雲に何かを消して作って購読、というようなことを書き連ねてあったって、ユーザーにとっては、余計なこと・無駄なことをやらされるだけ。

そういったガイドを書こうとしている人が、feeds.rdsの中身をチェックしてみる、なんてことを一切せずにガイドを書いたとしたら、ユーザーにとっては、いい迷惑。

SimpleTextとは異なるエディターかもしれないし、テキストエディターなんて見たことも聞いたことも無い、というMacユーザーかもしれないけれど、わからなきゃ自分でググルなりしてなんとかテキストエディターでファイルの中身をみてみる、ことくらいは、できるはずだと思います。

ちょっと今Mac環境が手元にないので、patch周りは後回しにして、気が付いたことだけ書いておきますね。

本件について、思っていたことは大体WADAさんから仰っていただいてるのですが、

と仰せの方にとっては、恐らくインスタントな、「このボタンを押しさえすれば全て一発解決」くらいのものがなければ、読む「気」にすらならないのだろうと思います。
本Bugについては、既にpatchもあがっているので、将来的なアップデートでの対応を期待できると思いますが、そうなる前に「自力で」どうにかしようと思った場合、現状はプロファイルフォルダのfeeds.rdfを確認したり、新規登録の場合に気を付けていただくしか（WADAさんや偶然的通行人さんのレスを参照)ありません。

ですので、当面の回避方法としては、
1)新規登録で対応（WADAさん、偶然的通行人さんの解説）
viewtopic.php?t=15721&p=56394#p56394
viewtopic.php?t=15721&p=56402#p56402
2)今までのフィードを復旧(拙文)
viewtopic.php?t=15721&p=56399#p56399
で行っていただくのが妥当かと思います。

これすらハードルが高い、ファイル操作が厳しいという場合は、修正後のアップデートがかかるまで待つしかない、という印象です。

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

なんですよねぇ...

細かなことは一切なしに、以下の手順だけを示しておくのがいいのかも。
「スラド」のフィードを例として。
(1) 新規にフィードアカウントを作成し(メッセージの保存先は.../Feeds-X)、同じファイル名の「スラド」というファイルを作って、Tbを終了・再起動し、「スラド」のフィードを購読して、Tbを終了。
(2) 既存のアカウント(メッセージの保存先は.../Feesd)の.../Feeds/feeds.rdfをテキストエディターで編集し、
dc:title=スラドのエントリーのmailbox URLの文字列を、
.../Feeds-X/feeds.rdf の中の、dc:title=スラドのエントリーのmailbox URLの文字列で置き換え、
mailbox://.../Feed-X/... を mailbox://.../Feed/...、にして、Tbを再起動する。
(3) 新規に作ったフィードアカウントを消す。

これなら、余計な購読の作業は、feeds.rdfに書きこむべきNFD(decomposed form)の文字列を入手するための、新規フィードアカウントにおける一回だけで、実質的な作業は、テキストエディターによるfeeds.rdfという単なるテキストファイルの編集だけだから、一切の紛れはなく、手順の記述もシンプルですむ。

テキストエディターによる単なるテキストファイルの編集すら嫌だったら、どうぞお好きなように。

遅くなりましたがpatch関連について。

仰せの通りの修正（新規購読時についての修正）と思いましたので、フィードのアカウントを新規に作成して、改めてフィードの購読作業を行っています。
「散々使い倒したプロファイルだからどこかおかしくなっているかも」とも思い、新規プロファイルでも確認しましたが、やはり従来と同様の挙動に見えました。

新規プロファイルでのfeeds.rdfでは

となっており、従来と変わらない状態です。
Mailbox URLをNFD(decomposed form)の状態

にすると改善します。

でもWindows環境ですと、あのpatchの内容で修正済みの状態になるということですよね・・・
まだ何か見落としがあるのかもしれません。スムーズに進まず申し訳ないです。

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

これは、パッチの意図は、フィードのタイトルからファイルを作った時はNFC(composed form)で、今と変らず、だから、ＯＫ．
で、再起動後は、オープンした後のファイル名(Mac OS XではNFD=decomposed form)からNFC(composed form)でmailbox URLを作ってfeeds.rdfのfz:feedを検索。


ということは、再起動後に、
意図している、オープンしたファイル名(Mac OS XではNFD=decomposed form)からNFC(composed form)でmailbox URLを作ってfeeds.rdfのfz:feedを検索、ではなく、
現在と同様に、オープンしたファイル名(Mac OS XではNFD=decomposed form)からmailbox URLを作ってfeeds.rdfのfz:feedを検索している、ということを示していると思います。


Linux/Winだと、OSから返されるファイル名はNFC(composed form)だから、あのパッチのコンセプトだと、Linux/Winだと今と何も変らない、というはずなんだが...

彼も、Macは使えないから、あるAPIを呼んだらどうなるか良くわからん、と言いながら、パッチを書いてくれています(^^;
あのパッチの後、Linux/Winでちょっとおかしくなるとすると、normalize()といったAPIの仕様がOSにょって異なるのかな？

念のために、パッチをあてた後の、マックでの、「スラド」というファイルを作ってTbを終了・再起動して「スラド」を購読、の時の、feeds.rdf内のmailbox URIを確認しておくといいかも。
購読した時にfeeds.rdf内にmailbox URIを書くロジックと、フィードのフォルダーからmailbox URIをキーにしてfeeds.rdf内のfz:feedを検索のロジックは、別です。

_________________
Mozilla/5.0 (Windows NT 5.1; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33.1

これを見てみました。
スラド購読直後の状態だと、

でNFD(decomposed form)の状態です。
購読後再起動しても同じで、Feedは更新可能状態のままとなります。

を裏付ける状況に思います。

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

(オフトピック)
meeyarさんの新規トピックの、新規に購読する方法について。
お見事。
フィードの新規アカウントで、購読は普通にさせておいて、再起動に行ってしまわないうちに、まずタイトルを問題の起こらないものに変えさせておき、次にフォルダー名をそれと同じものに変えさせる。
これなら、以降の再起動で起こるバグの問題を事前に完璧に阻止できて、かつ、全てが大体はやったことがあろう作業で無理無く行えるものであろうし、タイトルとフォルダー名をセットで変えるのは、違和感なく行えるはずだし、それ以上にわかりやすいし間違いも少ないし、細かいことの説明は一切不要。
せいぜい、濁音・半濁音があると問題がおこる、という程度で十分。

「～のようだ」をベースにしたような、簡単に無駄なことをさせかねないようなものに比べて、簡潔で的確であって、良く理解していてかつ非常に親切な人が書くと、こういうものができるんですね。
私だと、SimpleTextでエディットするだけの話じゃん、としか書かない(^^)
、

ありがとうございます。
このスレが随分と長くなったので、とりあえずの回避策のみ新規で分けました。
viewtopic.php?t=15755&p=56423#p56423
以後は「フィード使えなくなってどうしよう」の方はあちらへ誘導していただき、こちらではBugそのものの話に絞って良いかと思います。

基本的には、以前偶然的通行人さんが示された、
viewtopic.php?f=3&t=15721&start=45#p56402
の解説に画像を添付したもの、という中身になっています。
なので、当方のオリジナルではないですね(^_^;

あの方法は、確認した限り新規登録の時にしかできないものなので（再起動後はfeeds.rdfの編集が必要）、そこを明確化するために書いた、というのもあります。
再起動後にできなくなる理由は、偶然的通行人さんの解説でいうところの（B)の情報がなくなってしまうからですね。
タイトル、記事の保存先いずれも編集不可能になります。

２）については、どうしてもfeeds.rdfを編集する必要が出てくるので、１）よりハードルあがってしまいます。
うまい書き方がないか模索中です。

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

(オフトピック)


問題の解析に手間取ったから、いつの間にか、もう、5ページになっちゃいましたもんね。
でも、そういった気遣いが大事。
トピックのコメントなんて禄に読まずに、何かというと「一般ユーザー」を盾に、自分では何かをしようとせず、こういったボランティアの人がフォローしている場で、自分はお客様なんだからと、要求だけをする...
これは、bugzilla.mozilla.orgでも同じです。
無料の、お客様相談センター・お客様サポートセンター、と思っている人が、結構多いんですよね。


でも、バラバラにあったものをまとめ上げて、それを、わかりやすくて役に立つものに仕上げてユーザーに提示してあげる、って、そうは簡単にできないですよ。
面倒だから、つい、嘘じゃなくて正しいことが書いてあるんだから、それをちゃんと読んで理解してね、になっちゃいます(^^)


意味はわからないにせよ、スラドの例を提示していいるんだから、置き換えるべき文字列(NFD=decomposed form)も、具体例を提示しておいたほうがいいと思います。
NFD/NFCについてはわからなくても、「(3バイトのutf-8バイナリーのエスケープ形式)*3文字分」を 「(3バイトのutf-8バイナリーのエスケープ形式)*4文字分」で置き換える、ということが、たとえ極く一部の人だけであっても、文字列の長さの違いで伝えられる方がいいんじゃないかな。

[追記]
結局は、の部分を、で置き換えるだけでおしまい、という話ですよね。
NFD(decomposed form)の文字列を得るのに一苦労するから、フォルダ名を「SlashDot」にリネームしてしまえば、何も考えずに「mailbox://nobody@Feeds/SlashDot」で置き換えればいいので楽、というだけで。
[追記おわり]
[追記その２]
「SlashDot」に変えた後は問題なく購読できているから、タイトルを「スラド」に戻し、フォルダー名を「スラド」に変えれば、元に戻せて、バグの問題も起こらない。
これがお奨め手順かな？
[追記その２おわり]

[バグの経過報告]
パッチの新バージョンがでていました。
今度は、フォルダーを作った時点で(msgFolder.URIにNFCが入るようです)、Folder Re-discoveryと同等の処理を行い、msgFolder.URIにNFDがちゃんと入るようにしてから、フィードの登録を行う(fz:feedにmailbox URLを書く)。

[追記]
パッチを見ると、"rename"(同じParentFolderの下のみ)、"move"/"copy"(別のParentFolderがあり得る)、においても、Folder Re-discoveryと同等の処理を入れていました。
これらにおいても、新規にmsgFolderを作るパスを通るようです。
となると、一旦「SlashDot」にして問題が無くなっても、「スラド」にリネームしてしまうと、また問題が起こる可能性があります。
そうなると、また、feeds.rdf内で、「スラド」のNFDのmailbox URLに書き換えるか、「SlashDot」のmailbox URLに書き換えるか、どちらかが要ります。
「禁止事項」として書いておけるように、一旦「SlashDot」にして問題を回避した後に「スラド」にリネームした場合のTb 38の挙動もチェックしておいた方がいいでしょう。
[追記おわり]
[追記その２]
追記を書いたら、次のコメントで既にこのケースをチェックしてくれていた(^^)
やっぱり、「スラド」にリネームしてはいけなかった。
[追記その２おわり]

（オフトピック→対処方法のこと）
追記を見る前に追加の記事を書いてしまいました・・・

「タイトル」というのが、アカウント設定の「フィード購読の管理」で表示されるフィード名（faviconが表示されている部分）のことであれば、ここは2-2)の方法で行った場合であっても、「スラド」のままです。
そして、フォルダペイン上でフォルダ名を「スラド」にしてしまうと、feeds.rdfとの整合性が崩れて、更新できない状態になってしまいます。
フォルダペイン上で全角文字を使う場合は、どうあってもfeeds.rdf内にNFD(decomposed form)でもって書き換える必要があるように見えます。
（デコード後の文字列では無効のため）

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

いつもながらの、的確ですばやい確認、ありがとうございます。

一番簡単で、単純明快なバグの再現手順が判明。

Mac OS X上で、なんでもいいから、あるフィードで、フォルダー名を、濁音・半濁音がある日本語文字、ウムラウトとかアセントとかがある文字、タミル語の文字などの、NFD(decomposed form) != NFC(composed form) の文字を含む名前に変えて、Thunderbirdを再起動する。

Mac OS X使いの上司がちょっと席をはずしている間に、大事なフィードのフォルダー名の後ろの方に「グ」とかを入れ込んでリネームしてしまう。
次の日に上司がThunderbirdを再起動すると...(^^)

meeyar さん、動作検証や新規トピック建て、お疲れさまです。
WADA さん、Bugzilla の対応、お疲れさまです。


とのことなので、新規トピックで話が錯綜しないよう、こちらに書かせていただきます。
ぼく自身、"Unicode の正規化" の内容を専門的には知らないのですが、何が起こっているのかの概略を理解するのに役立つかもしれないことを、エンドユーザーの視点でいくつか......。明らかな誤りはもちろん、あまりに大雑把過ぎる部分にはツッコミを入れてください。

（前提）
通常、ひとつの文字は、ひとつの文字コードが対応しています。
ある文字列は、それらに対応するコード列と同等で、コンピュータ内部ではコードで解釈・処理されます。

（Unicode の仕様）
文字コードの規格である Unicode は、多様な言語の膨大な文字（文字集合、符号化方式など）を、Unicode というひとつの規格の中で一括して扱います。
従来の文字コードと異なる特徴点として、文字の "合成" と "分解" という考え方があります。
日本語で例えれば、ひらがな／カタカナのうち、濁音や半濁音の文字は、[元の文字] + [濁点または半濁点] の合成でその文字を表現する、または分解して組み立て直す、ということが可能なことです。従来からある文字コードとの互換性から、[濁点または半濁点が付いた文字] もあります。

（本件で起こっていること）
例として挙げられている「スラド」という文字列でいえば、最後の「ド」が、[ド] 一文字で表現されるか、[ト]+[゙ ] の合成・結合で表現されるかの違いから、受信したフィードのコンテンツを保存するファイル名と、feeds.rdf 内に定義されたそのパス名（URL）に食い違いが生じ、データの正常な読み書きが阻害されている、という話になります。

（事例）
例えば、「ブログ」という文字列は、人間が見ると３文字で、それぞれの文字に Unicode のコードが対応します。文字とコードの対比を区切って表現すると、次のようになろうかと思います。

NFC(composed form)
ブログ
[ブ][ロ][グ]
[30D6][30ED][30B0]
%E3%83%96%E3%83%AD%E3%82%B0

NFD(decomposed form)
ブログ
[[フ][゙]][ロ][[ク][゙]]
[[30D5]+[3099]][30ED][[30AF]+[3099]]
%E3%83%95%E3%82%99%E3%83%AD%E3%82%AF%E3%82%99

後者は、表現される文字は３つなのに、文字コードは５つあります。

最後の % 付の文字列は、その上の文字／コードが、パーセントエンコーディング (URL エスケープ) で表現されたものです。これは URL の記述には使えない規格外の文字を表現するためのもので、本件では feeds.rdf 内に
mailbox://nobody@Feeds/%E3%83%96%E3%83%AD%E3%82%B0
のような形で記述されています。

同様に「スラド」の場合は次のように表現できます。

[ス][ラ][ド]
[30B9][30E9][30C9]
%E3%82%B9%E3%83%A9%E3%83%89

[ス][ラ][[ト][゙]]
[30B9][30E9][[30C8]+[3099]]
%E3%82%B9%E3%83%A9%E3%83%88%E3%82%99

（簡単な方法で文字の表示を確かめる＝１）
feeds.rdf にある
mailbox://nobody@Feeds/%E3%82%B9%E3%83%A9%E3%83%89
または
mailbox://nobody@Feeds/%E3%82%B9%E3%83% ... 8%E3%82%99
の URL を、Firefox のロケーションバーに入力して実行してみてください。
「アドレスのプロトコルが不明です」とエラーが出ますが、ロケーションバーの表示が変化するのがわかると思います。
URL エスケープが元に戻され、どちらも
mailbox://nobody@Feeds/スラド
となり、見た目は違いがわからないはずです。

今度は、ロケーションバーから「スラド」の３文字だけを選択・コピーし、適当なテキストエディタにペーストすると、「スラド」の文字のまま表示されます。
そのテキストエディタが Unicode に十分対応していれば、どちらも「スラド」と表示されると思いますが、対応が不十分なテキストエディタ（あるいは選択しているフォントによって）では、最後が [ト]+[゙] か、[ト]+[?] のように濁点部分が文字化けしたように表示されると思います。

（簡単な方法で文字の表示を確かめる＝２）
～ \Mail\Feeds 内にある「スラド」という拡張子のないファイル（フィード記事を保存した実体ファイル）を、Firefox にドロップすると、ロケーションバーに URL が表示されます。次のようにです。
file:///C:/Users/<username>/AppData/Roaming/Thunderbird/Profiles/xxxxxxxx.default/Mail/Feeds/%E3%82%B9%E3%83%A9%E3%83%89

最後の URL エスケープされたものが、ドロップしたファイル名を表します。
見た目は同じでも、ファイル名がどのようにつけられているかで、URL エスケープされた文字列が変わります。

例示した「ブログ」「スラド」以外でも、実際に存在するファイルを Firefox にドロップすることで、feeds.rdf の mailbox://nobody@Feeds/ 以下をどう書けばいいかを割り出せるかと思います。

以上は Windows 環境での話なので、Mac 環境に置き換えて解釈してください。

＞ meeyar さん
　解決策につながる話ではなく単に本件で起こっていることの補足に過ぎませんが、上記のうち別トピック用に Mac ユーザー向けの説明として使える内容があれば、自由にアレンジしてお使いください。

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

その方がいいでしょうね。
あっちのスレッドは、回復手順の要点を的確・簡潔にまとめてユーザーが参照できるようにしておけば、あっちのスレッドをポイントしておしまい、にできる。
「～のようだ」といったいい加減な根拠で書かれた手順なんて、百害あって一利なし、だし、こっちはこっちで、問題がなにかをつきとめるだけで時間と手間がかかり、ようやく最終案になりそうなパッチが提供されたかも、という段階で、まだまだフォローがいるから長くなるし、「ボタン一発で全て解決」を期待しているユーザーさんだと読む気にもならないでしょう。

で、Unicodeには、(a)「グ」(U+30B0の1文字のみ、utf-8=0xE382B0、NFC、Composed Form、全角かな・カタカナ方式)で表現する場合と、
(b)「ク」と「゙ 」(U+30AFとU+3099の2文字、utf-8=0xE382AFとutf-8=0xE38299、NFD、Decomposed Form、半角カタカナ方式)で表現する場合があって、
文字の入力や表示では通常(a)なので、そこに(b)のものをペーストすれば、(b)を(a)に変換する処理が入っていなければ、おっしゃるような現象が起きますし、
(a)と(b)が混在するとやりにくくってしょうがないから「正規化」して、どちらかに統一する、ということをします。

しかし、今回の問題は、アプリケーションがちゃんと正規化しているか・していないか、といった類の問題とは、毛色が違います。
(0) Mac OS Xでは、ファイルの作成は(a)でファイル名をリクエストするが、HFS+のデフォールト(推奨)では、ファイルシステムが(b)でファイル名を保存する。
(1) Mac OS X上でThunderbirdが、msgFolder=createLocalSubfolder(NFCのファイル名)でフォルダーを作った時に、msgFolderオブジェクトのmsgFolder.URIには、NFC(Composed Form)のmailbox URIがセットされる。
(2) Mac OS X上でThunderbirdが、フォルダーをオープンした時に入手したmsgFolderオブジェクトのmsgFolder.URIには、HFS+ファイルシステム内のファイル名を元にした、NFD(Decomposed Form)のmailbox URIがセットされる。
(3) フィードで購読をした時に(1)でファイルが作られると、feeds.rdf内のfz:feedのエントリーに、(1)のmsgFolder.URIの値が書かれ、それがそのままfz:feedのエントリーの検索に使われるので問題なし。
しかし、再起動後は、(2)のmsgFolder.URIの値を使ってfz:feedのエントリーの検索が行われるので、エントリーを見つけられない。

この、Mac OS XのHFS+における、(1)と(2)のmsgFolder.URIの値の食い違いが、問題なのです。
フォルダーを最初に作った時のmsgFolder.URIの値をfeeds.rdfに保存しておいてそれを未来永劫使う、という、フィード側の悪行のせいなのかもしれないけれど、
Mac OS XのHFS+にきちんと対応していないcreateLocalSubfolder()のバグだと言ってもいいように思います。
(createLocalSubfolder経由だと、本来のデザインのファイルシステム上のファイル名からではなく、メモリー上のリクエストした名前からmsgFolder.URIをセットしている、とか)

UnicodeのNFD/NFCが関係するし、feeds.rdf内のチェックをしてもらった時に、%エスケープしたutf-8のデータがでてきますから、そのあたりの説明はユーザーに対して親切でしょうけど、「全角ひらがな・カタカナ方式のデータ」と「半角カタカナ方式のデータ」の2種類がある、という程度であっても、問題の本質の説明と回復手順の説明には、何の支障もないと思います。
わからなきゃ、「unicode NFC NFD」でググルとかすれば、一杯ヒットして来るんだから、一々長い説明を加える必要はないんじゃないかなぁ。
やりすぎると、「～のようだ」をベースにした、闇雲に何かを削除して購読させる、というのと、似たり寄ったり。

また、Linux/Winでは、ファイルシステム上のファイル名は、Unicodeをサポートしている場合は、NFCを使うか、リクエストされたファイル名そのまま、で、UIなどでは全てNFCだから、この問題はおきません。
だから、LinuxやWinでの例をだしてくるのもどうかと。
(WinのNTFSだと、任意のUnicodeの文字をファイル名に使えたはずだから、NFDのフィル名とNFCのファイル名は、別物かも。大文字と小文字の同一視、みたいなことをしているかもしれませんが)

[追記 on 2015/11/06]
ユニコードの日本語のひらがな・カタカナだったら、
http://www.taishukan.co.jp/kokugo/webko ... 03_03.html
ラテン文字のウムラウトやマクロンやアキュートとかだったら、
http://www.taishukan.co.jp/kokugo/webko ... 03_02.html
あたりをポイントしておけばいい。
高校生向けの参考書的に書かれているから、わかりやすいし。
どうしても例を提示して自分で説明したいんだったら、
Mac OS X上でフィードのフォルダーのリネームだけで問題を再現できるから、Mac OS X上で、「U　+　ウムラウト(COMBINING DIAERESIS,U+0308)　＋　マクロン(COMBINING MACRON,U+0304)」と「U　+　マクロン　＋　ウムラウト」の可能な組み合わせのそれぞれでリネームしてみると、面白いかも。
「Uウムラウト」はNFC(Composed Form)の単独の文字としても定義されているから、バリエーションが増える。
立方メートル==㎥(U+33A5)==「m(U+006D) ＋上付きの3(U+00B3)」にリネームしてみるとか、「か+半濁音」(鼻濁音の表現)にリネームして遊んでみるとかも、いいかもしれません。
[追記おわり]