こんばんは
UiPath Studio 2025.0.167STS Community editionのユーザーです。
POP3サーバを使っている環境で、下記2パターンでOutlook受信メールを取得してみました。
1.デスクトップ版 Outlook アプリを使用アクティビティ内に繰り返し（各メール）アクティビティを置いたケース
2.Get POP3 Mail Messagesアクティビティで受信メール取得後、ForEachアクティビティでcurrentMailMessageを回すケース
1.ですと、日本語文字コードをOutlookが適切に自動でデコードしてExcel出力してくれますが、
2.ですと、4種類以上ある日本語文字コードをプログラマが適切にデコードしないと、Excelにメール内容を出力した際に文字化けしてしまうため、ワークフロー作成がかなり面倒です。
2.を使用しておられる方は日本語文字コードのデコードはどのように対処しておられますか？
こんにちは
下記トピックとも関連しますが、基本的にメールbodyのエンコーディング情報はメールヘッダに格納されているはずなので、それを元にデコードするのが基本的なアプローチになります。ただしお行儀の良くないメーラーはこのあたりの情報が欠落しているかもしれないので、まずはオリジナルのメッセージでどのような情報があるか、GetPOP3MailMessagesでこれらの情報が取得できるかの確認になります。
サブジェクトの方も同様ですが、こちらは元々はそれ自身がMimeに従ってエンコードされていると思いますので、こちらに必要な情報があると思います。(こちらも、まずはオリジナルがどのようになっているかを確認した方が良いと思います)
スキル不足で、何をどう調べればよいかさっぱり分かりません。
ヘッダ情報のBodyエンコード情報やMIMEエンコードをどのように調べれば良いか、参考URLを紹介いただけないでしょうか？
Hi, probably you misunderstood my requirement…
What I wanted to know was how to clarify encoding type like “shift-jis”,“ISO-2022-JP” in mail.Subject and Mail.Body.
Cheers, Love your Lord Brahma
まずはお使いのメーラーで当該メールのヘッダを確認すると良いかと思います。
Outlookなら（バージョンにより差異があるかもでしれませんが）当該メールをダブルクリック等で別ウインドウで開いて、[ファイル]-[プロパティ]の画面でインターネットヘッダーのセクションがあるので、その内容になります。
ヘッダ－中にボディの文字コードの情報があれば、それを使用すれば良いです。（Content-Typeヘッダ等）
SubjectはMIMEエンコードされていると思いますので、その情報からデコードします。
もしエンコーディング情報が無ければ、発信元がお行儀があまりよろしくないですが、ある程度決め打ちでデコードしていくしかありません。
オリジナルのメッセージ中に文字コードの情報があるようであれば、あとはそれらをUiPathで取得できるかが問題になります。取得したMailMessage中にこれらの情報があれば、それを使用します。なければ別の手段での取得を試みる（例えばメール取得についてアクティビティではなく、コードで実装する等）等になると思います。
こんにちは
これをUiPathワークフローで実行するには、1件ずつキーボードショートカットでやるしかないという理解ですが、正しいでしょうか？
違います。上記は現状把握、原因の切り分けのためにあらかじめ手動で調査するものです。
UiPathですべきことは以下になりますが、そもそもオリジナルのメールに情報がなければ取得のしようがありませんので。
オリジナルのメッセージ中に文字コードの情報があるようであれば、あとはそれらをUiPathで取得できるかが問題になります。取得したMailMessage中にこれらの情報があれば、それを使用します
Mail.SubjectのエンコードタイプはSubject:ヘッダを見れば分かりそうでしたが、
Subject: =?iso-2022-jp?B?GyRCIVokTSRzJC0kcyVNJUMlSCFbRUU7UkhHIVZHLzZiGyhC?=
Subject: =?ISO-2022-JP?B?GyRCIVZCaBsoQjEzGyRCMnNGfEtcSTRMPjsz
Mail.Bodyのエンコード方法は
Content-Type: text/plain; charset=UTF-8
Content-Type: multipart/alternative; boundary="000000000000b7549d0636e05c98"
のように、エンコードタイプが分かるものもそうでない場合もある印象です。
結局ヘッダ情報を見ても100%の結果は期待できないという認識で合ってますか？
これは複数のデータが添付として扱われているケースで、その添付されているパートにおそらく文字コード定義が記載されていると思います。（こちらはメールの生データ全体を確認しないとわかりませんが）
今文字化けとして問題になっているケースは、それぞれどのようなヘッダ構成になっていますでしょうか？Multipartのケースも文字化けしていますでしょうか？
ある程度条件が特定できそうなら、GetPOP3MailMessageの出力中に必要なヘッダが格納されているかの確認が必要になると思います。
このメールのインターネットヘッダで文字コードが書いてあるのは下記だけでした。
Mail.Bodyに関するencode情報は見当たりませんでした。結局このアプローチでは、
Mail.SubjectとMail.Bodyの両方のencode情報を100%正確に入手するのは難しいのでは？
Subject: =?UTF-8?B?UmU6IOOAkOaDheWgseWFseacieOAkUNoYXB0ZXIwMuWOn+eov+S/ruato+WPr+iDveaApw==?=
=?UTF-8?B?5pyJ44KK?=
To: =?UTF-8?B?5rqd5Y+j5YGl5LqM?=
Cc: =?UTF-8?B?5qmL5pys5Lqr56WQ?=
From: =?UTF-8?B?5Yqg6Jek6ZqG5aSq6YOO?
Content-Type: multipart/alternative; boundary="000000000000b7549d0636e05c98"
なので、 multipart/alternativeの場合で本文が添付となっている場合はメールヘッダには文字コード情報はありません。各パートに文字コード記載があるとおもうので、多くの処理系では正しく文字コードを処理できると思いますが、実際にこのケースで文字化けが発生していますでしょうか？
各パートとはどのパートでしょうか？インターネットヘッダと本文以外にどのようなパートがありますか？
メールをヘッダとボディに分けるとすれば、ボディ中に必要なデータが格納されています。例えばxlsxファイルをメールに添付するケースもあると思いますが、このような場合でもそのxlsxファイルはボディ内に添付パートとして、符号化され格納されています。
例えばmultipart/alternativeの場合、以下RFCの7.3.2に例が載っています。
このあたりを見たければ、メールの生データを見ないとわからないので、それが可能なメーラー等が必要です。（が、一般的な処理系ですと、MIMEの情報に従って文字コードを正しく処理できるので、文字化けにつながらないではとも思います。）
少なくとも、Desktop版Outlookでは本文に存在するコード情報は見れないという理解で合ってますか？
見る方法があるかもしれませんが、私は存じません。
下記を見るとoutlookでもメッセージソースを見る方法がありそうですが、レジストリを編集しなければ駄目そうなので止めときます。
https://ja.eyewated.com/outlook%E3%81%A7%E5%AE%8C%E5%85%A8%E3%81%AA%E3%83%A1%E3%83%83%E3%82%BB%E3%83%BC%E3%82%B8%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%92%E8%A1%A8%E7%A4%BA%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95/