Das es wieder ein Haus und Hof Them von mir ist, hole ich etwas aus.
Wie wir alle wissen werden Dateien als Bytes gespeichert. Damit stellt sich natuerlich die Frage "Welcher Byte-WErt zwischen 0 und 255 soll das Zeichen A darstellen?". Der findige (und klugscheiszerische) Entwickler Antwortet natuerlich mit "65". Soweit so gut, aber was it mit dem Zeichen "й"? Da scheiden sich die Geister...
Also das Encoding der Datei musst du verstehen als Mapping von Byte-Wert auf Zeichen, und da sich hier immer die Geister geschieden haben, gibt es davon viele Unterschiedliche. In der Zwischenzeit hat sich die Welt weitestgehend geeinigt das UTF-8 das Encoding der Wahl ist. Es ist kompatibel mit ASCII in den Wertden von 0-128, und kann bis zu vier Byte pro Zeichen verwenden. Also "й" wird gespeichert als die Bytes "208 185", quasi "zweite Seite, dieses Zeichen". Damit kann UTF-8 fast alle Sprachen und Zeichen problemlos abbilden. Jetzt betritt Microsoft die Buehne, Microsoft verwendet seit jeher ein ISO 8859-1 Derivat, naemlich CP-1252 (auch bekannt als Windows 1252), welches zwar auch in den Bytes 0-128 kompatibel ist zu ASCII (und damit zu UTF-8), aber darueber hinaus einfach gar nichts gemein hat. Zusaetzlich kann CP-1252 nicht mal annaehernd die Menge an Zeichen abbilden wie UTF-8.
Daraus ergibt sich die tolle Situation, dass Text welcher auf Windows Maschinen geschrieben wird, und mehr als Lateinische Zeichen enthaelt, einfach Kacke zum verarbeiten ist auf allem was nicht Windows ist (auch bekannt als: Der Rest der Welt). Und genau dieses Problem hast du jetzt.
Du willst deine JSON Dateien *immer* als UTF-8 speichern (im Zweifelsfall einen Editor holen der das kann, zum Beispiel Notepad++), und du willst beim lesen und schreiben in Java *immer* explizit das Charset
auf UTF-8 setzen (StandardCharSets.UTF8
. Dann hast du diese Probleme nicht mehr. Und du willst auch deine IDE umstellen, so das fuer Quellcode immer UTF-8 verwendet wird, und nicht der Plattform-Standard (in deinem Fall CP-1252).