7
votes

Memorystream de String - Confusion sur le codage à utiliser

J'ai un morceau de code qui convertit la chaîne en flux de mémoire: xxx

Cependant, je suis un peu confus si c'est correct. Fondamentalement, je suis toujours confondu sur le codage .NET.

Bottom Line: Est-ce que j'utilise un objet de codage correct ( utf8 ) pour obtenir des octets?

Je sais que, en interne .NET stocke la chaîne en tant que utf-16 , mais ma variable d'application est basée sur le fichier avec du texte qui a été enregistré dans UTF-8 codage.

Merci, Pawel

Editer 1: Expliquons exactement comment je reçois ApplicationForm variable. J'ai accès à l'assemblage qui expose la classe avec la méthode generateApplicationForm . Cette méthode renvoie la chaîne. Cependant, je sais que quelque part dans les coulisses, composant utilise des fichiers stockés sur lecteur.content de ces fichiers sont codés à l'aide de UTF-8. Donc, je ne peux pas lire directement le fichier, etc. Je n'ai que cette chaîne et je sais, à l'origine du fichier codé UTF-8. Dans le code client, celui qui utilisait GenerateApplicationform Composant, je dois convertir ApplicationForm variable dans le flux, COS D'autres composants (d'un autre assemblage) attend un flux < / fort>. C'est là que UTILISER .... Déclaration mentionnée dans la question Springs en action.


5 commentaires

Si cela fonctionne, ne le touchez pas.


Mais cela dépend des données que vous travaillez.


Qu'est-ce qui tente d'atteindre? Comment l'application est-elle peuplée? C'est une chaîne ... c'est dans UTF-16 en mémoire, événement s'il a été chargé à partir d'un fichier UTF-8


Quels types d'encodage le support de composant GenerateApplicationForm est-il dans le flux passé? C'est le creux de la question.


Utf-8. GenerateApplicationform En fait est utilisé dans une sorte de médiateur. Ce médiateur: a) reçoit une chaîne (de la composante x - qui est en fait de la générationApplicationForm - qui génère des formulaires de demande) b) change la chaîne dans le flux c) passe le flux du composant Y. Composant Y. Composant Y s'attend à un flux d'encodage UTF-8.


5 Réponses :


0
votes

Si les données sont enregistrées dans UTF-8, vous devez l'ouvrir avec UTF-8.


1 commentaires

Fondamentalement, je n'ouvre pas les données. S'il vous plaît vérifier mon édition en question.



0
votes

Utilisez simplement le même codage pour lire comme vous l'aviez l'habitude d'écrire. Si c'était UTF8 -> Utilisez UTF8. Si vous écrivez chinois, Somony doit être capable de lire le chinois pour vous comprendre ...


0 commentaires

0
votes

pour la barre d'ordre d'octets UTF-8 (BOM) doit être ajouté au début du fichier. Voir le fichier est UTF-8, puis utilisez le convertisseur UTF-8.


1 commentaires

J'ai ajouté des informations à poser des informations. Veuillez vérifier si votre réponse est toujours pertinente.



3
votes

Assumer ApplicationForm est une chaîne que vous avez lisée à partir de certains fichier texte UTF8 . Ce sera utf16 / unicode , quel que soit l'encodage du fichier source. La conversion s'est produite lorsque vous avez chargé le fichier dans la chaîne.

Votre code encodera la chaîne ApplicationForm dans un MemoryStream de utf8 octets.

Cela peut être correct ou non en fonction de ce que vous voulez faire avec cela.

.NET Strings est toujours utf16 ou Unicode . Lorsque Strings sont convertis en fichiers, flux ou octet [] , ils peuvent être codés de différentes manières. 1 octet ne suffit pas à stocker tous les caractères différents utilisés dans toutes les langues, de sorte que des chaînes plus compliquées doivent être codées afin que d'un caractère puisse être représenté par plus d'un octet, parfois ou toujours en fonction du codage utilisé.

Si vous utilisez un codage simple comme ASCII un caractère comprendra toujours un octet, mais les données seront limitées au jeu de caractères ASCII . La conversion à 'ASCII' de tout codage UTF pourrait perdre des données si des caractères multi-octets sont utilisés.

Pour la photo complète sur Unicode Go ICI .

EDIT 1: En empêchant d'autres informations sur le composant GenerateApplicationForm , enconding utf8 est susceptible d'être le bon choix. Si cela ne fonctionne pas, essayez ascii ou utf16 . Le meilleur de tous, consultez le code source du composant ou le fournisseur de composants.

EDIT 2: Définitivement utf8 alors, vous étiez parti tout le long.


6 commentaires

J'ai ajouté quelques détails à la question. Peut-être que cela aidera la question que je traite. Merci


Quels types d'encodage le support de composant GenerateApplicationForm est-il dans le flux passé? C'est le creux de la question.


Utf-8. GenerateApplicationform En fait est utilisé dans une sorte de médiateur. Ce médiateur: a) reçoit une chaîne (de la composante x - qui est en fait de la générationApplicationForm - qui génère des formulaires de demande) b) change la chaîne dans le flux c) passe le flux du composant Y. Composant Y. Composant Y s'attend à un flux d'encodage UTF-8.


Ok, je pense que je commence à l'obtenir. Cette conclusion décisive est la suivante: coding.utf8.getBytes (ApplicationForm)) La ligne fait de la conversion sur la mouche de la représentation de chaîne UTF-16 dans .NET dans UTF-8?


Cela ne fait pas une comparaison à la volée - voir ma réponse. Il s'agit d'une représentation textuelle d'une valeur binaire et de la remettre en binaire. Cela n'a rien à voir avec comment .NET traite des chaînes interne.


@dagonfly, je suis d'accord avec Windart. Peu importe ce qui est à l'intérieur de String (il se trouve juste utf16.) Ce qui compte, c'est lorsque vous tournez la chaîne de la chaîne dans les octets, ce que les octets seront faits pour représenter le texte, c'est-à-dire quel encodage sera utilisé.



0
votes

Le codage de l'octet UTF8 produit une représentation de vos données à l'envers compatibles avec le jeu de caractères ASCII pour représenter vos données. Comme ASCII est un dénominateur commun le plus bas pour le transfert de données, vous pouvez plutôt vous garantir que cette représentation fonctionnera dans la grande majorité des systèmes.

Bien que vous puissiez le changer, vous supposez que tout système qu'elle va aussi comprendre que vous l'avez changé et appuierez votre nouvelle représentation. C'est une hypothèse assez difficile à vérifier. Les codages à la fois finissent beaucoup de match.

Si, comme vous le dites, vous ne pouvez pas modifier le système qui génère votre chaîne, puis oui, vous le faites bien. Cela fonctionne alors pourquoi voudriez-vous croire que vous devez apporter des modifications? Les internes de la façon dont .NET représente une chaîne ne vient pas en jeu ici, vous n'obtenez pas une chaîne .NET, vous obtenez une représentation codée UTF-8 d'une valeur, vous devez donc utiliser UTF8 pour le décoder à la valeur d'origine. .


0 commentaires