構造の属性値の文字化

一番簡単な対処としてはAsciiベースの命名規則に則ったフォルダ／ファイルの運用を行うことでしょう。
また、工程を簡素化するために中間工程をPDFベースに変更しXMLでの運用部分を絞り込むのも事故を誘発する部分を減ずる効果がでるようにも感じます。
工程を確認していないのではっきりしたことは申し上げられませんが、スクリプト等の併用によりリスクを回避するなどの方法も考えられますので、一度じっくり考えられたらよいかと思います。
ちなみに、スクリプトでデコードを行う場合は以下のようになります。

decodeURI("%e3%81%82%e3%81%82%e3%81%82%e3%81%82/%e5%85%a8%e5%9b%bd%e7%84%a1%e6%96%99.eps");

いろいろと返信ありがとうございます。エンコードの言葉が出ず、文字化けと記入してしまいご迷惑をおかけしています。質問では、簡単な項目で載せさせていただきましたが、使用用途としてアクセスより書き出したCSVデータをもとにXMLを作り、ドキュメント貼り付け→文字修正→XML書き出し、別ドキュメント（使用台紙）にXML貼り付けをし、校了後アクセス戻しを行っています。アクセス戻しの際にデコードも考えていますが、現状の問題は使用画像が一部日本語が含まれている事があり、画像が欠落することでミスにつながる危険性があることです。今回の質問で欧文に変更と返信がありましたので、視野に入れて考えていきます。

はい、yusuke_sさんの指摘が正しいです。これは文字化けでもなんでもなく正しくエンコードされています。気にせずにそのまま運用してください。
XML自体のUTF-8で吐き出されるのですが、内部のパーサーがAsciiベースの処理を行う為にプロパティ周りの文字化けを防ぐために予めエンコード処理を行いそれを保持するという事だと思われます。
ちなみに「%e3%81%82%e3%81%82%e3%81%82%e3%81%82/%e5%85%a8%e5%9b%bd%e7%84%a1%e6%96%99.eps"」
はUTF-8文字コードがURIエンコードされていますので、頭から『「あ（e3 81 82）」「あ（e3 81 82）」「あ（e3 81 82）」「あ（e3 81 82）」/「全（e5 85 a8）」「国（e5 9b bd）」「無（e7 84 a1）」「料（e6 96 99）」.eps』と読めます。
このXMLを読み込めば以下のようにデコードされますのでご安心を。

kafeetさん

これは文字化けでありません。

URIエンコードもしくは%エンコードと呼ばれる方式で文字列の符号化が行われているものです。

たとえば、ウェブサイトのURLなどで見たことがあるかもしれません。

XMLの属性値に（いわゆる）欧文以外の文字を使うことでこのようになります。

assauseさんのおっしゃるとおり（いわゆる）欧文以外の文字を使わない、ということでしか回避できません。

日本語を使わない、くらいではないでしょうか。

またXMLにした場合も基本的にデータそのものもXMLを理解した人が取り扱うものですから、通常、タグや属性について日本語表記を用いることも多くないように考えます。