Mam bazę danych (MySql) hostowaną na serwerze Linux w chmurze. A moja aplikacja Java została wdrożona na tym samym serwerze. Mam dane w bazie danych, które wyświetlam w moim html.

Kiedy trafiam do API z aplikacji hostowanej na serwerze LINUX, otrzymuję niepotrzebne znaki jak (|���59���6���20������) w treści odpowiedzi.

A kiedy podłączam lokalną aplikację w intellij do tej samej bazy danych LINUX, otrzymuję właściwą odpowiedź z mojej aplikacji lokalnej w listonoszu (|毓59年6月20日缸). Moja odpowiedź faktycznie zawiera japoński charakter.

Co próbowałem?

  1. Zmień zestaw znaków w przeglądarce.
  2. Zakoduj ciąg znaków w java przy użyciu zestawu znaków UTF-8.

Zarówno odpowiedź z komputera lokalnego, jak i nagłówki odpowiedzi LINUX są takie same. Różni się tylko treść odpowiedzi. Nie mam pojęcia, jaki jest rzeczywisty problem.

Mój przykładowy kod znajduje się poniżej. Nie mogę tutaj zamieścić aktualnego kodu.

@Autowired
    private EncryptionService encryptionService;

    @Autowired
    private IdentifierRepository identifierRepository;

    private ApplicantRepository applicantRepository;

    @GetMapping("applicant/{applicantId}/identifier/{identifierId}")
    public ResponseEntity<Identifier> getIdentifier(@PathVariable long applicantId,@PathVariable long identifierId){
        Identifier identifier = identifierRepository.findIdentifierById(identifierId);
        identifier.setOcrResponse(encryptionService.decrypt(identifier.setOcrResponse()));
        return ResponseEntity.ok(identifier);
    }
    @PostMapping("applicant/{applicantId}/identifier")
    public ResponseEntity<Identifier> callbackUrl(@RequestBody Map<String,String> map,@PathVariable long applicantId){
        Identifier identifier = new Identifier();
        identifier.setApplicant(applicantRepository.findById(applicantId));
        identifier.setOcrResponse(encryptionService.encrypt(map.get("abbyOcr")));
        identifierRepository.save(identifier);
        ResponseEntity.noContent();
    }

Właściwie otrzymujemy odpowiedź jako callback od abby ocr i zapisujemy ją do bazy danych po zaszyfrowaniu.

To są nagłówki żądań.

Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,hi;q=0.8
accessToken: 272f8807-f6c9-4bc4-9ba4-8082532e9364
Cache-Control: no-cache
Connection: keep-alive
Host: 10.132.214.204:8191
Origin: http://10.132.214.204:8080
Pragma: no-cache
Referer: http://10.132.214.204:8080/dob/
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36

A to są nagłówki odpowiedzi z linuxa

Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Type: application/json;charset=UTF-8
Date: Wed, 20 Nov 2019 11:52:24 GMT
Expires: 0
Pragma: no-cache
Set-Cookie: JSESSIONID=174FB7AF3BC28922D3169DE1BB12612E; Path=/; HttpOnly
Transfer-Encoding: chunked
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

Niech ktoś mi podpowie, jak rozwiązać ten problem

0
Vikram Singh 20 listopad 2019, 14:19
Dlaczego to głosowanie w dół?
 – 
Vikram Singh
20 listopad 2019, 14:23
Czy na pewno treść odpowiedzi naprawdę się różni? Albo po prostu, jak jest wyświetlany (przez Twojego klienta / terminal / aplikację)?
 – 
Thilo
20 listopad 2019, 14:35
W rzeczywistości są one wyświetlane inaczej na listonoszach, a także w html.
 – 
Vikram Singh
20 listopad 2019, 14:37
2
Proszę pokazać odpowiedni kod i podać dokładny problem lub błąd. Sam opis nie wystarczy. Zobacz też Jak utworzyć przykład minimalny, kompletny i weryfikowalny.
 – 
jww
20 listopad 2019, 14:40
1
Czy żądanie zawiera nagłówek „Accept-Charset”? Coś w stylu: "Accept-Charset: utf-8, iso-8859-1;q=0.5"?
 – 
Zaki
20 listopad 2019, 14:40

1 odpowiedź

Musisz ustawić kodowanie.
Spróbuj użyć techniki kodowania UTF-8, aby uzyskać odpowiedź.

0
Tarun 20 listopad 2019, 14:32
1
Nie, nie jest to związane z maszyną kliencką, ponieważ otrzymuję również inną odpowiedź w listonoszach.
 – 
Vikram Singh
20 listopad 2019, 14:25
1
Muszę się zgodzić z sugestią. Czy masz inne komponenty w kanale komunikacyjnym, które mogą używać innego kodowania? Może to być kontekst, środowisko wykonawcze lub inne kontenery, nawet jeśli znajdują się w tym samym procesie.
 – 
Nicolae Petridean
20 listopad 2019, 14:52
Nie, to bezpośrednie wezwanie do serwisu
 – 
Vikram Singh
20 listopad 2019, 14:57
Czy możesz spróbować sprawdzić, co jest w twoim kliencie? Chodzi mi o to, że prawdopodobnie próbuje zdekodować odpowiedź z niewłaściwym kodowaniem, które jest gdzieś dekodowane. Podczas debugowania w czasie wykonywania powinieneś być w stanie to zobaczyć. Kiedy wiadomość zostanie odtworzona. Widzę, że z nagłówków nie określasz żadnego nagłówka Accept-charset. możesz też spróbować to skonfigurować. W zależności od tego, jak klient bierze to pod uwagę.
 – 
Nicolae Petridean
20 listopad 2019, 15:43
Moim klientem jest przeglądarka, robi to, co zawsze. Ale mój kod nie dekoduje.
 – 
Vikram Singh
20 listopad 2019, 16:17