Why windows-1251 from decodeURI?

Question

JavaScript

There is a link of the form: I extract the text from it and send it as an argument to the VK API method:<a href=link&p=любой_текст>

VK.api('method', {name:decodeURIComponent($(this)[0].href.match(/p=(.+)/)[1])}, function(r){
console.log(r);
});

so, if I pass one word in this way, for example "any", then everything works fine - the method is executed:

For any compound texts, such as "any_text", an error arrives. In the console, you can see that the text was not in UTF-8, but for some reason in cp-1251:
I tried:

1. change the encoding of all your files (I made sure that they are all UTF-8 without BOM);
   
2. put "charset=utf-8" in script, meta and .htaccess;
   
3. do not use decodeURIComponent, then the text comes in url format;
   
4. use decodeURI, String() and process text at different stages.
   

The result is still unsatisfactory. I write on the JS SDK, I connect files with content via ajax (once, then I work only inside the connected file).
Where is the dog buried?

Answer 1

Damn, I found where the jamb is: it was necessary to replace the underscore with a space, then the text for some reason remains in UTF-8 and the method works. Here's the "obvious" solution.
The final result is a regular expression:

decodeURIComponent($(this)[0].href.match(/p=(.+)/)[1].replace(/_/g, ' '));

Answer 2

Why such a hassle with pulling out of exile?
your site and links.
First, replace this $(this)[0].href.match(/p=(.+)/)[1])
with a normal data-* attribute, try it, and see how it goes.
what is the secret method of the open api?
what are the parameters?
why decodeURI if you pull from the link, and not from the address bar.
Errors are also incomprehensible.
See on the Network how the data goes there, everything should become clear.