1. 問題が発生する
数日前に顧客から提供されたサーバーlinuxにバックエンド サービスをデプロイしているときに、この例外がjar突然スローされました。Caused by: java.text.ParseException: Unparseable dateコードを確認したところ、ユーザー センター インターフェイスを呼び出したときに、データを取得した後にオブジェクト変換を使用していることがわかり、gsonログから、日付変換中にスローされたエラーであることがわかりました。
2. 問題分析
Gsonローカルで開発していたときにはこの問題は発生しなかったため、その時点ではオブジェクトに日付形式を設定すること は考えていませんでした。しかし、サーバーにデプロイするときにlinux、このエラーが報告されます。これはマイクロサービスプロジェクトなので、まだ多くのサービスがあり、1つずつ追加するのはあまりにも面倒です。そして、最初に考えられるのは、コードではなくサーバーシステムの問題です問題、コードにはどのような問題があるでしょうか? ? ? 。
このような疑問に基づいて、運用保守担当者に問い合わせました。顧客からの新しいサーバーなので、サーバーの時刻形式、タイムゾーン、エンコーディングなど、サーバーのデフォルト設定がまだ疑問です。正常ですlinux。
結局、違うものを見つけました。
3. 問題解決
linuxサーバー上でコマンドを入力する とlocale、下図のような状況になりました 「
現在のサーバーは英語形式でエンコードされているということです。とにかく、他は正常ですが、ここが間違っています。まず変更してから変更してください」それが問題だと感じています。次に、linuxサーバー上で次の操作を実行します。
Entercd ~または単に Enter しcd、ホーム ディレクトリ (ルート ディレクトリではないものもあります) に戻り、次のコマンドを順番に実行します。
echo 'export LANG=zh_CN.UTF-8' >> .bash_profile
echo 'export LC_ALL="zh_CN.UTF-8"' >> .bash_profile
上記のコマンドを一つずつ実行し、入力してlocaleみると以下のように
なっています 運用保守のことが分からないので、運用保守の提案としては、Linuxの設定ファイルに書き込むことで、一部のサーバーが再接続後に元に戻らないようにするためです。
最後に、サービスを再起動して再試行し、gson変換が正常であることを確認します。
4. 後から考えたこと
最も正しい方法ではありますが、ほとんどの人は、次のように記述するときに時刻形式を定義する必要があると考えるかもしれません。
Gson gson= new GsonBuilder().setDateFormat("yyyy-MM-dd HH:mm:ss").create();
gsonしかし、こうして書いてみると、思い出したように、私はこの形式でしか時刻を知らない ようです。もちろん、インターフェイスは一般に形式を変更しないため、このように記述するのが正しいです。
結局のところ、私は、英語のエンコーディングは私たちの国が時間を定義する方法ではないので、何を、yyyy-MM-ddみんなが次のように書くのではないかと思いました。なぜなら、私たちのインターフェースは中国語のエンコーディングで書かれているのに、なぜそれをエンコーディング
に変更する必要があるのですか。 ここまで述べましたが、実際には、サーバー上で次の 2 行のコマンドを実行するだけです。zh_CN.UTF-8