[Java] Encoding Character Set probleem

[Twazerty]

Ik heb een probleem en ik krijg het niet opgelost. Een gebruiker van mijn programma (AVCHDCoder) heeft zijn windows versie in het Hebreeuws. Dit is zijn pad naar Documents:
C:\Users\עומר מעין\Documents\

Het probleem ontstaat op het moment dat ik met ProcessBuilder een exe aanroep. Er komt geen resultaat terug zodra het Hebreeuws in de Structuur staat.

Dit is de code:

Java:

public ExecuteCommands(String... parameters){
       try {
            for(String i: parameters){
                System.out.println(i);
            }
            pb = new ProcessBuilder(parameters).start();
            InputStream is = pb.getInputStream();
            InputStreamReader isr = new InputStreamReader(is);
            br = new BufferedReader(isr);
            String line;
            while ((line = br.readLine()) != null) {
                arraylist.add(line);
                System.out.println(line);
            }
            br.close();
        } catch (IOException ex) {
            //Error
        }
}

De aanroep gaat als volgt:

ExecuteCommands ec = new ExecuteCommands("\"D:\\tools\\MediaInfo.exe\"", "\"--Inform=file://D:\\tools\\input.txt\"", "\"C:\\Users\\עומר מעין\\Documents\\Film.mkv\"");

Zodra hij de eerste for loop uitvoert klopt het al niet helemaal. De hebreeuwse tekst word niet correct afgedrukt. Dit resulteerd in zoiets: ?￥￮? ￮?￩￯ of vraagtekens. En zodra de while loop uitgevoerd word komt er geen resultaat. Vermijd ik Hebreeuwse tekst dan werkt het perfect en krijg ik een hoop resultaten.

Ik heb de Virtual Machine al gestart met UTF-8/16 en zelfs de Hebreewse encoding set. In geen gevallen word de tekst correct afgedrukt. En in geen gevallen krijg ik resultaat in de while loop.

Als ik met de debugger erdoorheen loop dan kloppen alle strings perfect. De strings bevatten gewoon de Hebreeuwse tekens en ook labels in de GUI laten de tekens correct zien.

Ik krijg niet gevonden hoe ik het opgelost krijg. Het gaat uiteraard ook fout bij andere talen zoals japans ed. Al heb ik dat niet geprobeerd. Wie kan mij hier meer over vertellen en hoe krijg ik dit opgelost?

PS: Het hebreews geschrift is van rechts naar links

[bloody]

Zie hier: http://java.sun.com/j2se/...am,%20java.lang.String%29

Gebruik dus de andere constructor die als 2e parameter een charset heeft.

[roy-t]

Dat is heel vreemd aangezien Java normaal helemaal in Unicode werkt waar Hebreeuwse tekens netjes in zitten. Het lijkt meer op iets geks met het VM dan een fout van jouw code. (Je googelt nergens met strings ofzo). Helemaal gek is dat het in debug wel goed gaat, het VM kan het dus wel. Maar misschien kun je nog iets veranderen aan je BufferedReader, in C# hebben soortegelijke readers vaal een overload waar je de encoding in kan aangeven, misschien zit er ook een InputStreamReader achtig iets in java waarbij dat kan?

Edit: wat Bloody zegt dus

[Twazerty]

Idd zoals bloody aangeeft.
De volgende character sets werken niet:
Cp862 (PC Hebrew)
UTF-8 (en UTF8 ook gebrobeerd)
Cp1255 (Windows Hebrew)
UTF-16
UnicodeBigUnmarked

Alleen ingesteld in de InputStreamReader

[Confusion]

Twazerty schreef op donderdag 10 september 2009 @ 18:55:
[..]

Allereerst: je moet onderscheid maken tussen de begrippen character encoding en character set. De character encoding bepaalt welke bytes een bepaalde waarde coderen. De character set bepaalt welk karakter aan die waarde gekoppeld is.

Dat pad naar Documents wordt ergens vandaan gelezen. Op het moment dat je die string inleest, dan moet je erbij vertellen welke encoding en character set die string voorstelt. Het is immers niets dan een serie bytes, die zonder die informatie niets voorstelt dan wat 1-en en 0-en. Vertel je dat niet, dan gebruikt hij de default encoding en character set van het systeem en het is maar de vraag of dat allemaal goed staat en of voor alle doeleinden hetzelfde gebruikt wordt. Het eerste wat je moet doen is achterhalen welke encoding en character set Java standaard gebruikt op dat systeem. Het tweede wat je moet doen is achterhalen wat de encoding van de string is en welke character set daarmee gerepresenteerd wordt. Als dat allemaal hetzelfde is, dan is het een ander probleem, maar waarschijnlijk is dit het probleem al.

Nadat het is ingelezen, is het omgezet naar een string die unicode middels de UTF-16 encoding representeert, maar als je programma denkt dat hij pakweg ISO-8859-1 aan het lezen is, dan krijg je een perfect UTF-16 representatie van de verkeerde unicode characters. Dat Java unicode en allerlei encodingen ondersteunt en gebruikt betekent alleen maar dat het het goed kan doen. Het betekent allerminst dat het het automatisch goed doet.

[ Voor 15% gewijzigd door Confusion op 10-09-2009 19:20 ]

[Twazerty]

Windows in nederland is cp1252 als ik de virtual machine vraag welke encoding set hij draait.

Als ik dat naar UTF8 zet door de VM in stellen met -Dfile.encoding=UTF8 en de InputstreamReader ook op UTF8 dan zou dat toch moeten werken? Maar ook dat werkt niet.

Strings kun je idd een character set meegeven maar dan moet je de string een array aanleveren.

[Confusion]

Die string kan onmogelijk de cp1252 encoding hebben, aangezien die 8-bits encoding enkel een character set met 256 characters kan encoden.

Bovendien: als je zegt: -Dfile.encoding=UTF8, dan beweer je dat files de UTF-8 encoding hebben. Dus gaat hij bij het inlezen de bytes als een UTF-8 representatie van unicode characters interpreteren. Maar zijn die bytes een UTF-8 representatie van unicode characters?

Karaktersets zijn een hoofdpijnprobleem. Browsers verwachten en ondersteunen bepaalde encodings/characters sets, webservers verwachten en ondersteunen bepaalde encodings/characters sets, het onderliggende OS verwacht en ondersteunt bepaalde encodings/characters sets en de programmeertaal waarmee je ze wilt benaderen heeft weer andere karakteristieken. En dan hebben we het nog niet eens over het geval waarin een database bijvoorbeeld een deel van de data in cp1252 bevat, terwijl de database zelf beweert dat de encoding van al zijn data iso-8859-1 is en je onmogelijk de data met een cp1252 encoding uit de database kan lezen. Hier moet je hard over nadenken en je moet het soms voor jezelf van byte tot byte uitschetsen voor je overzicht krijgt. Bytes zijn een stuk eenvoudiger

[ Voor 53% gewijzigd door Confusion op 10-09-2009 21:18 ]

[Twazerty]

Confusion schreef op donderdag 10 september 2009 @ 19:38:
Die string kan onmogelijk de cp1252 encoding hebben, aangezien die 8-bits encoding enkel een character set met 256 characters kan encoden.

Bovendien: als je zegt: -Dfile.encoding=UTF8, dan beweer je dat files de UTF-8 encoding hebben. Dus gaat hij bij het inlezen de bytes als een UTF-8 representatie van unicode characters interpreteren. Maar zijn die bytes een UTF-8 representatie van unicode characters?

Als je niets insteld dan pakt Java hetgeen wat op je Windows draait. In ons geval is dat Cp1252.
Hoe kan ik weten in welke set de naam in thuishoort? Ik heb gewoon een folder op mijn pc staan die zo heet. Daarin staat een file met normale tekens.
Eigenlijk heb ik een oplossing nodig waarbij ik iedere character ernaartoe kan smijten ongeacht welke windows je hebt en wat de filename is van de file. (MediaInfo de Gui accepteerd de file wel gewoon.)
De filename bestaat dus eigenlijk uit 2 soorten. Onze soort en De hebreewse tekst door elkaar heen.

Edit: Ik word er ook een beetje moedeloos van van al die encoding sets. Echt een ramp en dit is niet de eerste keer dat ik ruzie heb met het encoding type.

[ Voor 6% gewijzigd door Twazerty op 10-09-2009 19:46 ]

[bloody]

Even nog die -Dfile.encoding. Volgens mij heeft dat niets te maken met je probleem. Je probleem is niets meer dan een string die de filenaam voorstelt toch? De file.encoding parameter gaat volgens mij over de inhoud van de file.

Ook interessant is hoe je aan die string komt.. heeft iemand dat gemaild? is tijdens het mailen informatie verloren gegaan? Bv andere encoding?

[Twazerty]

bloody schreef op donderdag 10 september 2009 @ 19:49:
Even nog die -Dfile.encoding. Volgens mij heeft dat niets te maken met je probleem. Je probleem is niets meer dan een string die de filenaam voorstelt toch? De file.encoding parameter gaat volgens mij over de inhoud van de file.

Ook interessant is hoe je aan die string komt.. heeft iemand dat gemaild? is tijdens het mailen informatie verloren gegaan? Bv andere encoding?

Deze string heb ik gecopieerd vanuit de email naar een windows folder op mijn pc. Vervolgens plaatste ik daar een normale file in. De file stop ik in mijn video converter en middels File.getPath() haal de het pad van de source file op. (Komt uit een JFileChooser)

Zoals ik al zei staat de tekst (goed) in de string als ik er met de debugger inkijk.
En als test heb ik even mijn pc ingesteld op het Hebrew keyboard en daarmee een folder gemaakt in windows. Dus geen conversie problemen in de email.

Als ik -Dfile.encoding instel word de afgedrukte string wel in een andere vorm uitgeprint.

String stelt het complete pad voor inclusief filenaam.

Edit: Nu ik verder denk denk ik ook dat -Dfile.encoding er niets mee te maken heeft omdat java op een hebreeuwse windows automatisch cp1255 pakt. De taal van de machine. Dus ik denk dat het specifiek in die ProcessBuilder zit.

Kom er nu ook achter dat tsMuxer ook geen files ondersteund met hebreeuwse tekst erin. Ben gelukkig niet de enige.

[ Voor 15% gewijzigd door Twazerty op 10-09-2009 21:29 ]

[terje7601]

Um, waarom niet eerst proberen om het werkende te krijgen zonder Java? Weet je zeker dat MediaInfo hebreeuws ondersteunt? Lukt het vanuit een command prompt wel?

[Twazerty]

terje7601 schreef op vrijdag 11 september 2009 @ 16:13:
Um, waarom niet eerst proberen om het werkende te krijgen zonder Java? Weet je zeker dat MediaInfo hebreeuws ondersteunt? Lukt het vanuit een command prompt wel?

Daar zat ik vanmiddag ook aan te denken. Om vage redenen werkt het gewoon via cmd.

Zodra je hebreeuws plakt in cmd dan maakt hij er vraagtekens van. (Precies zoals java het ook afdrukt) Maar ik krijg gewoon resultaat terug ondanks dat er vraagtekens staan ipv de hebreeuwse tekst.

Ik heb 2 andere programma's die ik gebruik ook getest met hebreeuwse tekst.
tsMuxer GUI lust de file niet.
ImgBurn lust hem wel maar maakt geen output. Werkt dus ook niet.

Ik denk dat dit een probleem is wat ik niet op kan lossen. Ik heb ook naar enkele van mijn concurenten gekeken maar ook zij kunnen er niet mee overweg.

[Confusion]

Twazerty schreef op donderdag 10 september 2009 @ 19:59:
Edit: Nu ik verder denk denk ik ook dat -Dfile.encoding er niets mee te maken heeft omdat java op een hebreeuwse windows automatisch cp1255 pakt. De taal van de machine. Dus ik denk dat het specifiek in die ProcessBuilder zit.

Een OS kan voor verschillende onderdelen van het systeem verschillende encodings en character sets specificeren. Als iemand Hebreeuwse bestandsnamen kan invoeren en kan weergeven, dan weet het OS dat het de bytes op schijf als, bijvoorbeeld, UTF-8 moet interpreteren. Dat gegeven is dus ergens te vinden. In Windows ongetwijfeld ergens in de registry. Dit is geen probleem van Java of van de ProcessBuilder. Die doen precies wat je ze vraagt en als je ze niet vertelt waar ze mee te maken hebben, dan houdt het redelijk op. -> Zie BalusC, wel dus.

[ Voor 11% gewijzigd door Confusion op 13-09-2009 09:44 ]

[BalusC]

De oplossing zit voorlopig in JNI. Zie ook http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4947220.

edit:

Deze blog bevat veel nuttige informatie: http://illegalargumentexc...windows-command-line.html.

Succes

[ Voor 44% gewijzigd door BalusC op 13-09-2009 17:12 ]