Avatar billede o-zone Nybegynder
28. februar 2007 - 12:45 Der er 16 kommentarer og
1 løsning

Hvordan slipper jeg for at StreamWriter indsætter FF FE i min fil

Hej med jer...

Jeg har et program som genererer en XML string som jeg skal gemmer i en fil. Filen skal bruges i en Unix miljø, men når jeg prøver at loade XML-filen giver unix programmet en fejlmeddelelse fordi der er noget forkert i rod elementet.

Efter at have gransket sagen nøjere (i en hex editor), viser det sig at min StreamWriter indsætter de to tegn "FF FE" i begyndelsen af min fil. De kan ikke ses når jeg arbejder med filen som almindelig tekstfil i mit windows system, men unix bryder sig altså IKKE om dem.

Jeg tror nok at det er noget Encoding shit der fejler, for de to tegn skulle ifølge MSDN være udtryk for at der var brugt UTF-16 encoding (men mit program beder eksplicit om UTF-8!)

Jeg har prøvet at bruge alle mulige encodings, men intet hjælper tilsyneladende :-(

Her er min string2file metode:
---8<----------
        public void StringToFile(string fileName, string contents)
        {
            StreamWriter sWriter = null;
            try
            {
                FileStream fileStream = new FileStream(fileName, FileMode.Create, FileAccess.Write);
                sWriter = new StreamWriter(fileStream, Encoding.UTF8);
                sWriter.Write(contents);
            }
            finally
            {
                if (sWriter != null)
                {
                    sWriter.Close();
                }
            }
        }
---8<----------

Er der nogen af jer der ved hvordan jeg kan slippe af med de to irriterende foranstillede tegn? :-(

(Jeg har været så langt ude at jeg overvejede at åbne filen bagefter som binær fil, og så klippe de to første tegn væk - men det er ikke ønskværdigt, da jeg arbejder med pænt mange filer, og det derfor vil tage ret lang tid :-( )
Avatar billede kalp Novice
28. februar 2007 - 12:48 #1
er encoding også sat til UTF-8 i xml'en?
Avatar billede o-zone Nybegynder
28. februar 2007 - 12:49 #2
jeps! her er et eksempel på en xml fil:
---8<----------
<?xml version="1.0" encoding="utf-8"?>
<root>
    <test>bla bla bla</test>
</root>
---8<----------
Avatar billede kalp Novice
28. februar 2007 - 15:13 #3
Nu bruger jeg aldrig FileStream til at gemme Xml, men XmlDocument så vil foreslå du prøver det istedet.
Avatar billede arne_v Ekspert
28. februar 2007 - 15:24 #4
sWriter = new StreamWriter(fileStream, new UTF8Encoding(false));
Avatar billede o-zone Nybegynder
28. februar 2007 - 16:16 #5
qawi> Jeg bruger også min metode til at gemme andet end XML så jeg vil helst slippe for at skulle bruge XmlDocument (anyway, så skal XmlDocument vel også have en encoding hvis den skal gemme en fil?)

arne_v> Det ville have været vidunderligt hvis det havde virket, men jeg kan ikke se nogen forskel på outputtet - det ser tilsyneladende ud som om min StreamWriter har besluttet sig for at skrive i UTF-16 uanset hvad jeg finder på. Når jeg kikker i mine XML-filer i hex, kan jeg se at alle tegn fylder 2 bytes >:-7

Jeg er i øvrigt selv blevet MEGET klogere på encodings siden sidst, især takket være denne side: http://www.unicode.org/faq/utf_bom.html#BOM
(bare hvis der var andre der var interesserede :) )

...men jeg har altså stadig ikke løst mit problem :-(
Jeg har prøvet at gemme mine strenge som Byte[] istedet (og testet at der ikke er nogen BOM (Byte Order Mark) i starten af min String) ... men det er altså endnu ikke lykkedes mig at gemme filen i UTF-8 :(

Hvis jeg henter filen ind i UltraEdit, og gemmer den som UTF-8 er alt peachy, og BOM bytesene væk :-7 (men som sagt har jeg ret mange filer, så DET er IKKE en løsning!)
Avatar billede o-zone Nybegynder
28. februar 2007 - 16:21 #6
arne_v> Jeg fatter i øvrigt overhovedet ikke hvorfor dit forslag ikke virker - det ser jo ellers ud til at det adresserer præcis mit problem :-(
Avatar billede kalp Novice
28. februar 2007 - 16:26 #7
yes XmlDocument skal også have encoding men det kunne være du slap for de 2 ekstra bytes, men kan godt se det ikke går hvis du gemmer andet end xml så går det ikke:)

Det eneste bud ellers er at bruge StreamWriter istedet for FileWriter.
Avatar billede o-zone Nybegynder
28. februar 2007 - 16:43 #8
kan det evt. være FileWriter der gør knuder? Det er ikke sådan at FileWriter kan tage en UTF8Encoding(false) et eller andet sted? :-/
Avatar billede o-zone Nybegynder
28. februar 2007 - 16:46 #9
he he he ... og det var så selvfølgelig FileSTREAM jeg mente dér :"-P~
Avatar billede kalp Novice
28. februar 2007 - 16:57 #10
tænkte du bare skulle skrive

StreamWriter fileStream = new StreamWriter(filename, false, new UTF8Encoding(false));

eller

StreamWriter fileStream = new StreamWriter(filename, false,Encoding.UTF8);

helt uden filewriter.
Avatar billede o-zone Nybegynder
01. marts 2007 - 13:38 #11
Hej med jer ...
Jeg er simpelthen blevet klogere siden sidst! (against all odds) :-)

Jeg skrev godt nok at citat:"arne_v> Det ville have været vidunderligt hvis det havde virket, men jeg kan ikke se nogen forskel på outputtet"
Det var også rigtigt at jeg ikke kunne se forskel - men hvad jeg IKKE vidste var at det kun skyldtes at min ultraEdit@windows tilsyneladende selv smækker en BOM i front når jeg henter filen ind (!!!! :-O) ... det vil sige Arne_v's løsning fungerer korrekt - jeg kan bare ikke se at den gør det når jeg kikker efter i windows!

Jeg har i øvrigt INGEN ide om hvorfor mit system ter sig sådan - det virker ret tosset på mig, at jeg ikke kan slippe for det BOM også selvom det rent faktisk IKKE findes i filen. Men de filer jeg får gemt ER altså gode nok.

arne_v> smid et svar så jeg kan forgylde dig! :)
Avatar billede o-zone Nybegynder
01. marts 2007 - 13:42 #12
Det ville næsten også have været for ærgerligt, hvis arne_v's løsning ikke havde virket, for ifølge APIet så addresserer den constructor PRÆCIS det problem jeg havde!

Jeg må indrømme at det var en af de sværere fejl at finde - jeg troede ærlig talt at jeg kunne stole på at UltraEdit ville gengive det eksakte filindhold (især når jeg går i hex mode) ... men jeg må altså erkende at min tillid til UltraEdit har lidt et mindre knæk idag! :-P~
Avatar billede kalp Novice
01. marts 2007 - 13:48 #13
notepad er altid en god løsning:P

i Ultra Edit fik jeg engang sådan en lille prik i starten.. lignede et punktum men lå lidt højere på, men den forsvandt ved brug af XmlDocument:)
Avatar billede arne_v Ekspert
01. marts 2007 - 15:26 #14
svar
Avatar billede o-zone Nybegynder
01. marts 2007 - 16:29 #15
qawi> notepad?? :-O Den kan mig bekendt ikke vise mig en fils indhold byte for byte (som i UltraEdits Hex mode)???

I notepad kan jeg da i hvert fald IKKE se hvorvidt en tekstfil er encoded med Byte Order Mark eller ej! Det kan godt være at UltraEdit er falmet en smule i mine øjne efter denne sag - men det gør absolut ikke notepad mere brugbar! :-P~
Avatar billede kalp Novice
01. marts 2007 - 23:38 #16
o-zone >> ja hvis det er til de formål så kan du ikke bruge notepad, men det kan mange andre heldigvis;)
Avatar billede kalp Novice
01. marts 2007 - 23:40 #17
nogle fra mit arbejde bruge notepad 2.. den har funktionalitet der minder om ultra edit, men har ikke selv erfaring med den.

Jeg bruger editplus selv.

notepad2
http://www.flos-freeware.ch/notepad2.html
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
IT-kurser om Microsoft 365, sikkerhed, personlig vækst, udvikling, digital markedsføring, grafisk design, SAP og forretningsanalyse.

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester