ファイルを管理する上で、使わない方が良い文字について語ります。
　ファイラーというよりも、Windows一般の教養ネタです。

　エクスプローラーでは閲覧も、削除も、リネームもできなくなるような悪質としか言いようが無いファイル名を取りあげて解説しています。
　これらは特にWindows10で仕様が大きく変わっており、見つけにくく、削除しにくく、そのため悪用しやすくなっています。
　原因はWindows10からILCreateFromPath()などのパス文字列とITEMIDLISTの相互変換をするAPI全般の動作が変更されていることがあげられます。
　具体的には、末尾ピリオドやスペースなどのイレギュラーな名称の変換が行えなくなっており、外部のソフトでも対応が難しくなっているためです。検証の際には十分ご注意ください。
※ほとんどの異常な名称のファイル名は、As/Rの拡張リネーム機能画面の「異常な名称のリネームを許可」にチェックを付けていればリネーム可能です。
　しかしAs/Rでも異常な名称のファイル扱いは完璧ではなく、「パス名をクリップボードへコピー」機能などのように、Windows10のAPIが返してくる間違った情報をコピーします。

　で、￥とか／とか｜とか＊とか？とか：とか＞とか＜とか”とか、使っちゃいけない文字は、どうせ使えないんだからバッサリ割愛します。
　例外的に、こういう文字を使うと、こんな時に困るよと言うのを紹介したいと思います。

　カンマやセミコロンを用いたファイル名にリネームしようとすると、Windowsのメッセージ内で使えない文字に含まれているバージョンがあります。（例:Windows7などではShell32.dllのリソース文字列に記載されている）

　これは、FAT時代の使えない文字が「.」「"」「/」「\」「[」「]」「:」「;」「|」「=」「,」であったため、非推奨で残ったのだと思われます。
　現在もよく問題になるケースで、コマンドプロンプト（cmd.exe）では「&」「(」「)」「[」「]」「{」「}」「^」「=」「;」「!」「'」「+」「,」「`」「~」がファイル名全体をダブルクオートで括らなければならない文字とされておりますので、混同しないように注意してください。
　あと最近利用が増えてるので補足しておきますが、OneDriveでは「~」「#」「%」「&」「{」「|」「}」「.」、これらも禁止されています。
　そのため、ファイル名のカンマが「^」に置き換えられるトラブルが良くありますので、興味がある方は調べてみてください。

※追記1
　Windows updateで修正されて、エクスプローラーのように別のエラーメッセージが表示されるようになったものがあります。
※追記2
　半角英数、UNICODE文字など、問題なさそう見えても万全な「文字種」は存在しません。
　何かしら癖や悪用手法があります。（断言）
　ディスクを管理しているファイルシステム、OSの種類、ミドルウェアの種類、クラウドか否かなどで、様々に条件が変わりますので、それらに適したファイル名にしてやる必要があります。

　末尾に「.」やスペースは、本来はMS-DOSの制限だったのですが、今でも制限が有効であり、作れますけど、使えません。
　エクスプローラーや、通常のコマンドプロンプトの記述ではアクセスどころか、ファイルの削除すらできません。
　というのも多くのアプリケーションでは
「C:\hoge」(末尾にスペースやピリオドがない、ごく普通のフォルダ)
「C:\hoge.」(末尾にピリオドがあるフォルダ)
「C:\hoge 」(末尾にスペースがあるフォルダ)
　なんと、この3つが別々に存在できますが、同じものとして扱われます。
　通常のアプリケーションが考え無しに作られている訳ではなく、Windows APIのデフォルトがこのような仕様だからです。
　とはいえ公開されている仕様であり特別難しいことは必要なく、開発者側の立場からすれば自由自在に扱えるファイルでもあります。

　ちなみに、このフォルダを削除するには以下のようにUNC表記で記述する必要があります。
C:\>rd "\\?\C:\hoge."
※このようなUNC表記で「\\?\」を付与する表記の場合、必ずフルパスで記載します

　逆に先頭に「.」があるファイルは、UNIX系では隠しファイルとして特別な意味があるファイルとなっています。
　ただこれ結構、末尾だろうが先頭だろうが「拡張子」という文化と相容れないので、色んなところで誤認識が多いんですよね。
　なるべく必要な時以外は使わない方がお奨めです。
　また本件の派生ですが、相対パス指定で使う「.」ピリオド1個は現在のディレクトリ、「..」ピリオド2個の場合は親ディレクトリを指しますので、これもファイル名としては使えません。

　あと、ついでに悪用事例です。
　これ、どんなファイルだと思います？

　おそらく「なんだろう？」って人は思うわけで「テキストのアイコンだから大丈夫だろ」と考えてしまって・・・で、ダブルクリックしちゃってウィルス感染というのがありがちなパターンです。

　このファイルの正体はメモ帳のアイコン画像をコピーして作成した「.exe」という実行ファイルです。
　Windowsのフォルダ設定で「登録されている拡張子は表示しない」、これがONになってると何が何だか正体がわからないファイルが表示されることになります。
　エクスプローラーの初期の設定値がそのようになっており、悪用してくださいと言わんばかりの状態なので十分ご注意ください。

　ちなみに、最近のエクスプローラーでは先頭が「.」になるようなリネームは、エラーになるように仕様変更されています。
　このようなファイルやディレクトリが必要な場合は、リネームする際に末尾に「.」を付与してください。
例）「.bmp」（ドット、ビーエムピー）を作る場合は「.bmp.」（ドット、ビーエムピー、ドット）と入力します。
　なお、As/Rでも埋め込み型のリネームも同様にエラーになりますので、末尾にドットを付与するか、こんな余計なお世話制限のない拡張リネームなどの機能を使用してください。
※Windows 10 19H1から先頭のピリオドでエラーにならないように変更されました


　先頭「.」（ドット）が2個以上あるとエラーにならないので、セキュリティを考えて・・・というのはありえませんし、UNIX系のファイルを操作する場合ってめんどくさい事になったものです。
　.htaccessとか普通に作るでしょうに・・・まさかファイラーを使えなんて話はありえませんし・・・。

　特定のハードウェアなどを示すので、作成できますが、使用できません。
　「CON, PRN, AUX, NUL, CLOCK$, COM0, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9」
　さらに言っちゃうと、これらに拡張子を付与してもダメです。
　一応、それぞれの意味をざっと書いておきます。
　CON=コンソール(キーボードだったりディスプレイだったり)
　PRN=プリンタ、AUX=RS-232Cポート、NUL=なし, CLOCK$=時計、COMn=シリアルポート(nはポート番号)、LPTn=パラレルポート(nはポート番号)
※大抵の場合、AUXはCOM1と同じ意味になります。
※エクスプローラー、コマンドプロンプト、Windowsが特殊な意味と解釈するだけであり、ファイルシステムとして許されている名称なので、UNC表記でのファイル操作が許されているAPIによって作成やリネームや削除が可能です。
　フルパスで260文字以上のファイル名が、エクスプローラー、コマンドプロンプトなどで許されないのと同様です。
　エクスプローラーやコマンドラインから操作できないことから悪用事例も見かけたことがありますが、そういう事態に陥った時は、まず落ち着いて（すごい重要）、As/Rの「異常な名称のリネームを許可」モードのようにリネーム可能なソフトを使って対処してください。
　こういうディレクトリの下に、ウィルスなどを潜伏させたり、ランサムウエアなどで利用されたりという、悪用事例はいっぱいありますので心の片隅にでも置いておくことをお勧めします。

　いわゆるマイナス記号です。
　最近はあまり聞かなくなりましたが、デスクトップ検索などの制御文字として使われることもあることから、検索でファイルが見つけられない系のトラブルがあります。
　もちろん「+」も結構微妙です。
　概ね、以下の理由からファイル名の単語の区切りにハイフンではなく、アンダーバー「_」を使う人が多い理由となります。

※今ではあまり使われなくなっていますが、ISO9660という規格のCD-ROMフォーマットでは「-」ハイフンは使用することができない禁止文字です。
※UNIX系では、コマンドラインオプションのスイッチを示す文字がハイフンであるため使用を避ける習慣があります。
　Windows系ではスイッチの記述はハイフンだったりスラッシュだったりするので、気にしない方も多いです。
※URLとして使用される場合は、Googleの公式ガイドでは「アンダースコアよりハイフンを推奨」と記載がありますが、実状は大差ありません。

　え？ちょっと待って、コロンって使えない文字じゃないの？と思われるかもしれません。
　通常だと、ドライブ文字の次に来る特殊な文字ですしね。
　ですが、UNIX系のようにそもそもAドライブとかCドライブといったドライブレターという考え方を持たないOSもあったりします。
　規定のディレクトリにマウントされますので、Windows系の文化しか知らない人はわりと戸惑います。
　また、他の使い方だと、ファイルの副ストリームへのアクセスする際に使われます。

※軽く説明
　副ストリームとは、通常のファイルの裏に書き込めるエリアでNTFSで使える機能です。
　副次ストリームとか、代替ストリームとも呼ばれます。
　ネットワークから入手したファイルを見分けるとか、ファイルシステムによる圧縮、ファイル暗号化等でも使用されるカラクリです。
　ちなみにエクスプローラーから参照する方法はありませんので、わりと良く悪用されてます。
　例えば、ファイルサイズが0のテキストファイルを用意して、15テラバイト（NTFSの上限値がこの辺）のディスク領域を要求して圧迫・・・とか、割と簡単にWindowsを瀕死に追い込むことができます。

　でまぁ、UNIX系（Androidなどが身近な例）だと副ストリームもドライブレターもありませんので、普通にファイル名の文字として使えます。(Macではパス区切り文字がコロンであった時代があり、特殊な例外になってます)
　つまり、スマホで書き物して、ファイル名をつけて保存って時にやらかしました。（作者）
　PC使っていて何が困るかってぇと、NASなどのネットワークドライブや、ファイルサーバーなどで良く利用されるSambaなどで出くわすことがあります。
　その辺りも考えて作られているファイル管理ソフトであっても、ファイル名がショートファイル名のような省略形で表示されるため、見分けが付かなくなるというわけです。
　※sambaでは 「"」「*」「/」「:」「>」「<」「?」「\」「|」なども許されています。

　パス指定で区切り位置を調整するので「”」で括らなきゃいけなくなります。
　可能であれば「_」アンダーバーなどに置き換えることを推奨します。
　「Documents and Settings」とか「Program Files」とか、Windows95から半角スペースも使えるよ！ってアピールしたかっただけとちゃうんか？という気がしてなりません。
　ただ全角スペースなら良いか？と言われれば微妙でして、見えない文字というのは、トラブル防止という観点からすると避けた方が良いと思います。

※見えない文字の恐怖の補足
　ファイル名の先頭への空白、ファイル名の末尾に空白なども結構トラブルの元です。
　（先頭への空白は、エクスプローラーやファイラーによっては禁止されているものが多々ありますが、末尾はかなり無警戒です）
　例えば
「test.txt(スペース100個).exe」
　というファイルを作ってみてください。
　エクスプローラーで見ると、拡張子表示をONにしていても
「test.txt　　　　　　　　　　　　　　...」
　このように、末尾が省略されてテキストなのか実行ファイルなのか判別できず、exeファイルのアイコン画像をそれらしいものにしておけば簡単に騙されてしまうでしょう。
　エクスプローラーをはじめとする、拡張子分離機能を持たないファイラーを使ってる人を引っ掛けるための簡単な騙しの手口の一つなんで、ご注意ください。

　半角のスペースはダブルクォーテーションで括らなければなりませんが、全角のスペースはダブルクォーテーション括る必要はありません。
　不思議だと思ったことはありませんか？

　これ種明かししますと、日本語の全角スペースは和字間隔（わじかんかく）と呼ばれる特殊な文字なんです。
　具体的には、段落の先頭のスペース、作文の際のタイトル位置、短歌や俳句の区切りといった用途で使われています。
　つまり、文章として意味のある文字(表意文字)という扱いなんですね。
　「行間を読む」とはよく言われますが、日本語だと文字通り行間に意味があるんです。

　それゆえ、ダブルクォーテーションで括る必要のない文字として扱われます。

　このように、言語圏の文化によってスペース1個にしても、色んな背景があるものなのです。
　アイルランド語のオガム文字の空白、モンゴル語母音の区切り記号などが代表的な所だと思いますので、興味がある方は調べてみてください。
　ちなみに、UNICODEの文字コードでスペースとして扱われるのは、
0x0020、0x00A0、0x1680、0x180E、0x2000、0x2001、0x2002、0x2003、0x2004、0x2005、0x2006、0x2007、0x2008、0x2009、0x200A、 0x200B、0x202F、0x205F、0x3000、0xFEFF
　執筆時点で、この20種類が該当します。
　いずれも見えませんが、別の文字です。
　この中の日本語の全角スペースは0x3000ですね。1個だけ特殊な動きになってます。

　なお、日本語以外の環境については専門外なんで、嘘書いてたら指摘ください。

UNICODE文字、機種依存文字

　いわゆる①や半角カナなど、PCメールなどで送らないほうが良い文字などが該当します。
　今どき①が使えない環境はありませんが、昔はありましたというものですね。

　それに対して、半角のカナが混じっていると、文字コード自動判別が確実に行えなくなります。
　半角カナには、そういう文字コードの番号が振られているからなので、数学的に証明できる定理だったりします。
　そういう経緯もあって、半角カナは１バイトであったり、2バイト以上であったりと文字コードによって扱いが変わる、とても難儀な文字です。

　ですから、通常のWindows PCでのやり取りは問題ないのですが、他のOSへ持っていった時、例えばスマートフォンなどで問題を起こすことが多々あります。
　あまり知られていないことですが、文字コードの自動判別のアルゴリズムは「多数決」による確率なので確実とは言えないシロモノですしね。


　あと、UNICODE文字の中には文字を読む方向を変えるという、画面に表示されないモノ（制御文字と言います）などもありますので、使わないにこしたことはありません。
　文字方向を変える制御文字などは悪用される場合も多々ありますしね。

※文字の方向を変える特殊文字による悪用事例
　「テスト[RLO]txt.exe」
　というファイルがあったとします。
　エクスプローラーでは
　「テストexe.txt」
　と、表示されます。
　この[RLO]というのは、文字の方向を右→左に変えろという方向を変える文字で、テキストフィールドの右クリックメニューから簡単に挿入できるため、全然珍しいものじゃありません。

　実行可能なexeファイルなのに、あたかも拡張子がtxtファイルであるように見えます。
　さらに、exeファイルのアイコンの画像をメモ帳と同じにしておけば、エクスプローラーで見たときに実行ファイルなのかテキストファイルなのか、まず判断が付かないでしょう。
　こうやって、ウィルスとかマルウェアとかに感染させようとするケースが多々あります。
　宣伝っぽくて嫌な感じがしますが、古くからAs/Rはこういうファイルを色分けして気付かせる機能を持ってます。

補足
　問い合わせがあったので、補足です。
　人名で良くあるトラブル事例で、以下のような漢字が良く文字化けします。
　通称「はしご高」SJIS(0xFBFC)、UNICODE(U+9AD9)
　百貨店の「髙島屋」さんとか有名です。
　通称「立つ崎」SJIS(0xFAB1)、UNICODE(U+FA11)
　シュウマイ屋さんの「崎陽軒」さんとか有名です。

　JIS第一水準、JIS第二水準からはみ出た部分の、拡張文字セットの中にはこういう字が少なからずあります。
　MacJapanese時代から、存在しない文字＝使えない、機種依存文字だったんで、使わない方が無難です。

　ちなみに、ウチの天野家も「天」の字の上の棒が短い字体が正なのですが、諦めています。

機種依存文字(Macintoshとの連携限定)

　いくつか、ハマるポイントは明確になっているので、そこだけ注意すれば良いでしょう。

　MACで日本語使うな、ASCII文字だけ使うのが正義！と言えます。（非常に偏った意見です）

　歴史を振り返るとMacintoshの古くは、Shift_JISを独自に拡張したMacJapaneseでしたが、一瞬EUCを経て今はUTF8-MACに変わっています。
　文化圏が違うためか、いろんなところでボロが出ていますので、そういうモノだと認識するほかありません。

　よくあるトラブルは、日本語のファイル名やフォルダー名を含んだZip書庫とかが良く問題になっています。
　これはZip書庫のフォーマットが変更になり、何の文字コードなのか？を指定できるようになったのですが、対応アプリや対応OSに差があって文字化けする組み合わせがありました。
　つまり、もともとは単なるバイト列だったものを、それを日本語環境のZIP解凍アプリ開発者達がSJISと解釈して解凍していたというものです。

　で、この新ZipフォーマットにMacintosh側は積極的に対応したんですが、Windows側がなかなか新フォーマットに対応しなかったので文字化けしていた、というものです。
　この時期、Apple社とMicrosoft社の仲が悪かったという事情もあったと思います。（見解には個人差があります）
　解凍する側の人は、アプリやOSの標準機能での対応状況とか、気にしない or 気づかない or 知ろうともしないことが多いですからね・・・

　こ結局のところ、解凍側はきちんとサポートされているアプリを選定する、圧縮する側もきちんとサポートされているアプリを選定するのはもちろん、「__MACOSX」を自動的に除去、ピリオドで始まるファイルを除去といった、他のOSのことをきちんと配慮した圧縮ソフトを使用するということが肝要かと思います。
　標準機能？あんなものは飾りです。偉い人にはそれがわからんのですよ。

　また、文字コード関連で言えば、濁点や半濁点などはトラブル事例が多いです。
　日本語のかなに付ける、点々や丸です。
　Windowsの世界では「か」に濁点の点々付けることが可能で、「が」という1文字が存在します。
　Macintoshの世界では、「か」と濁点の点々を別の文字扱い、「か」と「゛」の2文字で表現します。
　アルファベットで例えるならら「d」を「c」と「l」に分解するような乱暴な行為と言っても差し支えなく、過去の経緯はともかく、文字に対する敬意ってもんが欠落している仕様と言わざるを得ません。（見解には個人差があります）
　常識的なUTF8なら普通に「が」が存在しているので、単なるマッピングバグだと思います。（見解には個人差があります）

　これは、しれっと上で「UTF8-MAC」と書いているようにMacintoshのUTF8はApple社による独自仕様の方言であり、日本語の対応が残念な仕様になっています。
　日本語をよく知らない人がMacintoshの日本語環境を設計したんだとか（根拠のない噂です）、日本語UTF8の策定時期に問題があったとか（根拠のない噂です）、いろんな説がありますが、現状のある姿は変えようがないので、マッピングバグがある前提で行動することが必要になるわけです。

　ちなみに、これは一般に「NFC/NFD問題」と呼ばれている欠陥（見解には個人差があります）なので、詳しく知りたい方はこれをキーワードにすると良いでしょう。
　Apple社も自社の独自仕様が引きを超す欠陥なので頑張って対処してますけど(2024年現在)、このバグは思い出したように再発したり、新規アプリで紛れ込んだりと中々潰しきれないようです。
　ぶっちゃけた話をすると、アプリの開発者もUTF8からUTF8-MACへ変換、また逆をするライブラリなどを使わざるを得ないので、アプリによって対応がまちまちであり、思い出したようにトラブルが発生する・・・という事です。
　事例を補足しておくと、Zipフォーマットの方に「UTF8ですよ」と書いておきながら、なんちゃってUTF8であるUTF8-MACで書いちゃいました、なんてバグは英語圏の人はバグがあることに気づくことができないからです。

　まぁ、先に述べた通り日本語を含めて、全角文字を一切使わない癖を付けるのが一番だと思います。

補足
　今のWindowsの基本の文字コードはWindows NT 3.1(NTは一番最初のバージョンが3.1)からUNICODE(UTF16LE)です。
　ZIPフォーマットの問題と、UTF8-MACの問題を混同して解説しているサイトが非常に多かったので、「結論は一緒だけど理屈は不正確であることが多いですよ」と注意喚起しておきます。

　MS-DOSよりも前の負の遺産でもあるのですが(うろ覚えですがMicrosoft Disk BASICのFAT12の頃)、Windowsには8.3形式のショートファイル名という形式と、Windows95から使えるようになった3万2千ちょいの文字まで扱えるロングファイル名という2つの表記形式があります。
　（通常、フルパスで250文字くらいまでしか使えませんので、後述のオマケを参照してください）
　例えばこの二つのファイル名って同じものを意味します。
hogehogehoge.txt
hogeho~1.txt
　つまり、「~」ってショートファイル名を意味する文字であり、意図せず重複ファイル名を作ってしまう可能性があるんで要注意文字と言えるでしょう。

　ちなみにWindowsディレクトリで、このようなDIRコマンドを実行してみてください。
C:\Windows>dir *1*
C:\Windows>dir *~*
　試してみると、ファイル名に「1」とか「~」を含んでいないファイルが大量に表示されたと思います。
　これはショートファイル名でヒットしたからであり、「~」と数字の組み合わせは危険ということが良く分かると思います。

※ショートファイル名はOS側でディレクトリごとにユニークになるように勝手に割り振られるので、名称を変えることはできません。
　ディレクトリごとに命名されるので、同じ名称のロングファイル名から同じ名称のショートファイル名にはなりませんし、フォルダーを移動すると名称が勝手に変わります。
　また一般に「英数字6桁＋~＋数字」という組み合わせになると言われていますが、そんなことはありません。
　OSの世代によって命名法則は異なり、ショートファイル名に全角文字が含まれることもあります。
※APIレベルでも同様の現象が発生しますので、検索で引っかからない or 意図しないファイルがヒットすると言ったトラブルが多々あります。

　共有フォルダの下位に存在していると、隠しディレクトリになります。
　つまり簡単には他所から閲覧できないという用途があるのですが、意図しないでうっかり末尾に＄を付けちゃうと、わざわざ共有したのに一覧に表示されなくて、閲覧できない・・・というトラブルに会うことがあります。
　まぁ、一覧に表示されないだけなので、アドレスバーに手打ちで入力してやれば遷移できるでしょう。

　パス表記において、名称の前後を「%」で括ると環境変数と誤認することがあります。
　例えば
C:\%TEMP%
　というフォルダーが作れます。
　エクスプローラーなどのアドレスバーに「C:\%TMP%」と入力しても%で括っている部分を環境変数だと誤認して閲覧できません。
　・・・そういうものだと思ってください。

　環境変数ってなに？という人のために補足しますが、わりと有名どころで言うと、前述した%TEMP%とかですかね。
　いわゆるテンポラリディレクトリはOSのメンテナンスをしようと思うと必要になることがあります。
　他にも大量にありまして、コマンドプロンプトから
C:\>set
　とやるとこの手の環境変数は、大量に表示されると思います。
　これらのテキストと誤認されることがあるので、名称の前後を「%」で括るのは避けた方が良いでしょう。
　具体的には、Windows10の場合、%TEMP%とは以下のパスを置き換えた文字になります。
　C:\Users\＜ユーザー名＞\AppData\Local\Temp\

　「~」は再登場です。
　単に記述が面倒なだけでエスケープすりゃ良いです。
　もちろん目的を持って使用するのは一向に構いませんし、正規表現って何？という方も気にする必要はないでしょう。

「@」アットマーク

　例えばホームページ上に置くファイルの場合にわりと困ります。
　ソフトによってドメイン指定の記述と誤読しちゃうかららしいので、用途によってNGになってしまう例だと思います。
　そろそろ良いかなと思いますので、もう少し具体的な話をすると「ちゃんと考えてないアプリだと、勝手にメール送信させられちゃう」という現象が起こりうるんですよ。
　実際に悪用された事例も過去にあるんで、個人的には避けた方が良いと思っています。（見解には個人差があります）

　最近ではあまり問題になりにくいモノですが、たまに困ったことに出くわすことがあります。
　例えば、ファイルサイズが大きくて分割した後に、ファイル連結のコマンドを実行する際に困ったことになる場合があります。

　多くのツールでは、copyコマンドをBATコマンドにして連結している場合が多く、そのファイル連結の際にこんなコマンドを発行するんですよ。
C:\>copy text1.txt + text2.txt text3.txt
　これは、「text1.txt」と「text2.txt」を連結して「text3.txt」を作成してください・・・というコマンドになります。
　もちろんスペースは詰めることも可能なんで、連結記号なのかファイル名なのか悩むことになるでしょう。
　まぁ、ダブルクォーテーションで括って厳密な記述にすれば問題は起こらないでしょうが、システムの運用開発とかやってると地雷を踏んでしまうことがあります。

　これも再登場ですが、そろそろ語っても大丈夫かな？というので追加掲載です。
　わりとよくある脆弱性のレポートに「悪意を持って加工されたファイル名・・・」というのは、コレがキモになります。
　要するに、ホームページ上に置くとリクエストの引数として扱われてしまうため、いわゆるGET呼び出しの動きをすることがあります。
　他にもホームページ上でなくてもURLを解読するアプリって色々ありますよね？エクスプローラーとか・・・。

　ブラウザキャッシュとか、出所不明のZIPファイルとか、こういう記号が含まれている可能性がある「フォルダを開かない」って事が重要です。

　NTFSの環境において、ファイル名の最大の長さは約3万2千文字まで使えます。

　260文字しか使えないと言ってるサイトがやたらと多いですが、間違いです。
　単に、エクスプローラー「が」260文字以上のパスを扱えないだけなのです。
　同様に、コマンドプロンプトでは2000～8000文字くらいまでしか扱えませんので、それらを超えたパスの扱いは非常にハードルが高いものとなっています。

　これは、Windowsの内部のAPIでもフルパス表記で260文字(MAX_PATHとして定義されてる)までしか対応していないものが多く、エクスプローラーも含めて操作不能に陥ることが多々あるためです。
　実際、エクスプローラーでは閲覧も移動も削除もできなくなりますので、悪意あるソフトで悪用されるシーンが多々あります。
　（こういったファイルができてしまったら、コマンドプロンプトからショートファイル名で操作することで削除することが可能ですが、ショートファイル名も万能ではありませんので注意が必要です）
※260文字という中途半端（？）な数字なのは、ドライブレターや、UNC表記のための予約分があるためです。
※ショートファイル名で260文字以上になる場合は上記のUNC表記で操作することで編集可能ですが、現在のコマンドラインの引数の上限が約8KB（OS依存で、もっと少ない環境もあり）なので、それ以上のものは対応しているソフトを使う以外に方法はありません。

　ついでに、255文字までしか使えないと思っている方が妙に多かったので補足です。
　255文字までしか使えないのはFAT系のフォーマットの話です。
　ややこしいことに、FATフォーマットは時代に合わせて何度も更新されており、現在では510バイト(UNICODEで255文字)になっています。

※Windows10 Version 1607以降では、レジストリ値の変更で260文字の制限を一部解除できますが、詳細は非公開情報です。
Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
LongPathsEnabled=1

　コマンドプロンプト(cmd.exe)では、OSの種類によって異なりますが2047文字、もしくは8191を超える文字を入力することができません。
　NTFSの環境では、約3万2千文字のファイル名が付けられるって上で述べてますけど、もちろんエクスプローラーでファイルを作成するのはもちろん、フォルダーの閲覧すら不可能ですし、コマンドプロンプトを使っても2000文字ちょい～8100文字ちょいくらいのファイルしか扱えないということになります。
　いわゆるウィルスとか、ランサムウェアとか、悪意を持ち長ファイル名に対応したソフトによって、システムを滅茶苦茶にされても復元が不可能なんですね。
　個人的な見解ですけど、売り物のセキュリティソフトですら、2016～2017年ごろから本格化してきてるように思いますが2019年の時点でもまだまだ対応しきれてないように感じています。

　長パス対応に完全対応したソフトって見かけませんし・・・というか完全対応は不可能に近いのでAs/RでもWindowsで許される範囲の対応になっていますが、エクスプローラーやコマンドプロンプトよりは圧倒的に守備範囲が広いです。
　このようなトラブルに備えるというのは大げさだと思いますが、選択肢の一つにAs/Rを加えるというというのもアリなのかなと思って、ある程度長パス対応したソフトを公開しているという次第です。
　もちろん「こんなソフト作りましたが、よろしければどうぞ」というスタンスですので、As/Rの利用を推奨する意図は皆無です。

　「長いファイル名はショートファイル名にして削除しちゃいましょう」といった手法を紹介しているサイトを見て途方に暮れていた方がいたので、補足します。

　例えば、こんな風に
　C:\a\a\a\a\(130階層くらい省略)\a\a\a
　各サブディレクトリが１文字であるがゆえに、ショートファイル名にしても260文字を超えてしまうケースですね。
　むしろ、ショートファイル名にしようとすると、さらに長くなってしまいます。

　繰り返しますがパス長は3万以上の文字が使えるのですから、各階層が5文字くらいでトータルで3万文字くらい使えば、簡単にショートファイル名で扱えない深さの階層にすることができます。

　できるってぇことは、実際に悪用されてる実績は当然あるわけですよ。
　というわけで、力業で解除する方法です。
1.セーフモードで再起動する（問題のディレクトリ内でロックしているものを排除する）
2.「C:\a\a\a\a\(50階層くらい省略)\a\a\a」これくらいの長さで区切って、浅い階層のディレクトリに移動する
3.2を繰り返す
4.2～3で浅いところに移動したら削除するなり解析するなりする
　という手順になります。

　さっさと諦めて、ディスクをフォーマットするのもアリですね。

　このページにディープリンク貼られてるようなので補足ですが、別にいーんじゃね？と思います。
　特にシステムに由来するようなトラブル事例を聞いたことがありませんし、前述のように半角スペースの代替としても使われます。
　ただし、フォントの都合で文字数が分からない特殊性がありますので、アンダーバーを2つ以上繋げることは推奨されないでしょう。
　2文字以上続けて書くと繋がって見えて、文字数が分からないということを言っています。
　例えば「123」は明らかに3文字ですが「___」これ何文字？って、フォントの種類によっては判断できません。

　質問があったので私なりの回答も記しておきます。 　先頭にアンダーバーを付けることに、深い意味などありません。

　ただ用途によって「インクリメンタルサーチをしにくくなる」ことから「編集するな」というファイル作成者の意思が込められていることがあります。
　ウチのファイラーの配信ファイルとか、このタイプですね・・・

　それからソートしたときに上部に表示されやすくなるという件もありますが、これはお薦めしない運用です。
　作業中は良いのですが、元に戻し忘れるという事案を個人的に何度も見てます。

　あとはシステム的に許されない名称の補完として、置換されることがあります。
　SAMBA上で「te:st.txt」というファイルがあったとして、Windwos環境にコピーして持ってくると「te_st.txt」のように勝手に変換されます。
　この辺りはWindowsの版と使用APIで挙動が変わり一概に言えないところなので、こういうこともあるよという事例の紹介です。

　個人的な見解ですが先頭に記号を入れるのは、用途次第だと思います。
　いわゆるインクリメンタルサーチという、リストの中からダイレクトにアイテムを探すのに便利な機能の一つですが、エクスプローラーでは先頭一致しか使えません。
　つまり、良く使う名称に使うのは賢明とは言えません。

　逆にアクセスしにくくするという意味合いで付与するケースはアリです。
　例えば、テンポラリファイルや、マスターデータのファイルなどといった用途に向いてます。

　理由なく使うのはNGだと思います。

　エクスプローラーの欠陥仕様で、どうやっても表示されない拡張子があります。
　「lnk」、「pif」、「url」の3種で、いずれも実行可能な拡張子であり、これまでに述べている危うい仕様と組み合わせて良く悪用されています。
　脆弱性と言って差し支えないとも思いますが（見解には個人差があります）、Windowsの仕様です。

　エクスプローラなどでは「-」 「+」 「(」 「(2)」 「,」「、」「。」など、文を分かつ目的の記号文字が引っかかりません。
　他にも全角記号とかも無視されますが、ごく一般的な文字である「首」などもOSによって引っかからない文字である場合もあります。
　趣旨から外れるので、深追いしませんが「~=」などの演算子が必要になるとか、Windowsのファイル検索は引っかからないパターンが大量にあるってことだけ認識しておけば十分かと思います。

　他にも、XP以前は文字単位での検索であったのに対し、Vista以降では単語単位での検索に仕組みが変わっており、Windowsを使う以上は慣れるか、別のソフトをインストールするかの2択です。
　しかもWindowsのバージョンによって、改良と言う名の下にNGな文字がむしろ増えていたり、出力結果が異なりますので、検索に引っかからない！って問い合わせをする時は、OS名を書かないとだめでしょう。
　個人的に納得できないケースだとWindows Updateで揺らいだことにも遭遇したことが何度となくあります。

※単語で検索する際のNG例（OSの種類やインデックスの状態により結果が揺らぎます）
元ファイル「赤毛のアン.txt」
OKな入力例：アン.txt
NGな入力例：ン.txt（「ン」が単語とみなされないため）

　まぁ日本語はともかく、記号を使うファイル名は、基本的にNGってことなのでしょう・・・(2)とかエクスプローラーが勝手につけちゃうこともあるんで納得はできないですが・・・。
　だからこそ、ファイラーなんぞ作ってるわけですし、独自の検索機能を用意しているわけです（苦笑）

　私が答えるべき内容じゃない気もしますが、一応私なりの回答です。
　そもそも、コンピューターにとって「文字」とは、人間に読ませるためだけの記号であり、あまり意味のある情報じゃないんですよ。
　コンピューターが扱える情報って、最終的には機械的なスイッチのON/OFFであり、それを「人間の読みやすいように」という都合で2進数→16進数→コードから各種文字への変換表→人間が読める文字や文章なのです。

　そしてコンピューターにとって重要なのは、プログラム（命令）、処理する対象（データ）の、2種類の情報であり、何かしら処理した結果のデータを、人間様に分かるように、上記のルールに従って加工したものが文字なんですね。
　ですから、コンピュータの制御という最優先のルールがあり、その進化の歴史にまつわる制限というのも当然付いて回ることになりますし、Windowsよりも後に生まれた文字も対応不能なケースが多々あります。

　分かりやすい事例だと、最近ではPCでも使える文字で「絵文字」とかもありますけど、表示ソフトの「データ」としての対応であり、大抵の「命令」の対象となる制御が絡む部分では使えないものとして分類されるということです。
　もちろんファイル名とかは、「命令」の対象となる制御が絡む部分なので、こういった例外的な制限が付きまとうわけです。

　そうですね、当然だと思われてると思いますが、「同じディレクトリに、hoge.txtが複数存在できない」とか、よーっく考えると酷い制限ですよね。
　例えば、同じディレクトリに格納した4月1日に保存したhoge.txtと、5月3日に保存したhoge.txtが、共存できないってのはコンピューター側の都合であって、運用する人間の都合ではありません。
　暴論ですが、人間が管理するものであれば、ファイル名がユニーク（一意性を持つ）である必要性は無いと言ってます。
※ジャーナルとか履歴管理とか、そーいった別の概念でコンピュータの制限を回避するような場合もあります

　他にもファイル名の大文字・小文字を区別しないとか、言語学の観点からしたら「ふざけるな」と言いたくなるでしょうね。
　制御の対象になる制限というのは、こういうことなんです。

　先頭にスペースが含まれる場合であっても、Win32APIではファイルとして認識できます。
　ですがWinRT系のAPIではネット環境の機能追加を行ったそうで、こうしたファイル名が認識できなくなっています。
　システム開発をしていて「ファイルが読めないよ！なんでや！」というシーンにぶち当たった時に、このような地雷を気に留めておくと、解決することがあるやもしれません。（経験談）