[Java] String - char probleem

[Verwijderd]

Hallo, ik wil een String omzetten naar een char[]

Java:

String s = "Hallo";
char[] ch = s.toCharArray();

Allemaal geen probleem, maar wat als een string er zo uitziet:

Java:

String s = "Q5\b\037~Q?^\035}T4\f";

Dit gaat niet goed, want nu neemt ie ieder karakter als een char, terwijl een "\037" een soort unicode is voor één karakter

[Soultaker]

Wat gaat er mis dan? Een Java char is ook een (16-bits?) unicode karakter, dus je krijgt dan inderdaad het karakter '\035' in je array (wat trouwens gewoon nog binnen de ASCII character set valt, maar dat terzijde). Waaruit leid je af dat dit anders zou zijn?

[Verwijderd]

Soultaker schreef op 14 July 2003 @ 16:55:
Wat gaat er mis dan? Een Java char is ook een (16-bits?) unicode karakter, dus je krijgt dan inderdaad het karakter '\035' in je array (wat trouwens gewoon nog binnen de ASCII character set valt, maar dat terzijde). Waaruit leid je af dat dit anders zou zijn?

Hmm, ik zie dat het inderdaad niet uit maakt, maar merk iets bijzonders op (althans dat vind ik).

Als ik een String hardcode (dus String s = "20BnT\022>\016S\035\026";) en ik XOR hem dan met een key, dan komt het goed. Maar als ik die String copy paste in een TextField en dan zeg String s = textfield.getText(); en dan die XOR uitvoer, dan gaat ie fout

[Glimi]

Voer je dan letterlijk "20BnT\022>\016S\035\026" in in je textfield? Want dan zal de Java string inhoud immers "20BnT\\022>\\016S\\035\\026" worden
_{of ben ik weer aan het suffen vandaag}

[Verwijderd]

Glimi schreef op 14 July 2003 @ 17:15:
Voer je dan letterlijk "20BnT\022>\016S\035\026" in in je textfield? Want dan zal de Java string inhoud immers "20BnT\\022>\\016S\\035\\026" worden
_{of ben ik weer aan het suffen vandaag}

Ja dat voer ik letterlijk zo in...hoe fix ik dat? Scannen op een \\ en dan 1 verwijderen?

[Verwijderd]

volgens mij kan dat met s.replaceAll("\\\\", "\\");

[Glimi]

Kun je niet gewoon een string met unicode characters invoeren in het textvak?

[hobbit_be]

hmm misschien sla ik de bal er (weer ) naast maar moet je niet \u80 doen? (ie \u as in unicode ?) en als je hardcode moet je toch \\ doen?

[MSalters]

Glimi is aan het suffen.
\037 in een quoted string (in je code) is een enkel karakter
\037 in user input zijn 4 karakters

Het equivalent van user input \037 in code is "\\037", een escaped \ dus.

Reden: Je moet in code een escape karater hebben voor je ", dus de \ is als escape karakter gekozen. Een tekst input veld wordt niet gevolgd door (Java) code, dus dan hoef je niet te weten waar de tekst eindigt, hoef je " dus niet te escapen etc.

[Glimi]

MSalters schreef op 14 July 2003 @ 17:46:
Glimi is aan het suffen.

offtopic:
Owkay, ik houd er weer mee op. Dat is al de derde keer voor vandaag

[MSalters]

offtopic:
sowwy Glimi zal volgende keer liev zijn.

[Verwijderd]

Verwijderd schreef op 14 July 2003 @ 17:20:
volgens mij kan dat met s.replaceAll("\\\\", "\\");

Dit helpt dus niet

[Soultaker]

Mij is het probleem nog steeds volstrekt onduidelijk. Misschien kan de TS (of iemand die het wel begrijpt) het nog eens duidelijk uitleggen?

[Verwijderd]

Soultaker schreef op 14 July 2003 @ 21:37:
Mij is het probleem nog steeds volstrekt onduidelijk. Misschien kan de TS (of iemand die het wel begrijpt) het nog eens duidelijk uitleggen?

Ik zal het wel wat duidelijker uitleggen
Ik wil een XOR doen met een geencrypte text en een key, om de plaintext terug te krijgen. De encrypte text en de key zijn bekend. Ik hoef het dus alleen nog maar even te XOR en daar heb ik ook al de juiste methode voor gemaakt. Het probleem is dat de encrypte text van die unicodes bevat (bijv: \0323 ). Als ik de encrypte String hardcoded opneem dan is het XORen geen probleem. Maar als je de encrypte text in een TextField kopieert en dan met textfield.getText() de text inleest dan gooit java dus een extra \ voor die unicode en dus gaat de XORing niet goed.

Ik heb al geprobeerd om met een string.replaceAll("\\\\", "\\") deze extra backslash te verwijderen, dat gaat dus niet goed. Dus als je een idee hebt...:)

[hobbit_be]

Verwijderd schreef op 14 July 2003 @ 21:48:
[...]

Ik zal het wel wat duidelijker uitleggen
Ik wil een XOR doen met een geencrypte text en een key, om de plaintext terug te krijgen. De encrypte text en de key zijn bekend. Ik hoef het dus alleen nog maar even te XOR en daar heb ik ook al de juiste methode voor gemaakt. Het probleem is dat de encrypte text van die unicodes bevat (bijv: \0323 ). Als ik de encrypte String hardcoded opneem dan is het XORen geen probleem. Maar als je de encrypte text in een TextField kopieert en dan met textfield.getText() de text inleest dan gooit java dus een extra \ voor die unicode en dus gaat de XORing niet goed.

Ik heb al geprobeerd om met een string.replaceAll("\\\\", "\\") deze extra backslash te verwijderen, dat gaat dus niet goed. Dus als je een idee hebt...:)

ah nu snap ik hem ook - wel je zult zover ik weet toch een mini-parsertje moeten schrijven. Als je de tekst ingeeft via een UI dan genereert ie unicode voor jouw hence \0844 is gewoon \0844. Normaal geef je het eigenlijke Unicode getal gewoon dmv je keyboard in. Als je echter ook in UI met \04... wil zeggen dat het in feite een unicode is moet je dit dus zelf gaan omzetten.

dus zoeken op \[Numeric] dan het getal van die nummer-string nemen en die dan casten naar een char.

dus for each \Nummer (char)Integer.parseInt(Nummer).intValue().

[Soultaker]

Verwijderd schreef op 14 July 2003 @ 21:48:
Maar als je de encrypte text in een TextField kopieert en dan met textfield.getText() de text inleest dan gooit java dus een extra \ voor die unicode en dus gaat de XORing niet goed.

Daar geloof ik helemaal niets van. Hoe kom je daarbij? Als je gewoon de tekst "Hé!" intypt in een TextField, krijg je gewoon een string met drie karakters, en dus geen backslash voor de 'é' ofzo. Als je als tekst "bla\066" ofzo intypt krijg je inderdaad letterlijk die 7 karakters in je string. Dan nog wordt die backslash niet verdubbelt. Waarom denk je van wel?

Ik heb al geprobeerd om met een string.replaceAll("\\\\", "\\") deze extra backslash te verwijderen, dat gaat dus niet goed.

Het lijkt me sterk dat er een extra backslash is, dus 'm verwijderen zal ook niet lukken.

Kun je aangeven hoe je de ingelezen string weergeeft? Waarom denk je dat die af zou wijken van de hardcoded variant? Kun je misschien een minimaal, volledig werkend voorbeeld geven (van, zeg, een regel of 50) dat je probleem illustreert?

[ Voor 16% gewijzigd door Soultaker op 14-07-2003 22:21 ]

[Verwijderd]

Ok, hier een verkorte versie van de code...het is een werkzaam exemplaar, dus je kunt het zo copy pasten en dan kun je zelf zien wat ik bedoel

Java:

import java.awt.*;
import java.awt.event.*;
import java.applet.*;

public class Unobfuscator extends Applet
{
    Font font;
    TextArea decText;
    TextField encText;
    Label encLabel, decLabel;
    Button decButton;
    Panel mainPanel, northPanel, centerPanel, westPanel;
    
    public void init()
    {
        font = new Font("Helvetica", Font.PLAIN, 12);       
        encText = new TextField();
        decText = new TextArea("", 5, 40, TextArea.SCROLLBARS_VERTICAL_ONLY);
        encLabel = new Label("Voer hieronder de obfuscated String in");
        decLabel = new Label("De originele String is:");
        decButton = new Button("Unobfuscate");
        decButton.addActionListener(new ActionListener()
        {
            public void actionPerformed(ActionEvent event)
            {
                
                //Copy paste dit maar eens in je textfield:  20BnT\022>\016S\035\026                
                decrypt(encText.getText()); 
                
                //en zet hem dan maar eens hardcoded in deze class en gooi (zie hieronder)
                //decrypt("20BnT\022>\016S\035\026");
            }
        });
                
        northPanel = new Panel();
        northPanel.setLayout(new BorderLayout());
        northPanel.add("North", encLabel);
        northPanel.add("South", encText);
        
        centerPanel = new Panel();
        centerPanel.setLayout(new BorderLayout());
        centerPanel.add("North", decLabel);
        centerPanel.add("Center", decText);
        
        westPanel = new Panel();
        westPanel.add(decButton);
        
        mainPanel = new Panel();
        mainPanel.setLayout(new BorderLayout());
        mainPanel.add("South", centerPanel);
        mainPanel.add("North", northPanel);
        mainPanel.add("West", westPanel);
        
        this.setLayout(new GridLayout(1,1));
        this.add(mainPanel);
    }
                
    private void decrypt(String s)
    {
        char enc[] = s.toCharArray();
        int i = enc.length;
        byte k;
        for(int j = 0; j < i; j++)
        {
            switch(j % 5)
            {
            case 0:
                k = 0x66;
                break;

            case 1: 
                k = 81;
                break;

            case 2: 
                k = 46;
                break;

            case 3: 
                k = 5;
                break;

            default:
                k = 116;
                break;
            }
            enc[j] ^= k;
        }

        decText.setText(new String(enc));
    }
    
}

[hobbit_be]

heb je nou gelezen wat ik postte???

edit 1:
via UI:

code:

wat er verschijnt: 
\  0   4  8  4
wat er in chars zit
x  x   x  x   x = 5 different chars

via Hardcoded:

code:

wat er verschijnt in je editor: 
\  0   4  8  4
wat er in chars zit
x  = 1 char

de java compiler gaat dus die \084 omzetten naar 1 char met waarde == 84 - dit moet jij nu ook gaan doen...

edit2:
Soultaker zei net hetzelfde...

edit3:
in windows doe je normaal ALT + NUMPAD voor het invoeren van Unicode chars (doe maar eens hier in je editor ALT en dan 128 met je keypad dan krijg je: Ç en dat is dus \0128)

[ Voor 109% gewijzigd door hobbit_be op 14-07-2003 22:44 ]

[Verwijderd]

hobbit_be schreef op 14 July 2003 @ 22:39:
heb je nou gelezen wat ik postte???

Yep hobbit_be, maar Soultaker dacht er anders over, dus vandaar ff die post...

[Soultaker]

Verwijderd schreef op 14 July 2003 @ 22:40:
Yep hobbit_be, maar Soultaker dacht er anders over, dus vandaar ff die post...

Ik denk er niet zozeer anders over dan hobbit_be, maar had moeite met het begrijpen met het probleem.

Je wil dus letterlijk de tekst "20BnT\022>\016S\035\026" in kunnen voeren, dus met onder andere de karakters '\\', '0', '1', '6' en '\\', '0', '2', '6' enzo? Of wil je nu juist de unicode karakters die daarbij horen? Als je die patronen wilt herkennen en omzetten in unicode karakters, moet je inderdaad een parsertje schrijven, maar het lijkt me dat als het 'zinnige' karakters zijn je ze ook gewoon met je toetsenbord in kunt voeren.

[ Voor 57% gewijzigd door Soultaker op 14-07-2003 22:48 ]

[hobbit_be]

offtopic:
Soultaker: lol ik wou net op jouw small replyien en dan was ie al weg

[Soultaker]

hobbit_be schreef op 14 July 2003 @ 22:39:
in windows doe je normaal ALT + NUMPAD voor het invoeren van Unicode chars (doe maar eens hier in je editor ALT en dan 128 met je keypad dan krijg je: Ç en dat is dus \0128)

Dat is niet helemaal waar. Als je een getal onder de 256 intoetst (zonder 0 ervoor!) dan interpreteert Windows dat als een (extended) ASCII karakter. Unicode karakter 128 is namelijk het Euro-teken (ALT-0128: €), terwijl het extended ASCII karakter 128 inderdaad de hoofdletter C met cedille is (ALT-128: Ç). De reden hiervoor is dat dit gedrag backward compatible is met DOS, waarin je alleen extended ASCII had. De extended ASCII karakters hebben in Unicode andere nummers (hoewel de normale ASCII karakters, onder de 128, wel hetzelfde getal hebben, waardoor bijvoorbeeld ALT-77 hetzelfde is als ALT-077).

hobbit_be schreef op 14 July 2003 @ 22:49:

offtopic:
Soultaker: lol ik wou net op jouw small replyien en dan was ie al weg

Mja, sorry, ik vond het iets te uitgebreid worden om 'm in een ot-blokje te stoppen en nu heb ik er per ongeluk een aparte reactie van gemaakt.

[ Voor 18% gewijzigd door Soultaker op 14-07-2003 22:52 ]

[Verwijderd]

Soultaker schreef op 14 July 2003 @ 22:45:
[...]

Ik denk er niet zozeer anders over dan hobbit_be, maar had moeite met het begrijpen met het probleem.

Je wil dus letterlijk de tekst "20BnT\022>\016S\035\026" in kunnen voeren, dus met onder andere de karakters '\\', '0', '1', '6' en '\\', '0', '2', '6' enzo? Of wil je nu juist de unicode karakters die daarbij horen? Als je die patronen wilt herkennen en omzetten in unicode karakters, moet je inderdaad een parsertje schrijven, maar het lijkt me dat als het 'zinnige' karakters zijn je ze ook gewoon met je toetsenbord in kunt voeren.

De "20BnT\022>\016S\035\026" wordt zo aangeleverd (hoe en waarom boeit niet), maar dan heb ik weinig keus he...zal dan toch zo'n parsertje worden

[hobbit_be]

Soultaker schreef op 14 July 2003 @ 22:51:
[...]
Mja, sorry, ik vond het iets te uitgebreid worden om 'm in een ot-blokje te stoppen en nu heb ik er per ongeluk een aparte reactie van gemaakt.

en je hebt gelijk (off course). Slecht voorbeeld van me om nou net 128 te pakken aangezien tot 127 hetzelfde is as ascii

Dennis26: het zou kunnen dat zoiets al in Java bestaat (ie een String.functie) maar ken hem zelf niet.

[Soultaker]

Verwijderd schreef op 14 July 2003 @ 22:51:
De "20BnT\022>\016S\035\026" wordt zo aangeleverd (hoe en waarom boeit niet), maar dan heb ik weinig keus he...zal dan toch zo'n parsertje worden

Inderdaad, dat lijkt me ook de eindconclusie. Het was wat moeilijk om daar op uit te komen, omdat je zo'n ongebruikelijke situatie beschrijft.

Overigens heb je bij jouw notatie een groot probleem als unicode karakters van elke grootte toegestaan zijn. Hoe detecteer je in de string "\0234" het verschil tussen '\0234' (1 karakter) en '\023', '4' (2 karakters)? Als na de \0 altijd twee cijfers volgen, of na de unicode notatie gegarandeerd geen cijfer kan volgen, is dat natuurlijk geen probleem,

[hobbit_be]

Soultaker schreef op 14 July 2003 @ 22:55:
[...]
Overigens heb je bij jouw notatie een groot probleem als unicode karakters van elke grootte toegestaan zijn. Hoe detecteer je in de string "\0234" het verschil tussen '\0234' (1 karakter) en '\023', '4' (2 karakters)? Als na de \0 altijd twee cijfers volgen, of na de unicode notatie gegarandeerd geen cijfer kan volgen, is dat natuurlijk geen probleem,

Vraag me eigenlijk af hoe Java dat doet? Want daar heb je toch hetzelfde probleem ? (of moet je dan in Hex gaan geven?).

[Verwijderd]

Soultaker schreef op 14 July 2003 @ 22:55:
[...]

Inderdaad, dat lijkt me ook de eindconclusie. Het was wat moeilijk om daar op uit te komen, omdat je zo'n ongebruikelijke situatie beschrijft.

Overigens heb je bij jouw notatie een groot probleem als unicode karakters van elke grootte toegestaan zijn. Hoe detecteer je in de string "\0234" het verschil tussen '\0234' (1 karakter) en '\023', '4' (2 karakters)? Als na de \0 altijd twee cijfers volgen, of na de unicode notatie gegarandeerd geen cijfer kan volgen, is dat natuurlijk geen probleem,

Heb het nog niet meegemaakt dat er een '4' na een '\023' komt waarbij het 2 afzonderlijke chars zijn. Maar goed, ik weet wat ik nu moet doen Bedankt en wat mij betreft mag ie offtopic

[MSalters]

Soultaker schreef op 14 July 2003 @ 22:51:
Dat is niet helemaal waar. Als je een getal onder de 256 intoetst (zonder 0 ervoor!) dan interpreteert Windows dat als een (extended) ASCII karakter. Unicode karakter 128 is namelijk het Euro-teken (ALT-0128: €), terwijl het extended ASCII karakter 128 inderdaad de hoofdletter C met cedille is (ALT-128: Ç). De reden hiervoor is dat dit gedrag backward compatible is met DOS, waarin je alleen extended ASCII had. De extended ASCII karakters hebben in Unicode andere nummers (hoewel de normale ASCII karakters, onder de 128, wel hetzelfde getal hebben, waardoor bijvoorbeeld ALT-77 hetzelfde is als ALT-077).

Bijna, maar ook niet helemaal. ALT-abc (3cijfers) is ASCII plus Windows karakterset uitbreiding. Dat is niet "Extended ASCII", (verwarrende term; ASCII is op 20 incompatibel manieren uitgebreid). ALT-0abc zou Unicode moeten zijn, maar omdat het maar 3 cijfers zijn kan de Euro (Unicode 0x20AC) niet zo ingevoerd worden, dus hebben ze unicode karakter 128 maar opgeofferd.

www.unicode.org heeft code charts op www.unicode.org/charts/PDF/ maar mijn Acrobat crasht daarop

[ Voor 7% gewijzigd door MSalters op 15-07-2003 16:45 . Reden: IE crash :( ]