Je pensais que les personnages de Java sont de 16 bits comme suggéré dans Java Doc < / a>. N'est-ce pas le cas pour les cordes? J'ai un code qui stocke un objet dans un fichier: essentiellement, j'ai essayé de stocker une chaîne "abcd" dans le fichier "sortie" , quand j'ai ouvert sortie avec un éditeur et supprimé la partie de chaîne Aucun, ce qui reste de la chaîne "ABCD", qui correspond à 4 octets au total. Quelqu'un sait pourquoi? Java enregistre-t-il automatiquement de l'espace à l'aide de ASCII au lieu de Unicode pour les chaînes pouvant être prises en charge par ASCII? Merci
5 Réponses :
oui, le char code> est uniquement UNICODE dans le contexte de l'environnement Java Runtime. Si vous souhaitez l'écrire en utilisant un codage 16 bits, utilisez un fichier code> code>. FileWriter outputStream = null;
try {
outputStream = new FileWriter("myfilename.dat");
int c;
while ((c = inputStream.read()) != -1) {
outputStream.write(c);
}
} finally {
if (outputStream != null) {
outputStream.close();
}
}
Je ne pense pas que vous comprenez que vous comprenez la Point PAL - Demandant pourquoi une offre de sortie écrit des octets uniques. Et la réponse que je crois est ma réponse ci-dessous.
@MJB - Non, le codage compte. S'il écrit à l'aide d'un codage 16 bits, le système d'exploitation le considérera et allouera 16 bits pour un seul caractère. Bien que, à nouveau, il appartient au système d'exploitation.
Je ne suggérez pas d'utiliser FileWriter , car il n'a aucun moyen de spécifier le codage et seulement prend en charge le codage par défaut. Le (malheureusement plus verbose) nouvelle sortie de sortie (nouveau fichierOutPutStream (fichier), codage) est le meilleur choix.
Si vous regardez la source de chaîne, il convient de noter que cela appelle dataOutUt.writeutf pour écrire des chaînes. Et si vous lisez que vous découvrirez qu'ils sont écrits comme «modifié UTF-8». Les détails sont longs, mais si vous n'utilisez pas non 7 bits ASCII, oui, il faudra un octet. Si vous voulez que les détails de Gory se trouvent sur le javadoc extrêmement long en dataOutUt.writteutf ()
(Je pense par "None String Part", vous vous référez aux octets que ObjectOutpTstream émet lorsque vous le créez. Il est possible que vous ne voulez pas utiliser ObjectOutputStream, mais je ne connais pas vos exigences.)
Juste Fyi, Unicode et UTF-8 ne sont pas la même chose. Unicode est une norme qui spécifie, entre autres choses, quels caractères sont disponibles. UTF-8 est un codage de caractères qui spécifie comment ces caractères doivent être codés physiquement dans les 1s et les 0s. UTF-8 peut utiliser 1 octet pour ASCII (<= 127) et jusqu'à 4 octets pour représenter d'autres caractères Unicode.
UTF-8 est un superset strict d'ASCII. Donc, même si vous spécifiez un codage UTF-8 pour un fichier et que vous écrivez «ABCD», il ne contiendra que ces quatre octets: ils ont le même codage physique en ASCII que dans UTF-8.
Votre méthode utilise Si vous êtes sérieux de comprendre cela, vous devriez vraiment passer une bonne quantité de temps à la lecture des systèmes de codage Unicode et de caractères. Wikipedia possède un excellent article sur Unicode comme départ. ObjectOutPutStream qui comporte en réalité un codage significativement différent de l'ASCII ou UTF-8! Si vous lisez soigneusement Javadoc, si obj est une chaîne et s'est déjà produit dans le flux, des appels ultérieurs vers WriteObject entraîneront une référence à la chaîne précédente à émettre, susceptiblement de causer beaucoup moins d'octets d'octets dans le cas de chaînes répétées.
Une autre chose importante à propos de la représentation de la mémoire des chaînes Unicode est qu'un point de code unicode ne s'intègre pas toujours dans un caractère de 16 bits.
@CodeInchaos - Pouvez-vous fournir des scénarios où cela dépasse 16bits?
Tout personnage pas dans le plan de base a un point de code de code de base supérieur à 2 ^ 16-1. Donc utf-16 le code en deux caractères 16 bits. en.wikipedia.org/wiki/utf-16/ucs-24/a >
Donc, pour répondre à la question de OP directement alors: cela dépend du codage de la chaîne ...
Vous pouvez donc vous attendre à un 16 * 4 = 64 bits = 8 octets fichier? Plus que l'encodage UTF-8 ou ASCII. Une fois que le fichier est écrit dans un fichier. La gestion de la mémoire (en termes d'espace) est au système d'exploitation. Et votre code n'a pas de contrôle dessus.
Ce n'est pas vrai, votre code peut contrôler absolument comment la sortie est codée.
Je comprends. Mais même lorsque vous spécifiez, il appartient au système d'exploitation de gérer l'espace dont il a besoin. (Veuillez comprendre cela, je ne m'oppose pas que le système d'exploitation changera le codage)
@sjr - en fait +1 pour votre réponse. Il indique clairement. Si vous écrivez ABCD dans un fichier, le système d'exploitation (bien que l'encodage est UTF-8) allouera 1 octet uniquement (car il suffit) ..
Le système d'exploitation n'a rien à voir avec la manière dont Java codant pour une chaîne lors de la sérialisation.
Alors peut-être que vous devriez mieux l'expliquer. Le mappage entre vos données et une séquence d'octets n'est pas le travail du système d'exploitation. Le système d'exploitation est uniquement responsable de stocker cette séquence d'octets sur le disque. Mais cela ne sait pas ou ne se souciait pas des codages de quelque manière que ce soit. Le système d'exploitation est totalement non pertinent dans le contexte de cette question.
Ouais peut-être! Je parlais du scénario une fois que cela a été écrit sur le disque!
Vous pouvez être intéressé de savoir qu'il existe un malgré le Options Java Hotspot VM Guide suggérant qu'il peut être sur défaut, cela ne peut être que pour les versions de performance. Cela ne semble que travailler pour moi si je le transforme explicitement. -xx: + USECompresseDstringsstrings dans Java Update 21 Version de performance et ultérieure. Cela permettra à la chaîne d'utiliser un octet [] pour les chaînes qui n'ont pas besoin de char []
Juste une pensée: ne pourrait-il pas être que Java sauve dans UTF-8?
Oui, exactement - il stocke des cordes dans l'UTF-8 modifié ...