What is the default Content Encoding for jmeter HTTP Request sampler? - jmeter

I am looking at the Content Encoding field in the HTTP Request sampler. Don't confuse this with the HTTP Content-Type header.
By default the value in the Content Encoding field is empty. What does empty mean? What is the default content encoding for jmeter HTTPRequest? Is it ASCII or ANSI or UTF-8?
This guide only mentions that it is not a required field.

Dmitri's answer points to code related to encoding of query strings, but this led me to looking at the code of PostWriter class which creates the actual body of the request - and if sampler does not provide a content encoding - ISO-8859-1 is used for encoding of the body:
public static final String ENCODING = StandardCharsets.ISO_8859_1.name();
...
String contentEncoding = sampler.getContentEncoding();
if(contentEncoding == null || contentEncoding.length() == 0) {
contentEncoding = ENCODING;
}

To point out why I downvoted the reply above (Dmitri T's answer):
I had issues with spanish accents and characters, and I spent hours trying to figure it out, assuming the above answers: that leaving it blank is equivalent to UTF-8. After specifically setting it to UTF-8, no more spanish characters issues.
SO, DO NOT LEAVE BLANK IF YOU NEED UTF-8.

As per JMeter 5.2
Looking into HTTPSamplerBase.java:1136
// Check if the sampler has a specified content encoding
if (JOrphanUtils.isBlank(lContentEncoding)) {
// We use the encoding which should be used according to the HTTP spec, which is UTF-8
lContentEncoding = EncoderCache.URL_ARGUMENT_ENCODING;
}
Looking into EncoderCache:31
/** The encoding which should be usd for URLs, according to HTTP specification */
public static final String URL_ARGUMENT_ENCODING = StandardCharsets.UTF_8.name();
So leaving the field blank is equal to setting it to UTF-8

Related

How to make Get Request with Request param in Postman

I have created an endpoint that accepts a string in its request param
#GetMapping(value = "/validate")
private void validateExpression(#RequestParam(value = "expression") String expression) {
System.out.println(expression);
// code to validate the input string
}
While sending the request from postman as
https://localhost:8443/validate?expression=Y07607=Curr_month:Y07606/Curr_month:Y07608
// lets say this is a valid input
console displays as
Y07607=Curr_month:Y07606/Curr_month:Y07608 Valid
But when i send
https://localhost:8443/validate?expression=Y07607=Curr_month:Y07606+Curr_month:Y07608
//which is also an valid input
console displays as
Y07607=Curr_month:Y07606 Curr_month:Y07608 Invalid
I am not understanding why "+" is not accepted as parameter.
"+" just vanishes till it reaches the api! Why?
I suggest to add this regular expression to your code to handle '+' char :
#GetMapping(value = "/validate")
private void validateExpression(#RequestParam(value = "expression:.+") String expression) {
System.out.println(expression);
// code to validate the input string
}
I didn't find any solution but the reason is because + is a special character in a URL escape for spaces. Thats why it is replacing + with a " " i.e. a space.
So apparently I have to encode it from my front-end
Its wise to encode special characters in a URL. Characters like \ or :, etc.
For + the format or value is %2. You can read more about URL encoding here. This is actually the preferred method because these special characters can sometimes cause unintended events to occur, like / or = which can mean something else in the URL.
And you need not worry about manually decoding it in the backend or server because it is automatically decoded, in most cases and frameworks. In your case, I assume you are using Spring Boot, so you don't need to worry about decoding.

PDF does not use utf-8 string encoding like Go

I am working with libray (https://github.com/unidoc/unipdf) for Go to process PDF files. By using 'SetReason' method I try to set reason of signing of my pdf file.
func (_aggg *PdfSignature )SetReason (reason string ){_aggg .Reason =_gb .MakeString (reason )};
This leads to cyrillic text become unclear symbols (as shown in the picture).
unclear cyricclic symbols
original text is: "русский > Request Id = 12, Task Id = 145"
And it is all ok with cyrillic symbols in main content of PDF file. The problem is in 'Signs'('Подписи') part (as shown in the picture).
In the library there is a mention: (see 'NOTE')
// MakeString creates an PdfObjectString from a string.
// NOTE: **PDF does not use utf-8 string encoding like Go so `s` will often not be a utf-8 encoded
// string.**
func MakeString(s string) *PdfObjectString { _aaad := PdfObjectString{_gcae: s}; return &_aaad }
I want to my pdf file's 'reason' become readable cyrillic symbols,
so, is there any solutions for this ? Hope, I explained the problem ...
It should work if you use core.MakeEncodedString
https://apidocs.unidoc.io/unipdf/latest/github.com/unidoc/unipdf/v3/core/#MakeEncodedString
signature.Reason = core.MakeEncodedString("русский > Request Id = 12, Task Id = 145", true)
func MakeEncodedString(s string, utf16BE bool) *PdfObjectString
MakeEncodedString creates a PdfObjectString with encoded content, which can be either UTF-16BE or PDFDocEncoding depending on whether utf16BE is true or false respectively.
This will store the reason in UTF-16BE which is appropriate for this text.
Disclosure: I am the original developer of UniPDF.

How to remove the characters �� from the JSON response using Jmeter?

Below is the JSON Response from the Server, How to remove the characters �� from the below Response using Jmeter
Response :
{"_id":"5d56cc5c31acfd001298e863","test_id":"5d56cc593801370012bdb2bb","display_order":"1","question_type":"MULTIPLE CHOICE","isbn":"9780393630749","status":"added","question":{"_id":"5d56cc5c31acfd001298e864","questionId":"5d4262bb56c1d800122fcb48","QuestionTitle":{"key":"","value":"","valueRTF":"","valueHtml":"��������\n
I have written the groovy Script. but it is not removing the char.
def response = prev.getResponseDataAsString();
def var1= response.replaceAll("\�", "");
and I need to use this Var1 in another request.
Most probably you're seeing these question marks due to encoding problems, try setting file.encoding property to UTF-8 in system.properties file and restart JMeter, most probably you will see normal text instead of the question marks.
If for some reason the above hint is not applicable I would recommend replacing the whole valueHtml attribute value using JsonBuilder, the relevant code would be something like:
def builder = new groovy.json.JsonBuilder(new groovy.json.JsonSlurper().parse(prev.getResponseData()))
builder.content.question.QuestionTitle.valueHtml = ''
vars.put('Var1', builder.toPrettyString())
As the result you will have the same JSON structure with empty valueHtml attribute.
More information:
Groovy: Parsing and producing JSON
Apache Groovy - Why and How You Should Use It
As it is a JSON Response, add JSON Extractor Post Processor to the Parent Sampler from where the Response is expected. Extract whole JSON with following settings:
Now, use a JSR223 Sampler, with following code in script area:
String var1 = vars.get("jsonOutput");
log.info("Output: " + var1);
String replaceString=var1.replace('?','-'); // replace with whatever you want to, I am replacing it with '-'
log.info("Output: " + replaceString);
vars.put("NewString", replaceString);
Afterwards, you can use ${NewString} wherever you want.

How to return localized content from WebAPI? Strings work but not numbers

Given this ApiController:
public string TestString() {
return "The value is: " + 1.23;
}
public double TestDouble() {
return 1.23;
}
With the browser's language set to "fr-FR", the following happens:
/apiController/TestString yields
<string xmlns="http://schemas.microsoft.com/2003/10/Serialization/">The value is: 1,23</string>
/apiController/TestDouble yields
<double xmlns="http://schemas.microsoft.com/2003/10/Serialization/">1.23</double>
I would expect TestDouble() to yield 1,23 in the XML. Can anyone explain why this isn't the case and, more importantly, how to make it so that it does?
It is because the conversion from double to string happens at different stage for each API. For the TestString API, double.ToString() is used to convert the number to a string using CurrentCulture of the current thread and it happens when the TestString method is called. Meanwhile, the double number which is returned by TestDouble is serialized to string during the serialization step which uses GlobalConfiguration.Configuration.Formatters.JsonFormatter.SerializerSettings.Culture.
In my opinion, both should use InvariantCulture. On the consumer side, the values will be parsed and be formatted with the correct culture.
Update: this is only used for JsonFormatter. XmlFormatter doesn't have such a setting.
Update 2:
It seems (decimal) numbers need special converter to make it culture-aware:
Handling decimal values in Newtonsoft.Json
Btw, if you want o change data format per action/request, you can try the last piece of code of the following link: http://tostring.it/2012/07/18/customize-json-result-in-web-api/

Code Igniter Form Validation Min Max Length count of unicode characters?

Curious if anyone knows if codeigniter's form validation built in max_length[n] and min_length[n] functions count unicode characters as 1 character or the sum of all the characters used symbolize the unicode character?
I noticed when I var_dump the string it counts all the characters, just wondering if code igniter or php has a built in function to count unicode characters?
Thanks.
You can make your own callback validation:
$this->form_validation->set_rules('rule', 'The rule', 'callback_checkUnicode');
And the check the unicode string>
public function checkUnicode($string)
{
if (strlen($string) != strlen(utf8_decode($string)))
{
//is unicode: add your own counter condition here
return true;
}
return false
}
Codeigniter uses php's mb_strlen if it's available on your php installation which allows for an encoding parameter to be passed along, otherwise it defaults to php's basic strlength which doesn't allow you to pass the string encoding along. The trouble is that CI doesn't give you the ability to pass along the possible encoding for max_length[n]...
If you need it to compensate for the encoding, you might be better served rolling your own validation with just raw php.

Resources