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

Question

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

То, что я вижу:

• Вводимый текст: Снежный барс op イ ン ス ト ー ル す る 場合 、100 し い
• Превращается в: Снежный барс ???????????????

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

О данных:

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

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

JMeter CSV Dataset Config:

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

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

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

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

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

Настройки:

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

В HTTP-запросе справа от Метода вы также должны установить Content Encoding на 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 в любую кодировку, которая, по его мнению, у вас есть, а затем вторую кодировку в знаки%, и мои данные были неправильно закодированы на первом шаге.

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

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

Поэтому я усвоил урок.

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

Answer 3

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

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