Набор данных JMeter CSV повреждает японские строки, хранящиеся как правильный UTF-8, вместо этого я получаю вопросительные знаки

Я читаю условия поиска из простого текстового файла для отправки в поисковую систему. Он отлично работает на английском языке, но выдает мне ???? для любого японского текста. Текст со смешанным английским и японским языком действительно показывает английский текст, поэтому я знаю, что он его читает.

Что я вижу:

  • Входной текст: Snow Leopard をインストールする場合、新しい
  • Превращается в: Снежный барс ???????????????

Это в моем поле POST HTTP. Если я настрою JMeter для кодирования данных, он просто поставит процентную последовательность для вопросительных знаков.

О данных:

  • Файл CSV очень прост по структуре.
  • Есть только одно поле/один столбец, который я называю TERM, а позже использую как ${TERM}
  • Мне действительно не нужен полный CSV, потому что это только одна строка в строке.
  • Здесь нет запятых и кавычек.
  • Это UTF-8, и когда я запускаю команду Unix «файл» для файла, он говорит текст UTF-8.
  • Я также проверил UTF-8 в командной строке и графическом режиме на двух машинах.

Интересное примечание: интересное совпадение, которое я заметил: если есть 15 японских символов, то я получаю 15 вопросительных знаков, поэтому в какой-то момент это рассматривается как полные символы, а не просто байты.

Конфигурация набора данных JMeter CSV:

  • Имя файла: japanese-search.csv
  • Кодировка файла: UTF-8 (пробовал и без)
  • Имена переменных: ТЕРМИН
  • Разделитель: ,
  • Разрешить данные в кавычках: False (я также пробовал True, по-другому, но все равно неправильно)
  • Переработка в EOF: правда
  • Остановиться на EOF: False
  • Режим просмотра: все темы

Несколько вещей, которые я пробовал: - Пробовал Разрешить цитируемые данные. Он изменился на другие странные символы. - Добавлено -Dfile.encoding=UTF-8 - Пробовал кодировать этап POST, но он просто превратился в кучу %nn для вопросительных знаков

И я не уверен, как «отладить» сразу после того, как каждая строка CSV будет прочитана. Я думаю, что он сразу поврежден, но я не уверен.

Если он искажен только тогда, когда я на него ссылаюсь, то вместо ${TERM}, возможно, есть какой-то другой вызов функции "в байты". Я начну проверять это. Я еще ничего не делал с функциями JMeter.

Отредактировано 24 декабря:

Настройки:

  • Изменено форматирование и добавлены маркеры для большей ясности.
  • Уточнил, что файл в кодировке UTF-8, и проверил это.

Новая теория:

  • Возможно ли, что японские иероглифы доходят до конца, и проблема в том, что КАЖДОЕ ЕДИНСТВЕННОЕ место, где они показаны, сопоставляет их со знаком «?» только во ВРЕМЯ ОТОБРАЖЕНИЯ. Итак, хотя я проверил кучу мест, у всех у них проблема с отображением только в пользовательском интерфейсе?
  • Есть ли способ в JMeter увидеть числовое значение символа или строки? На самом деле, чтобы указать JMeter отображать список кодовых точек Unicode?
  • Я посмотрю свои последние файлы журналов... хотя я полагаю, что даже журналы сервера могут неправильно отображать символы.
  • Кроме того, возможно, при расширении переменной внутри текстового поля, которое я отправляю, где я ссылаюсь на ${TERM}, возможно, в этой точке она также отображается в вопросительные знаки, но в этом случае происходит повреждение более поздняя точка. Если это произошло И это было неправильно отображено в пользовательском интерфейсе, это может привести к ложному заключению.
  • Что я действительно хотел бы сделать, так это приостановить JMeter после первой записи CSV, сразу после загрузки этой строки, и посмотреть на нее с помощью «области данных» или редактора байтов или чего-то еще. Не уверен, что это возможно.

csv encoding utf-8 jmeter
person Mark Bennett    schedule 22.12.2010    source источник
comment
Я не думаю, что это очень ясно. Вы говорите, что читаете из текстового файла, но не упоминаете, в какой кодировке он находится или как он читается (например, код Java), и если да, то какой код он использует. Я думаю, что у вас больше шансов получить ответ, если вы не полагаетесь на то, что кто-то точно знает, как работает JMeter.   -  person PandaWood    schedule 23.12.2010
comment
Я упомянул UTF-8 и проверил это. Я отредактирую форматирование, может быть, больше пунктов. Также есть немного больше информации.   -  person Mark Bennett    schedule 24.12.2010
comment
Похоже на проблему с кодировкой. Эта статья может помочь: velocityreviews.com/forums/ иначе я бы разместил сообщение на форуме nabble: jmeter.512774. n5.nabble.com/JMeter-User-f512775.html   -  person BlackGaff    schedule 04.01.2011
comment
Вы пробовали цитировать текст И помещать японские символы в свой CSV в кавычки? После проведения исследований просто установите кодировку на UTC-8, и она должна работать.   -  person BlackGaff    schedule 04.01.2011
comment
Привет BlackGaff, спасибо за комментарии. У меня не было кавычек в файле, потому что в строке только одно поле и нет запятых, но я могу попробовать. Я искал на форуме JMeter, пока не нашел дымящегося пистолета. Я посмотрю на UTC-8. На данный момент я решил установить крошечный веб-сервер, который просто выводит шестнадцатеричные/восьмеричные коды того, что он отправляет, и я заставлю JMeter подчиняться этому. Я хочу доказать, так или иначе, действительно ли JMeter отправляет вопросительные знаки ИЛИ просто каждое место в пользовательском интерфейсе, где он пытается отобразить японский символ, неправильно отображает его НА ЭКРАНЕ.   -  person Mark Bennett    schedule 06.01.2011
comment
Привет БлэкГафф. Я попробовал предложенную вами кодировку UTC-8 вместо UTF-8, но тогда не появилось никаких записей, и вместо этого я получил ${TERM}. Я почти уверен, что UTC-8 — это часовой пояс, и если вы имели в виду UTF-8, я так и делал. Я также попытался поставить кавычки вокруг полей ввода, без изменений. И добавление дополнительных операторов отладки на стороне сервера, он получает только буквальные знаки вопроса?, а не Unicode. Я уже видел текст CJK в журналах сервера, так что сбой в JMeter.   -  person Mark Bennett    schedule 06.01.2011

Ответы (3)


arrow_upward
3
arrow_downward

Нашел проблему, было еще одно место, где нужно было указать UTF-8.

В HTTP-запросе справа от метода вы также должны установить кодировку содержимого в UTF-8.

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

1: После того, как текст попал в Java как Unicode, он остается как Unicode и входит и выходит с помощью UTF-8. Явно не в этом случае.

2: я как бы думал, что HTTP по умолчанию использует UTF-8, если вы не говорите иначе, но, может быть, я просто привык к XML, но, вероятно, это не очень хорошая практика, и, возможно, HTTP по умолчанию использует ISO-Latin1 или что-то в этом роде, или даже если есть спецификация, возможно, люди не следуют ей.

3: И если я не конкретизирую это, я думаю, что подход «не навреди» будет состоять в том, чтобы передать символы, и пусть получатель на другом конце разберется с этим. Опять неправильно!

(ОК, так что пункты 1, 2 и 3 немного перекрываются)

4: Несмотря на то, что мой HTTP-запрос POST, я все же попробовал установить флажок «Кодировать». Я, конечно, думал, что это закодировало бы его, но все, что я получил, это повторяющийся % hex для вопросительных знаков, поэтому мне казалось, что данные уже были повреждены в этот момент. Опять неправильно. Я подозреваю, что ВНУТРИ фазы HTTP есть ДВА перехода символов, сначала из Unicode в любую кодировку, которую, по его мнению, у вас есть, а ЗАТЕМ вторая кодировка в %signs, и мои данные были неправильно закодированы на первом шаге.

5: И я бы подумал, что JMeter что-то скажет или предупредит, но, судя по моему чтению, в этом отношении он явно бесполезен. Вы можете вести журнал или что-то еще.

А "?" - это способ сообщения о проблеме в Java ПО умолчанию, это началось во временном интервале Java 1.4x. В моем Java-коде я предпочитаю устанавливать сообщения об ошибках кодирования как исключения, но опять же, не по умолчанию и не то, что делает JMeter.

Так я усвоил урок.

ПОДСКАЗКА о том, что Unicode, по крайней мере, начинался нормально, заключалась в том, что количество вопросительных знаков равнялось количеству японских символов, а не в 2 или 3 раза больше вопросительных знаков. Если длина "???" соответствует вашей японской (или китайской) строке, тогда Java ДЕЙСТВИТЕЛЬНО увидит фактические символы Unicode в какой-то момент пути. Принимая во внимание, что если вы видите в 3 раза больше ?, чем входной текст, тогда Java всегда видит их как байты, целые числа или что-то еще, и НИКОГДА не как допустимые кодовые точки.

person Mark Bennett    schedule 05.01.2011
comment
Начиная с Java 1.4x, вы можете сказать Java, чтобы ВЫБИРАТЬ ИСКЛЮЧЕНИЯ, когда она сталкивается с ошибками кодирования, вместо того, чтобы просто молча заменять их вопросительными знаками. Это может быть слишком строгим для производственных приложений, но для отладки и ТЕСТИРОВАНИЯ я считаю это полезным. Хитрость заключается в объекте Charset, который вы используете: Charset charset Charset.forName( charsetName ); CharsetDecoder dec = charset.newDecoder(); dec.onMalformedInput(CodingErrorAction.REPORT); Затем будьте готовы обрабатывать исключения java.nio.charset.CharacterCodingException или подклассы: MalformedInputException и UnmappableCharacterException Очень строго! - person Mark Bennett; 06.01.2011
comment
И я также сделал -Dfile.encoding=UTF-8, поэтому я думал, что Java будет использовать это по умолчанию, если когда-либо будет неуверен. Но это также было неверно, по крайней мере, для этапа HTTP-конвейера JMeter. - person Mark Bennett; 06.01.2011

arrow_upward
3
arrow_downward

Наткнулся на эту тему при поиске решения для использования параметров из CSV-файла, содержащего некоторые столбцы, написанные на иврите.

  1. Я использовал Excel 2007 для создания 1000 строк данных для регистрации пользователей. Имя и фамилия должны быть на иврите. Я экспортировал файл в файл «Текст Unicode». Он стал разделителем табуляции. «Текст Unicode» сохраняется в UTF-16 LE (Little Endian), а не в UTF-8. Это важно.

  2. Я открыл результат в Notepad++. Я мог правильно видеть еврейские буквы. Notepad++ имеет пункт меню «Кодировка», где вы можете проверить кодировку или изменить ее. Поэтому я изменил Little Endian на UTF-8. Затем я заменил вкладки запятыми (просто выбрал вкладку и вставил ее в поле «Найти».

  3. Параметры подставлялись нормально, но после запуска скрипта я увидел следующее: В слушателе "Просмотр дерева результатов" я открыл вкладку "Результат" "Http Request". Параметры были заменены, но вкладка просмотра HTTP (внизу) запроса показала мне какую-то тарабарщину. Но когда я посмотрел на представление Raw, я увидел, что параметры запроса на самом деле содержат строки, такие как %D7%A9%D7%A8%D7%9E%D7%95%D7%98%D7%94, которые, взятые парами (% D7 %A9) правильно соответствует буквам иврита.

На мой взгляд, JMeter имеет ошибку и не может правильно отображать символы юникода. Но он отправляет (POST) их в порядке.

Надеюсь, что я прав, и надеюсь, что это поможет кому-то.

person Mike BCh    schedule 11.12.2012

arrow_upward
1
arrow_downward

Вы можете попробовать использовать «SHIFT-JIS» в кодировке контента (это рядом с выбором метода). Затем вы должны снять флажок «Кодировать?» для параметра, включающего японский язык.

Надеюсь, это сработает.

person Zen    schedule 22.10.2012