Comment résoudre le problème des caractères chinois tronqués dans les fichiers Java Linux-exploitation et maintenance Linux-php.cn

Solutions aux caractères chinois tronqués dans les fichiers Java Linux : 1. Téléchargez le code source Sun de jdk1.8 ; 2. Modifiez la création de polices de polices physiques en polices logiques ;

Comment résoudre le problème des caractères chinois tronqués dans les fichiers Java Linux

L'environnement d'exploitation de cet article : système linux5.9.8, jdk1.8, ordinateur Dell G3.

Comment résoudre le problème des caractères chinois tronqués dans les fichiers Java Linux ?

Solution aux caractères chinois tronqués Java dans l'environnement Linux

Je crois que de nombreux amis ont rencontré le problème des caractères Java tronqués récemment. J'ai également résolu un problème de « processus d'utilisation de texte pour générer des images » « Les caractères chinois et spéciaux sont tronqués » ; j'ai passé beaucoup de temps à déboguer divers codes sources sous sun.font et sun.awt, et j'ai finalement compris le mécanisme et résolu le problème actuel. problème ; je vais maintenant vous donner le processus de résolution du problème. Notez-le et gardez une trace afin que vous ne le rencontriez plus à l'avenir.

Problèmes rencontrés

Voici le code que je souhaite exécuter (extrêmement simplifié, mais le sens reste le même) :

public static void main(String[] args) throws IOException {
   File file = new File("test.png");
   Font font = new Font("宋体", Font.PLAIN, 10);
   BufferedImage bi = new BufferedImage(400, 200, BufferedImage.TYPE_INT_ARGB);
   Graphics2D g2 = (Graphics2D) bi.getGraphics();
   g2.setBackground(Color.WHITE);
   g2.clearRect(0, 0, 400, 200);
   g2.setFont(font);
   g2.setColor(Color.BLACK);
   g2.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING, RenderingHints.VALUE_TEXT_ANTIALIAS_ON);
   g2.drawString("为什么没有(ꐚꌒꑿꆺ)(ꐚꌒꑿꆺ)这名字特殊不？@￥￥￥ 为什么没有(ꐚꌒꑿꆺ)(ꐚꌒꑿꆺ)这名字特 ", 0, 10);
   g2.dispose();
   ImageIO.write(bi, PNG, file);
}

Copier après la connexion

Le but est bien sûr de voir la scène suivante à l'ouverture de test.png :

Après qu'il n'y ait eu aucun problème de débogage local, je l'ai mis sur la machine de test (Linux) et je l'ai exécuté. Les résultats d'exécution ont été incroyables :

Téléchargement du code source jdk1.8 de Sun

Suivez le. style cohérent des programmeurs : Puisqu'il y a un problème, alors Debug !
Le truc, c'est que le package de code source actuel ne contient plus le code du package sun !
Heureusement, Java a officiellement confirmé que le code d'OpenJDK est fondamentalement le même que le code source de la JVM. Vous pouvez le télécharger directement depuis OpenJDK8u : jdk8u

Quant à la façon d'utiliser le code source pour déboguer, je n'en parlerai pas. ... Ce n'est pas basique, alors ne lisez pas cet article

Localisez le problème

Téléchargez directement le code source, utilisez des points d'arrêt distants et exécutez-le sur le serveur. Lors du débogage, j'ai d'abord découvert le premier code causé. incohérence entre les serveurs locaux et de test :

Il s'avère que lorsque la JVM crée une police, elle utilisera FontManagerFactory pour l'obtenir, et différents systèmes utilisent différents FontManagers ! Mac utilise CFontManager, tandis que Linux utilise X11FontManager !

Alors, quelles sont les différences entre ces deux FontManagers ?

CFontManager créera CFont en tant que Font2D. Ce CFont est une classe créée par JVM spécifiquement pour Mac. En regardant les commentaires de la classe et de la méthode, vous pouvez savoir que parfois les polices physiques sont enveloppées par CFont dans l'environnement Mac, et c'est le cas. réalisé en code natif. :

Font2D créé par X11FontManager est une collection qui contient des polices logiques et des polices physiques. X11FontManager hérite de FcFontManager et FcFontManager hérite de SunFontManager ; jetons un coup d'œil à la méthode loadFonts() de X11FontManager, qui utilise directement la méthode loadFonts() de SunFontManager pour charger les polices physiques.

polices logiques et polices physiques

Le débogage du code ici a essentiellement confirmé qu'il s'agit d'un problème de chargement de polices dans différents environnements, donc les polices logiques trouvées lors du débogage de l'environnement Linux Et que sont les polices physiques ?

Polices physiques

Les polices physiques sont de véritables bibliothèques de polices qui contiennent des données de glyphes et des tableaux qui mappent des séquences de caractères à des séquences de glyphes à l'aide de technologies de police telles que TrueType ou PostScript Type 1. Toutes les implémentations de la plateforme Java prennent en charge les polices TrueType ; la prise en charge d'autres technologies de polices dépend de l'implémentation. Les polices physiques peuvent utiliser des noms de police tels que Helvetica, Palatino, HonMincho ou tout autre nom de police. En règle générale, chaque police physique ne prend en charge qu'un ensemble limité de systèmes d'écriture, par exemple uniquement les caractères latins ou uniquement le japonais et le latin de base. L'ensemble des polices physiques disponibles varie en fonction de la configuration. Les applications qui nécessitent des polices spécifiques peuvent utiliser la méthode createFont pour regrouper ces polices et les instancier.

Polices logiques

Les polices logiques sont cinq familles de polices définies par la plate-forme Java qui doivent être prises en charge par tous les environnements d'exécution Java : Serif, SansSerif, Monospaced, Dialog et DialogInput. Ces polices logiques ne sont pas de véritables bibliothèques de polices. De plus, c'est l'environnement d'exécution Java qui mappe les noms de polices logiques aux polices physiques. Les mappages dépendent de l'implémentation et généralement des paramètres régionaux, de sorte que l'apparence et les spécifications qu'ils fournissent varient. En règle générale, chaque nom de police logique est mappé sur plusieurs polices physiques afin de couvrir la vaste gamme de caractères.

问题解决

debug的源码很多，但是此次问题的关键点就在这里了，其它debug内容就不贴了。
既然已经确认了本地（mac环境）是native的代码帮我们做了物理字体的封装，转换成了CFont进行渲染，而Linux环境的X11FontManager只是帮我们加载了物理字体和逻辑字体，但是却需要我们自己进行选择，那么解决问题的第一步就显而易见了：将Font的创建从物理字体改为逻辑字体

1 //  Serif、SansSerif、Monospaced、Dialog 和 DialogInput 随意选择
2 Font font = new Font("Serif", Font.PLAIN, 10);

Copier après la connexion

改完以后执行代码，仍然是乱码！继续Debug，发现是Linux上逻辑字体Serif映射的物理字体没有中文字体和对应的特殊符号字体，这就很简单了，直接在Linux上安装中文字体（simsun.ttf），再安装特殊符号“ꐚꌒꑿꆺ”可显示的字体（mysi.ttf），将这两个字体也放到了jdk的fonts目录（JAVA_HOME/jre/lib/fonts）下。文章后面有Linux字体安装方法。

完成上面的改动之后，重启服务，再次执行成功显示！热烈庆祝~~~~

JVM逻辑字体映射配置

以上的改动已经可以解决中文和特殊字符乱码问题，但是我在Debug过程中发现在逻辑字体加载过程中，JVM会参考一个配置文件，代码在sun.awt.FontConfiguration中，这个配置类完成了逻辑字体和物理字体的映射，也指导了SunFontManager创建逻辑字体，而这个FontConfiguration读取的配置文件就是fontconfig.properties，这个配置文件目录是JAVA_HOME/jre/lib

查阅了一下资料，JVM字体配置文件的加载顺序如下：
JAVA_HOME/jre/lib/fontconfig.OS.Version.properties
JAVA_HOME/jre/lib/fontconfig.OS.Version.bfc
JAVA_HOME/jre/lib/fontconfig.OS.properties
JAVA_HOME/jre/lib/fontconfig.OS.bfc
JAVA_HOME/jre/lib/fontconfig.Version.properties
JAVA_HOME/jre/lib/fontconfig.Version.bfc
JAVA_HOME/jre/lib/fontconfig.properties
JAVA_HOME/jre/lib/fontconfig.bfc

OS是系统，例如：Linux、CentOs、RedHat等；Version是版本号

在这个配置文件中可以修改逻辑字体与物理字体的对应关系，也就是说可以手动的修改Serif、SansSerif、Monospaced、Dialog 和 DialogInput这五个逻辑字体在不同场景下所使用的真正物理字体。

举个栗子，下面的配置将serif.plain逻辑字体的中文使用simsun.ttf，拉丁文使用java自带字体：

# @(#)linux.fontconfig.SuSE.properties 1.2 03/10/17
#
# Copyright 2003 Sun Microsystems, Inc. All rights reserved.
#

# Version
version=1

# Component Font Mappings
serif.plain.chinese=-misc-simsun-medium-r-normal--*-%d-*-*-c-*-iso10646-1
serif.plain.latin-1=-b&h-lucidabright-medium-r-normal--*-%d-*-*-p-*-iso8859-1

# Search Sequences
sequence.allfonts=latin-1,chinese

# Exclusion Ranges

# Font File Names
filename.-misc-simsun-medium-r-normal--*-%d-*-*-c-*-iso10646-1=/usr/share/fonts/myfonts/simsun.ttf

Copier après la connexion