I believe I found a (possible) issue when using app.utils.web.getURLContentAsync. I'm currently working on an plugin for the new autotag framework for vgmdb.net and noticed that lookups with
getURLContentAsync consistently fail if the URL contains certain japanese characters, e.g. 瀬 or 々. If I now run the following code:
Code: Select all
var headers = newStringList()
headers.add('User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36')
var requestURL = 'http://vgmdb.info/search/albums?format=json&q=瀬'
app.utils.web.getURLContentAsync(requestURL, {headers: headers}).then(function(Content) {console.log(Content)})
To rule out that the difference in results is not just the browser just handling the string differently or doing some other magic, I opened the powershell ISE and ran the following statement
Code: Select all
$response=Invoke-WebRequest -Uri "http://vgmdb.info/search/albums?format=json&q=瀬";$response.Content
Originally I thought that the server is just misinterpreting the provided URL for some reason or returning because I didn't provide any details about language, charset, etc., so I ran both functions in powershell and MM again and captured both sessions. Turns out, that the request sent to the server by MM already contained the wrong encoding:
Code: Select all
ps => GET /search/albums?format=json&q=%E7%80%AC
MM => GET /search/albums?format=json&q=%E7%C2?%AC
Code: Select all
var requestURL = encodeURI('http://vgmdb.info/search/albums?format=json&q=瀬')