The server-side PHP script accepts requests from clients in C ++ ... In the header there is a parameter Name: имя_пользователя , which becomes null when json_encode . If you look at the client's exe-file in notepad ++, it is in windows-1251 encoding (the parameters are appended to the end of the client and it reads itself to initialize the variables). Naturally json_encode requires utf-8. Attempts to convert to utf-8 on the server side using utf8_encode or mb_convert_encoding yielded something incomprehensible at the output, and not Russian text (although not null already). mb_detect_encoding when receiving this parameter returns UTF-8 although json_encode still writes null

How to get out of this situation? Is it possible to solve the problem in php or is it necessary to write a function of the type string_cp1251_to_string_utf8 for one single variable in the client?

  • On php did not do the encoding detection (on c # did). Do this, once null is returned, then try to apply 1251 encoding to the request. Or analyze the array of bytes of the request, for the presence of characteristic UTF-8 combinations - a large number of bytes D0 D1 C0 C1 for example - nick_n_a
  • Not quite clear? c ++ client sends some file? What file format? How is it passed to json_encode ()? - JustAnotherCoder
  • The client does not send a file, but a POST request with headers to the HTTP server. One of the headers is Name: client_name. The server parses the barrels, and delays json_encode (array ($ headers ['ID'] => $ Headers ['Name'])) ;. This Name comes out Null after json_encode, but the Exejpe sequence must be encoded with the Cyrillic string, which at echo json_decode should give the readable username - Iceman
  • @E_p, and if mb_detect_encoding on the server returns UTF-8, when cp1251 actually leaves the client, does iconv lead to a real UTF-8, which json_encode will accept? - Iceman

0