mailto URI, усеченный между Java.Desktop и Windows / MS outlook - PullRequest
4 голосов
/ 24 февраля 2012

Я пытаюсь создать инструмент для автоматического сообщения об ошибках для нашего настольного Java-приложения.Идея состоит в том, чтобы максимально упростить для клиентов отправку нам отчетов об ошибках в случае сбоя нашего приложения.

Используя API Desktop.mail, я могу создавать сообщения, которые можно легко редактировать и отправлять с нашегопользователи, но я сталкиваюсь с системными ограничениями на нескольких платформах (в частности, Windows 7 и MS Outlook, которые используют большинство клиентов)

Когда я запускаю приведенный ниже пример кода, вы заметите, что сообщение электронной почты, котороеотображается обрезает включенную трассировку стека.Я считаю, что это как-то связано с максимальной длиной командных строк или URI в базовых системах.

Есть ли лучший способ создать письмо из сообщения об ошибке, которое не подпадает под это ограничение?

import java.awt.Desktop;
import java.io.PrintWriter;
import java.io.StringWriter;
import java.net.URI;
import java.net.URLEncoder;

public class Scratchpad {

    public static void main(String[] args) throws Exception {
        try {
            generateLongStackTrace();
        } catch (Error e) {
            URI uri = createMailURI(e);
            // this will correctly pop up the system email client, but it will truncate the message
            // after about 2K of data (this seems system dependent)
            Desktop.getDesktop().mail(uri);
        }
    }

    // Will eventually generate a really long stack overflow error
    public static void generateLongStackTrace() throws Exception {
        generateLongStackTrace();
    }

    public static URI createMailURI(Error e) throws Exception {
        StringBuilder builder = new StringBuilder();
        builder.append("mailto:foo@example.com?body=");
        // encodes the stack trace in a mailto URI friendly form
        String encodedStackTrace = URLEncoder.encode(dumpToString(e), "utf-8").replace("+", "%20");
        builder.append(encodedStackTrace);
        return new URI(builder.toString());
    }

    // Dumps the offending stack trace into a string object.
    public static String dumpToString(Error e) {
        StringWriter sWriter = new StringWriter();
        PrintWriter writer = new PrintWriter(sWriter);
        e.printStackTrace(writer);
        writer.flush();
        return sWriter.toString();
    }

}

1 Ответ

2 голосов
/ 01 марта 2012

есть ограничения по длине относительно допустимых URL в ie и длина командной строки Windows (см. здесь , здесь , здесь и здесь) - мне кажется, вы столкнулись с одним из них (хотя я признаю, что я не проверил строго).
однако я думаю, что это правдоподобное предположение, что даже если вы могли бы пробираться сквозь указанные ограничения, длинаобщий буфер передачи между настольными приложениями (если вы не используете выделенный API для удаленного управления целевым приложением) будет каким-то образом ограничен без лазейки.

, поэтому я бы предложил одну из следующих стратегий:

  1. распространение через веб-сервер.

    • загрузка данных для отправки на веб-сервер вместо использования метода загрузки файлов в формате html.в основном вы должны подделать POST-запрос полезной нагрузки с типом контента, установленным в 'multipart / form-data'.вашему контенту потребуются некоторые данные-оболочки, чтобы синтаксически соответствовать этому типу MIME.
    • фактическая передача может быть инициирована с помощью COM-объекта WinHttpRequest под windows или командной строки curlпрограмма отовсюду.
    • обработка на стороне сервера может быть делегирована подходящему обработчику cgi, например,.может создать (короткую) ссылку для загрузки данных с веб-сервера.
    • эта ссылка может быть частью http-ответа на запрос на загрузку, или вы создаете ее на стороне клиента в соответствующем формате для публикации навеб-сервер без изменений.
    • pro:
      эта схема осуществима - я неоднократно применял ее в корпоративных проектах.Передача данных может быть защищена через https.
    • con:
      требуется веб-сервер для реализации
  2. отправить письмо с использованием вложения (для некоторых деталей см. Здесь ):

    • сохранить тело вашего сообщения в некотором файле на рабочем столе.
    • создать почтовую ссылку, которая ссылается на вложение (вместобольшая часть вашего тела)
    • любой приличный почтовый клиент сможет показывать вложение встроенным, если у него есть какой-то элементарный тип пантомимы, например «text / plain».на платформах Windows вы устанавливаете его, выбирая правильное расширение файла ('.txt')
    • pro:
      simple
    • con:
      доступ к файловой системе на клиентской платформе;не проверено (по крайней мере, мной)

удачи!

...