Win7の「送信先>圧縮（zip形式）フォルダー」の名前にUnicode文字を含むファイルを圧縮する際のエラー
©や™などの名前にUnicode文字を含むファイルをZip圧縮しようとすると、次のエラーが発生します。
[ウィンドウタイトル]圧縮（zip形式）フォルダエラー
[コンテンツ] 'C：\ Asd™.txt'には、™などの圧縮フォルダーで使用できない文字が含まれているため、圧縮できません。このファイルまたはディレクトリの名前を変更する必要があります。
[OK]
これはWindows 7を再インストールしたときにのみ問題になりました。おそらく、このエラーから自動的に解決するために必要なリソースがいくつかありましたが、今ではほとんどクリーンインストールでファイルを圧縮できません。どうすれば修正できますか？
UPD：この質問を投稿してからしばらく時間が経過しましたが、通常のアプリケーションの一部をインストールしましたが、問題はまだ存在し、それが原因かどうかわかりません以前から特定のアプリケーションをインストールすることで修正できます。
この質問へのコメント で報告されているように、Windows 10の組み込みの圧縮にはこの問題がない可能性があります。
問題の文字が英語以外の言語からのものであるが、Microsoftがサポートしている場合、Windows Updateから関連するMUI（多言語ユーザーインターフェイス）言語パックをインストールできます。または、可能な修正として、関連するLIP（Language Interface Pack）from here を使用します。
上記に加えて、システムロケールを変更する必要がある場合もあります。
システムロケールは、Unicodeを使用しないプログラムで情報を入力および表示するために使用されるデフォルトの文字セット（文字、記号、および数字）とフォントを決定します。これにより、Unicode以外のプログラムを、指定した言語を使用してコンピューター上で実行できます。コンピューターに追加の表示言語をインストールするときに、デフォルトのシステムロケールを変更する必要がある場合があります。システムロケールに別の言語を選択しても、WindowsやUnicodeを使用する他のプログラムのメニューやダイアログボックスの言語には影響しません。
そうするために：
スタートメニューの検索ボックスに「region」と入力します（引用符は不要）。
地域と言語コントロールパネルアプレットを開きます
管理タブをクリックし、非Unicodeプログラムの言語で、システムロケールの変更。管理者のパスワードまたは確認を求められたら、パスワードを入力するか、確認を提供します。
言語を選択し、[OK]をクリックします。
コンピュータを再起動するように求められたら、今すぐ再起動をクリックして再起動します。
![Win7 Change System Locale]()
ただし、上記のように問題のある文字が™のようなものである場合、これに対する正式なMicrosoftの修正は存在しないと思いますzipfldr.dll制限、Windowsがこの機能を備えている限り存在します（つまり、実際にdid以前に修正した場合、サードパーティのコンポーネントをインストールした可能性があります）。 Wikipedia から：
Microsoft Windowsのバージョンには、Plus以降のExplorerでのZip圧縮のサポートが含まれています。パックはWindows 98用にリリースされました。Microsoftはこの機能を「圧縮フォルダ」と呼んでいます。すべてのZip機能がWindows圧縮フォルダ機能でサポートされているわけではありません。たとえば、AES暗号化、分割またはスパンアーカイブ、およびUnicodeエントリエンコーディングは、Windowsの圧縮フォルダー機能による読み取りまたは書き込みが可能であることがわかっていませんXP以降のバージョン。
Zipファイル形式は、長い間Unicdeをサポートしていませんでした。この拡張機能は、2006年に6年前に追加されただけです。付録のとおりです。付録D-言語エンコード（EFS）Zipファイル形式の仕様 ：
D.1 Zip形式はこれまで、元のIBM PC文字エンコードセット（一般にIBMコードページ437と呼ばれます）のみをサポートしてきました。これにより、ファイル名の文字の格納は、元のMS-DOSの範囲内の文字のみに制限され、適切にサポートされません。他の文字エンコーディングまたは言語でのファイル名。この制限に対処するために、この仕様では次の変更がサポートされます。 [残りのドキュメントを読む。]
それ以来、このフォーマットを実装するすべての主要なWindowsアーカイバが更新され、Unicodeサポートが含まれるようになりました。2008年のWinZipから始めました。不幸なことに、Microsoftは奇妙な理由で圧縮フォルダ機能のサードパーティライブラリをライセンスしました（ただし、 Zipサポートのコーディングは非常に困難です）。明らかに、このライブラリは、Zipファイル形式へのUnicodeの追加よりも古いものです。また、この機能をどれほど重視しているかを示す明確な兆候として、Microsoftはこのバグを修正するコードを更新していませんtill date（どうやら、最新の新しいSystem.IO.ZipArchiveクラスも.Net Frameworkのバージョン、つまり4.5では最初はこれが正しく行われていませんでしたが、バグは修正されました）。 多くのフル機能を備えたサードパーティ製アーカイバのいずれかを誰もがインストールすることを期待していると思います。これは、まさに私が上記で推奨したものです。
Microsoftの Michael Kaplan による次の一連のブログ投稿で、WindowsでのこのUnicodeのサポートの特異な欠如に関する厳格な詳細を読むことができます。
追伸「Windowsの「送信先」での圧縮は、Winrarの「最高」の圧縮と同じくらい効果的ですが、はるかに高速であることがわかりました。」 -私はこれを何度もテストしました。 WinRARのAdd to archiveダイアログを開くのにかかる余分な時間を除いて、アーカイブ形式としてZipを選択してOKを押すと、圧縮にかかった実際の時間は大体どちらも同じですが、WinRARの方が一般的に時間がかかりません（違いはごくわずかですが）。大きな違いがある場合は、最初に一連のファイルでWinRARをテストしてから、すぐに同じファイルを圧縮フォルダーで圧縮した場合にのみ可能でした。当然のことながら、Windowsで2度目にはすでにデータがキャッシュされていたため、プロセスは最初に行った時間の何分の1かかかりました。現在のWindowsセッションで以前に触れていない一連のファイルに対して、逆の順序で実行します。結果は逆になると思います。 :)
最終的な圧縮サイズについては、アーカイブされたファイル形式のデータ/組み合わせに応じて、2つのうちどちらかがより適切に機能していることがわかりました（ただし、違いはごくわずかです）。もちろん、7zまたはRar（またはWinZipのZipX）フォーマットは、この点でfar優れており、ほぼいつでもプレーンオールジップ（つまり、従来のレガシーを使用するZip deflatePPMd などの代わりにアルゴリズム）。
同じ問題が発生しました。 7-Zipマネージャーを使用してファイルを圧縮すると、問題が解決します。 :)