JMeter CSV Data Set beschädigt japanische Strings als richtige UTF-8 gespeichert, bekomme ich stattdessen Fragezeichen

Question

Ich lese in Suchbegriffe aus einer einfachen Textdatei an eine Suchmaschine zu senden. Es funktioniert gut in Englisch, aber gibt mir ???? für jeden japanischen Text. Text mit gemischtem Englisch und Japanisch zeigt den englischen Text, also weiß ich, dass er es liest.

Was ich sehe:

• Eingabetext: Snow Leopard を イ ン ス ト ー ル す る 場合, 新 し い
• verwandelt sich in: Snow Leopard ????????????? ??

Dies ist in meinem POST-Feld eines HTTP. Wenn ich JMeter auf die Codierung der Daten einstelle, wird nur die Prozentfolge für Fragezeichen eingefügt.

über die Daten:

• Die CSV-Datei in Struktur sehr einfach ist.
• Es gibt nur ein Feld/eine Spalte, die ich TERM nennen, und die spätere Verwendung als $ {TERM}
• ich wirklich nicht voll CSV brauchen, weil es nur eine Saite pro Zeile.
• Es gibt keine Kommas oder Anführungszeichen.
• Es ist UTF-8 und wenn ich den Unix-Befehl "Datei" für die Datei ausführen, wird UTF-8-Text angezeigt.
• Ich habe UTF-8 auch in der Befehlszeile und im Grafikmodus auf zwei Rechnern verifiziert.

Interessante Anmerkung: Ein interessanter Zufall, dass ich bemerkt: wenn gibt es 15 japanische Zeichen dann bekomme ich 15 Fragezeichen, so an einem gewissen Punkt wird es als Voll Zeichen gesehen zu werden und nicht nur die Bytes.

JMeter CSV Datensatz Config:

• Dateiname: Japanisch-searches.csv
• Datei-Codierung: UTF-8 (auch versucht ohne)
• Variablennamen: TERM
• Delimiter:,
• Zulässige Daten zulassen: Falsch (Ich habe auch versucht True, anders, aber immer noch falsch)
• Recycle bei EOF: True
• Stopp bei EOF: False
• Staring-Modus: Alle Themen

Ein paar Dinge, die ich versucht habe: - Versuchte können Daten zitiert. Es änderte sich zu anderen seltsamen Charakteren. - Added -Dfile.encoding = UTF-8 - Versuchte Codierung der POST Bühne, aber es nur in einen Haufen von% nn für Fragezeichen gedreht

Und ich bin nicht sicher, wie „debug“ kurz nach der jeweils Linie der CSV wird eingelesen. I denke es ist sofort beschädigt, aber ich bin mir nicht sicher.

Wenn es nur gemangelt wird, wenn ich es referenziere, dann gibt es vielleicht anstelle von $ {TERM} einen anderen "to Bytes" Funktionsaufruf. Ich werde mich darum kümmern. Ich habe mit den JMeter-Funktionen noch nichts gemacht.

Edited 24. Dezember:

Tweaks:

• Geänderte Formatierung und hinzugefügt Kugel Punkte für mehr Klarheit.
• Klargestellt, dass die Datei UTF-8 ist, und das überprüft haben.

Eine neue Theorie:

• Ist es möglich, dass die japanischen Schriftzeichen es durch machen, und das Problem ist, dass jeder einzelne Ort, der sie sie zu einem zeigt Karten „?“ nur bei DISPLAY TIME. Also, obwohl ich ein paar Orte eingecheckt habe, haben alle ein Display-Problem nur in der Benutzeroberfläche?
• Gibt es in JMeter eine Möglichkeit, den numerischen Wert eines Zeichens oder einer Zeichenfolge zu sehen? Um JMeter mitzuteilen, die Liste der Unicode-Codepunkte anzuzeigen?
• Ich schaue mir meine letzten Protokolldateien an ... obwohl ich vermute, dass sogar die Serverprotokolle die Zeichen falsch zuordnen konnten.
• Vielleicht auch, wenn Variable Erweiterung innerhalb des Textfelds, das ich POST, wo ich die $ {TERM} verweisen, vielleicht bei , dass es auch auf Fragezeichen zugeordnet, aber dass die Korruption zu diesem späteren Zeitpunkt passiert . Wenn dies passiert ist UND in der Benutzeroberfläche falsch angezeigt wurde, kann dies zu einer falschen Schlussfolgerung führen.
• Was ich wirklich gerne tun würde, ist JMeter nach dem ersten CSV-Datensatz anzuhalten, kurz nachdem diese Zeile geladen wurde, und es mit einem "Data Scope" oder Byte-Editor oder etwas zu betrachten. Ich bin mir nicht sicher, ob das möglich ist.

Answer 1

Gefunden das Problem, es gab einen anderen Ort der UTF-8 angegeben werden musste.

In dem HTTP-Request, rechts von der Methode, müssen Sie auch Content-Codierung auf UTF-8

Ja, im Nachhinein festgelegt, dies scheint offensichtlich, aber es gab eine Reihe von Gründen, die ich didn‘ Ich glaube, das war nötig. Einige meiner falschen Annahmen könnten hilfreich für andere sein, die debuggen, also hier - ich hätte gedacht:

1: Sobald Text in Java als Unicode gemacht hat, bleibt es als Unicode, und geht ein- und aus von UTF-8. Offensichtlich nicht in diesem Fall.

2: Ich dachte, HTTP würde auf UTF-8 voreingestellt, wenn Sie nicht anders sagen, aber vielleicht bin ich nur an XML gewöhnt, aber wahrscheinlich keine gute Praxis, und vielleicht HTTP Standardeinstellungen ISO-Latin1 oder etwas, oder selbst wenn es eine Spezifikation gibt, folgen vielleicht die Leute nicht.

3: Und wenn ich es nicht spezifiziere, würde ich denken, dass der "do no harm" -Ansatz wäre, die Zeichen weiterzugeben und den Empfänger am anderen Ende damit beschäftigen zu lassen. Wieder falsch!

(OK, so Punkte 1, 2 und 3 überlappt ein wenig)

4: Auch wenn mein HTTP-Request-POST, ich habe immer noch das Encode Checkbox versuchen.Ich dachte natürlich, dass es das verschlüsselt hätte, aber alles, was ich bekam, war das wiederholte% hex für Fragezeichen, daher schien mir, dass die Daten zu diesem Zeitpunkt bereits beschädigt waren. Wieder falsch. Ich vermute, INNERHALB der HTTP-Phase gibt es ZWEI Zeichenübergänge, zuerst von Unicode zu jeder Kodierung, die es zu haben glaubt, und DANN eine zweite Kodierung zu den% -Zeichen, und meine Daten wurden im ersten Schritt falsch kodiert.

5: Und ich hätte gedacht, JMeter würde etwas sagen oder warnen, aber nach meiner Lektüre ist es anscheinend in dieser Hinsicht nicht hilfreich. Sie können Logging oder was auch immer tun.

Und das "?" ist die Art und Weise, wie Java ein Problem meldet Standardmäßig begann dies im Java 1.4x-Zeitrahmen. In meinem Java-Code bevorzuge ich das Festlegen von Codierungsfehlern, die als Ausnahme gemeldet werden, aber wiederum nicht die Standardeinstellung und nicht das, was JMeter tut.

Also habe ich meine Lektion gelernt.

Der TIPP, dass der Unicode zumindest von Anfang an OK war, war, dass die Anzahl der Fragezeichen der Anzahl der japanischen Zeichen entsprach, anstatt 2 oder 3 Mal so viele Fragezeichen zu haben. Wenn die Länge von "???" entspricht Ihrer japanischen (oder chinesischen) Zeichenkette, dann wird Java DID an einem bestimmten Punkt der Reise tatsächliche Unicode-Zeichen anzeigen. Während, wenn Sie sehen 3 mal so viele wie Eingabetext, dann sah Java immer sie als Bytes oder Ints oder was auch immer, und nie als gültige Codepoints.

Answer 2

Sie können versuchen, "SHIFT-JIS" in Inhaltscodierung (es ist in der Nähe von Methode Auswahl) zu verwenden. Dann sollten Sie "Encode" deaktivieren für Parameter, die Japanisch enthalten.

Hoffe es funktioniert dich.

Answer 3

Ist bei der Suche nach einer Lösung zu diesem Thema gekommen, um Parameter aus der csv-Datei zu verwenden, die einige in Hebräisch geschriebene Spalten enthielten.

1. Ich habe Excel 2007 verwendet, um 1000 Zeilen Daten für Benutzerregistrierungen zu erstellen. Der erste und der letzte Name mussten auf Hebräisch sein. Ich habe die Datei in "Unicode-Text" -Datei exportiert. Es wurde tabulatorgetrennt. "Unicode Text" speichert in UTF-16 LE (Little Endian), nicht in UTF-8. Das ist wichtig.

2. Ich habe das Ergebnis in Notepad ++ geöffnet. Ich konnte die hebräischen Buchstaben richtig sehen. Der Notepad ++ hat den Menüpunkt "Encoding", wo Sie die Kodierung überprüfen oder ändern können. Also habe ich den Little Endian zu UTF-8 geändert. Dann ersetzte ich Tabs mit Komma (nur der Registerkarte ausgewählt und eingefügt in das Suchfeld

3. Die Parameter ok wurden ersetzt, aber nach dem Ausführen des Skripts sah ich folgendes:. In der „Ansicht Ergebnisse Baum“ Hörer Ich öffnete die Registerkarte "Ergebnis" der "HTTP-Anfrage". Die Parameter wurden ersetzt, aber die HTTP-Ansicht Registerkarte (auf der Unterseite) der Anfrage zeigte mir etwas Kauderwelsch. Aber wenn ich auf die Raw-Ansicht schaute, sah ich dass die Anfrageparameter tatsächlich Zeichenketten wie% D7% A9% D7% A8% D7% 9E% D7% 95% D7% 98% D7% 94 enthielten, die paarweise (% D7% A9) korrekt in hebräische Buchstaben entkorrelierten.

In meinen Augen hat der JMeter einen Fehler und kann die Unicode-Zeichen nicht korrekt anzeigen. Aber es sendet (POSTs) sie in Ordnung.

Hoffe ich bin richtig und hoffe, es wird jemandem helfen.