I'm using aws-sdk-for-php and using AmazonSES for sending email.
The problem is I want to set the name for the email. Example:
指定 < email_address >
Here my source code:
$mailer = new \AmazonSES( $aws_config ); $response = $mailer->send_email($mail_data['from'],$mail_data['to']);
I believe the format you're looking for is as follows:
"John Doe" <johndoe#example.com>
Reference: http://docs.aws.amazon.com/ses/latest/DeveloperGuide/email-format.html
I have resolved the same issue after checking this aws forum link .
I was using aws SES for sending mails using java sdk , so I have added the from email id in the application.yml file like below.
from: John Doe <johndoe#example.com>
SES doesn't support Japanese characters by default, so you have to encode from name with iso-2022-jp encoding.
below is sample in python.
from email.header import Header
import os
FROM_ADDRESS = os.environ.get('FROM_ADDRESS')
FROM_NAME = os.environ.get('FROM_NAME')
...
from_address = '{} <{}>'.format(Header(FROM_NAME.encode('iso-2022-jp'),'iso-2022-jp').encode(), FROM_ADDRESS)
Short answer:
You have to send the name encoded with MIME encoded-word syntax.
"指定 <johndoe#example.com>" would be "=?utf-8?B?5oyH5a6a?= <johndoe#example.com>"
Long Answer:
Althoug #dezinezync answer is correct, it only works for non-ASCII characters so if you want to set a friendly name as "指定" or any other (my problem was with spanish/latin characters "á, é, í, ó, ú" showing the symbol � instead) you have to encode the string.
Acording to amazonSES javascript SDK Docs
The sender name (also known as the friendly name) may contain
non-ASCII characters. These characters must be encoded using MIME
encoded-word syntax, as described in RFC 2047. MIME encoded-word
syntax uses the following form: =?charset?encoding?encoded-text?=.
So using utf-8 and base64 encoding you will be able to set the name you need.
Encoding 指定 to base64 will give you this string 5oyH5a6a and based on the RFC 2047 MIME encoded-word-syntax you have to replace the encode-text in the form:
=?charset?encoding?encoded-text?= <email#domain.com>
Resulting:
=?utf-8?B?5oyH5a6a?= <email#domain.com>
Where =? marks the begining and the end of the encoded string, utf-8 is the charset (which support japanese characters) and the B is the encoding, can be either "Q" (denoting Q-encoding) or "B" (denoting base64 encoding) and finally 5oyH5a6a the base64 string that represents 指定.
Thats it! :)
Here is code I found in php (haven't test it) that uses the Q-encoding:
<?php
$name = ""; // kanji
$mailbox = "kru";
$domain = "gtinn.mon";
$addr = mb_encode_mimeheader($name, "UTF-7", "Q") . " <" . $mailbox . "#" . $domain . ">";
echo $addr;
Here is the link of the code https://doc.bccnsoft.com/docs/php-docs-7-en/function.mb-encode-mimeheader.html
And other references:
https://nerderati.com/2017/06/09/mime-encoded-words-in-email-headers
https://knowledge.ondmarc.redsift.com/en/articles/2720905-multipurpose-internet-mail-extensions-mime#:~:text=The%20MIME%20encoded%2Dword%20syntax,the%20charset%20into%20ASCII%20characters.
Hope it helps!
I only changed the format and it is working fine for me.
"from": {
"name": "name",
"address": "email address"
}
Related
I call my service in wcf as you can see :
ClientRequest.Headers["Content-type"] = "application/json";
string result = ClientRequest.DownloadString(ServiceHostName + "/NajaService.svc/GetCarData/" + plaque);
var javascriptserializer = new JavaScriptSerializer();
return javascriptserializer.Deserialize<NajaResult>(result);
But the returned data is like this :
{"CarColor":"آبي سير","CarModel":"1383","CarTip":"ال ايکس","CarType":"سواري","Chassis":"83844131","Family":"####","FuelType":1,"MotorNum":"12483068683","Name":"####","NationalCode":"0000000000","Plaque":"11-426د61","PlaqueCoded":110561426,"PlaqueType":"","SystemType":"سمند","VinNo":"IRFC831V3GJ844131"}
I converted it to UTF8 byte and again convert it to utf8 string but not solved.
The encoded data is in Persian language .
I traced the request in fiddler and i found that the data is come with the correct format as you can see ,But in my code is changed
The WebRequest contains the Encoding property you can set up before downloading the service reply. Details are here: https://msdn.microsoft.com/en-us/library/system.net.webclient.encoding(v=vs.110).aspx
I'm trying to encode a file to Base64 in Jmeter to test a web service using the following script:
String file = FileUtils.readFileToString(new File("${filepath}"), "UTF-8");
vars.put("file", new String(Base64.encodeBase64(file.getBytes("UTF-8"))));
This works fine for plain/text files and does not work for other file types correctly.
How could I make it work for other file types?
Jmeter has many potions to convert a variable to "Base64", below are a few options
Bean shell pre processor
BeanShell PostProcessor
BeanShell Sampler.
Below is the "bean shell" code, which used in "Bean shell pre processor" to convert variable to Base64
import org.apache.commons.codec.binary.Base64;
String emailIs= vars.get("session");
byte[] encryptedUid = Base64.encodeBase64(emailIs.getBytes());
vars.put("genStringValue",new String(encryptedUid));
Example :
Before Base64 :jdwqoeendwqqm12sdw
After Base64 :amR3cW9lZW5kd3FxbTEyc2R3
Converted using Jmeter :
Converted Using base64 site:
As Groovy is now the preferred JSR223 script language in each JMeter Sampler, Pre- & PostProcessor, Listener, Assertion, etc. this task is pretty easy.
def fileAsBase64 = new File("${filepath}").bytes.encodeBase64().toString()
vars.put("file", fileAsBase64)
Or as one liner:
vars.put("file", new File("${filepath}").bytes.encodeBase64().toString())
That's it.
Use the function ${__base64Encode(nameofthestring)} to encode the string value and ${__base64Decode(nameofthestring)} to decode the string value.
Your issue comes from the fact that you're considering binary files as text when reading them which is wrong.
Use this for reading the file:
https://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/FileUtils.html#readFileToByteArray(java.io.File)
Then encode the byte array in Base64
Try this
import org.apache.commons.codec.binary.Base64;
String forEncoding = vars.get("userName") + ":" + vars.get("passWord");
byte[] token = Base64.encodeBase64(forEncoding.getBytes());
vars.put("token", new String(token));
Alternative for this is to directly create a groovy function in User Defined Variable as
${__groovy(new File(vars.get("filepath")).bytes.encodeBase64().toString(),)}
URL = http://example.com,
Header = [],
Type = "application/json",
Content = "我是中文",
Body = lists:concat(["{\"type\":\"0\",\"result\":[{\"url\":\"test.cn\",\"content\":\"", unicode:characters_to_list(Content), "\"}]}"]),
lager:debug("URL:~p, Body:~p~n", [URL, Body]),
HTTPOptions = [],
Options = [],
Response = httpc:request(post, {URL, Header, Type, Body}, HTTPOptions, Options),
The http request body received by http server is not 我是中文。How do I fix this issue?
Luck of the Encoding
You must take special care to ensure input is what you think it is because it may differ from what you expect.
This answer applies to the Erlang release that I'm running which is R16B03-1. I'll try to get all of the details in here so you can test with your own install and verify.
If you don't take specific action to change it, a string will be interpreted as follows:
In the Terminal (OS X 10.9.2)
TerminalContent = "我是中文",
TerminalContent = [25105,26159,20013,25991].
In the terminal the string is interpreted as a list of unicode characters.
In a Module
BytewiseContent = "我是中文",
BytewiseContent = [230,136,145,230,152,175,228,184,173,230,150,135].
In a module, the default encoding is latin1 and strings containing unicode characters are interpreted bytewise lists (of UTF8 bytes).
If you use data encoded like BytewiseContent, unicode:characters_to_list/1 will double-encode the Chinese characters and ææ¯ä will be sent to the server where you expected 我是中文.
Solution
Specify the encoding for each source file and term file.
If you run an erl command line, ensure it is setup to use unicode.
If you read data from files, translate the bytes from the bytewise encoding to unicode before processing (this goes for binary data acquired using httpc:request/N as well).
If you embed unicode characters in your module, ensure that you indicate as much by commenting within the first two lines of your module:
%% -*- coding: utf-8 -*-
This will change the way the module interprets the string such that:
UnicodeContent = "我是中文",
UnicodeContent = [25105,26159,20013,25991].
Once you have ensured that you are concatenating characters and not bytes, the concatenation is safe. Don't use unicode:characters_to_list/1 to convert your string/list until the whole thing has been built up.
Example Code
The following function works as expected when given a Url and a list of unicode character Content:
http_post_content(Url, Content) ->
ContentType = "application/json",
%% Concat the list of (character) lists
Body = lists:concat(["{\"content\":\"", Content, "\"}"]),
%% Explicitly encode to UTF8 before sending
UnicodeBin = unicode:characters_to_binary(Body),
httpc:request(post,
{
Url,
[], % HTTP headers
ContentType, % content-type
UnicodeBin % the body as binary (UTF8)
},
[], % HTTP Options
[{body_format,binary}] % indicate the body is already binary
).
To verify results I wrote the following HTTP server using node.js and express. The sole purpose of this dead-simple server is to sanity check the problem and solution.
var express = require('express'),
bodyParser = require('body-parser'),
util = require('util');
var app = express();
app.use(bodyParser());
app.get('/', function(req, res){
res.send('You probably want to perform an HTTP POST');
});
app.post('/', function(req, res){
util.log("body: "+util.inspect(req.body, false, 99));
res.json(req.body);
});
app.listen(3000);
Gist
Verifying
Again in Erlang, the following function will check to ensure that the HTTP response contains the echoed JSON, and ensures the exact unicode characters were returned.
verify_response({ok, {{_, 200, _}, _, Response}}, SentContent) ->
%% use jiffy to decode the JSON response
{Props} = jiffy:decode(Response),
%% pull out the "content" property value
ContentBin = proplists:get_value(<<"content">>, Props),
%% convert the binary value to unicode characters,
%% it should equal what we sent.
case unicode:characters_to_list(ContentBin) of
SentContent -> ok;
Other ->
{error, [
{expected, SentContent},
{received, Other}
]}
end;
verify_response(Unexpected, _) ->
{error, {http_request_failed, Unexpected}}.
The complete example.erl module is posted in a Gist.
Once you've got the example module compiled and an echo server running you'll want to run something like this in an Erlang shell:
inets:start().
Url = example:url().
Content = example:content().
Response = example:http_post_content(Url, Content).
If you've got jiffy set up you can also verify the content made the round trip:
example:verify_response(Response, Content).
You should now be able to confirm round-trip encoding of any unicode content.
Translating Between Encodings
While I explained the encodings above you will have noticed that TerminalContent, BytewiseContent, and UnicodeContent are all lists of integers. You should endeavor to code in a manner that allows you to be certain what you have in hand.
The oddball encoding is bytewise which may turn up when working with modules that are not "unicode aware". Erlang's guidance on working with unicode mentions this near the bottom under the heading Lists of UTF-8 Bytes. To translate bytewise lists use:
%% from http://www.erlang.org/doc/apps/stdlib/unicode_usage.html
utf8_list_to_string(StrangeList) ->
unicode:characters_to_list(list_to_binary(StrangeList)).
My Setup
As far as I know, I don't have local settings that modify Erlang's behavior. My Erlang is R16B03-1 built and distributed by Erlang Solutions, my machine runs OS X 10.9.2.
I am at my wit's end on this one, I just can't find the right combination of code to make this work. I'm trying to create an authentication digest for an API query. I've tried many CFML functions (for example: Coldfusion HMAC-SHA1 encryption and HMAC SHA1 ColdFusion), but I'm not coming up with the same results that are cited in the API documentation. Here's that example (basically elements of the request header with line breaks as delimiters.):
application/xml\nTue, 30 Jun 2009 12:10:24 GMT\napi.summon.serialssolutions.com\n/2.0.0/search\ns.ff=ContentType,or,1,15&s.q=forest\n
and here's the key:
ed2ee2e0-65c1-11de-8a39-0800200c9a66
which according to the documentation should result in:
3a4+j0Wrrx6LF8X4iwOLDetVOu4=
when the HMAC hash is converted to Base64. Any ideas would be most appreciated!
The problem is your input string, not the functions. The first one works fine. Though I would change the charset to UTF-8, or make it an argument. Otherwise, the results are dependent on the jvm default, which may not always be correct, and can change which would break the code.
Verify you are constructing the sample string correctly. Are you using chr(10) for new lines? Note: It must also end with a new line.
Code:
<cfscript>
headers = [ "application/xml"
, "Tue, 30 Jun 2009 12:10:24 GMT"
, "api.summon.serialssolutions.com"
, "/2.0.0/search"
, "s.ff=ContentType,or,1,15&s.q=forest"
];
theText = arrayToList(headers, chr(10)) & chr(10);
theKey = "ed2ee2e0-65c1-11de-8a39-0800200c9a66";
theHash = binaryEncode( hmacEncrypt(theKey, theText), "base64");
writeDump(theHash);
</cfscript>
Result:
3a4+j0Wrrx6LF8X4iwOLDetVOu4=
Hi I have a web service built using the Zend Framework. One of the methods is intended to send details about an order. I ran into some encoding issue. One of the values being returned contains the following:
Jaime Torres Bodet #322-A Col. Lomas de Santa María
The webservice is returning the following fault:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>SOAP-ERROR: Encoding: string 'Jaime Torres Bodet #322-A Col. Lomas de Santa Mar\xc3...' is not a valid utf-8 string</faultstring>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
How should I go about this problem?
Thanks
Followup: Problem was due to a truncated string by the database. The field was set to VARCHAR(50) and it truncated exactly in the middle of the encoded value.
What about change the encoding settings:
SERVER:
$server = new SoapServer("some.wsdl", array('encoding'=>'ISO-8859-1')); // for 'windows-1252' too
CLIENT:
$server = new SoapClient("some.wsdl", array('encoding'=>'ISO-8859-1')); // for 'windows-1252' too
... then the conversion is done automatically to UTF-8, I had the similiar problem, so this helped me, so it is tested
Today I run into same problem - the code which caused that problem was:
$request->Text = substr($text, 0, 40);
changing substr to mb_substr seems to solve the issue:
$request->Test = mb_substr($text, 0, 40, 'utf8');
The problem is that í != i. Try to convert your string to UTF-8 before using in a request. It may look like that:
$string = iconv('windows-1252', 'UTF-8', $string);
See http://php.net/iconv
The answers above lead me to try:
// encode in UTF-8
$string = utf8_encode($string);
which also resolved the error for me.
Reference: utf8_encode()
I fixed a problem like this using mb_convert_encoding with array_walk_recursive to walk into my POST parameters, named $params (array).
Maybe this is useful for you:
array_walk_recursive($params,function (&$item){
$item = mb_convert_encoding($item, 'UTF-8');
});
I found out that in my case not the encoding of strings was the problem but that the file itself was not saved as UTF-8. Even explicit saving with UTF-8 encoding did not help.
For me it worked to insert a comment with an UTF-8 character like
// Å