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

Question

У меня есть форма, которая принимает список значений, каждое из которых указано в отдельной строке 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" правильно транслироваться в их браузере? А как насчет Linux? Я бы подумал, что все будет обработано в браузере, но я просто не уверен, что здесь ... так что мой вопрос, это выглядит правильно для вас, или я что-то пропустил?

Answer 1

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

Поскольку значения 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».

Answer 2

Если вы посмотрите определение протокола 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)