Новые линейки и совместимость с браузером/ОС

У меня есть форма, которая принимает список значений, каждое из которых указано в отдельной строке textArea. В моем сервлете я токенизирую строку, которую получаю из этого textArea, на основе символов новой строки "\r\n", например:

String[] partNumberList = originalPartNumberString.split("\r\n");

Кажется, это работает нормально. Я получаю массив значений, как и ожидалось. Я считаю, что это связано с тем, что браузер обрабатывает стандартизацию способа отправки новых строк на сервер, независимо от того, из какой ОС/браузера отправляются данные формы (см. этот пост). Я тестировал в IE, Firefox, Chrome... все работает нормально, и я в этом уверен.

После получения значений на стороне сервера я затем использую эти значения для некоторых поисков и т. д., а затем записываю их обратно в textArea для ответа. Для этого я пишу его так же, как и получаю... Я просто создаю новую строку и разделяю каждое значение "\r\n". Затем я устанавливаю значение textArea для этой строки.

StringBuffer invalidReturnPartList = new StringBuffer("");

for (int i = 0; i < requestedPartList.length; i++)
{
    invalidReturnPartList.append(requestedPartList[i]);
    invalidReturnPartList.append("\r\n");
}

return invalidReturnPartList.toString();

Это также дает мне хорошие результаты во всех браузерах, которые я пробовал. Тем не менее, я просто нервничаю из-за того, освещаю ли я здесь все свои основы ... если кто-то работает на Mac, будет ли «\ r \ n» правильно переводиться в их браузере? Что насчет линукса? Я бы подумал, что все будет обрабатываться в браузере, но я просто не уверен здесь... поэтому мой вопрос: это выглядит правильно для вас или я что-то пропустил?


java browser newline
person JasonStoltz    schedule 03.06.2009    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Я попытаюсь ответить на свой вопрос здесь.

Поскольку значения textArea являются данными формы, а форма отправляется на сервер с типом содержимого «application/x-www-form-urlencoded», новые строки преобразуются браузером в «CR LF» перед отправкой на сервер. сервер в соответствии со спецификацией HTML (см. http://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.2.1).

Так что в этом случае мой код должен работать стабильно, независимо от браузера или ОС.

Однако, если бы я пытался реализовать тот же код на стороне клиента (скажем, с помощью JavaScript), возможно, для проверки формы перед отправкой... это может быть другая история. Поскольку данные формы на данный момент не канонизированы, они, скорее всего, зависят от того, что платформа/браузер использует для новых строк. В этом случае мне, вероятно, нужно будет проверить не только "\r\n", но и "\r" и "\n".

person JasonStoltz    schedule 03.06.2009

arrow_upward
2
arrow_downward

Если вы посмотрите определение протокола HTTP, вы обнаружите, что:

HTTP/1.1 определяет последовательность CR LF как маркер конца строки для всех
элементов протокола, кроме тела объекта (см. приложение 19.3 для устойчивых
приложений). Маркер конца строки в теле объекта определяется связанным с ним типом носителя, как описано в разделе 3.7.

Но это не относится к телу. Я предполагаю, что вы отправляете информацию формы с почтовым запросом, поэтому я предполагаю, что используется тип содержимого text/plain, и в этом случае я думаю, что применимо следующее:

3.7.1 Канонизация и текстовые значения по умолчанию

Типы интернет-медиа регистрируются в канонической форме. Тело объекта
, передаваемое через HTTP-сообщения, ДОЛЖНО быть представлено
в соответствующей канонической форме перед его передачей, за исключением "текстовых" типов, как определено в следующем абзаце.

В канонической форме подтипы мультимедиа типа «текст» используют CRLF в качестве разрыва строки текста. HTTP ослабляет это требование и позволяет передавать текстовые мультимедиа только с простыми CR или LF, представляющими разрыв строки, когда это делается последовательно для всего тела объекта. Приложения HTTP ДОЛЖНЫ принимать CRLF, чистый CR и чистый LF как представление разрыва строки в текстовом медиа, полученном через HTTP.

Это означает, что браузер может отправлять вам конечные строки в стиле UNIX.

(Оба абзаца взяты с сайта http://www.ietf.org/rfc/rfc2616.txt)

person chris166    schedule 03.06.2009
comment
Я вижу вашу точку зрения. Однако я думаю, что когда форма отправляется, она отправляется с типом контента application/x-www-form-urlencoded. Этот пост(stackoverflow .com/questions/760282/) ссылается на документ (w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.2.1), что, по-видимому, подразумевает, что разрывы строк всегда заменяются на CR LF при отправке формы вместе с application/ x-www-form-urlencoded тип содержимого ... Разрывы строк, как и в значениях многострочного текстового поля, представлены парами CR LF, т. е. `%0D%0A'. - person JasonStoltz; 03.06.2009
comment
Да, ты прав. Я думал, что тип контента также начинается с text/* . Ну, тогда ваш код должен работать;) - person chris166; 03.06.2009
comment
Этот пост старый, но все же я хотел отдать вам должное ... Я только что проголосовал за этот ответ. В конце концов я ответил на свой вопрос, но без этого ответа я не мог бы направить меня на правильный путь. - person JasonStoltz; 07.10.2010