Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Runtime.exec() and character encodings

<email@hidden> wrote:

>I'm trying to tag an MP3 file by running 'lame' from a Java program. I want
>to use accentuated characters in the tags, and the problem is that the file
>is not correctly tagged when running the program on the Mac (when I open
>the tagged file with iTunes I see strange characters instead of the
>accentuated ones).
>
>If I run the program in a Red Had Linux, it works (I see the tags correctly
>in iTunes).
>
>Below is the source code of the program. I have this source code saved in a
>file using ISO-8859-1 encoding (because I want to be able to compile and
>run this program in Red Hat too, without problems with special characters).

You should not use a specific encoding of a source-file unless you can also
guarantee that all transfers of that source will maintain that encoding. I
doubt that FTP or ZIP or whatever else you use to move files around will
always provide such guarantees.

Instead, you should use the Unicode escape representation for Java source
code. For example:
"Fa\u00E7ade"

is the word "Facade" with a cedilla-C character.

Using Unicode escapes in source is a pain, but it probably won't be changed
very often, so it's a one-time cost. In your case, I suspect that you
don't really want to put the exact same accented text on every tag of every
MP3 you process. That would be the only reason for hard-coding the
accented text into a Java source file. If that *IS* what you want, then
the effort of doing Unicode escapes in the source is well worth the gain in
portability and flexibility of eliminating a specific charset encoding for
the source.


>I've tried changing the file.encoding property to ISO-8859-1 (instead of
>the default MacRoman), but with no luck (I thought that maybe this would
>affect how the parameters are passed to 'lame' from the Java program, i.e.
>that this way Java would convert the parameters to ISO-8859-1 before
>passing them to lame).

The "file.encoding" property has no effect on how args are passed to
processes with exec(). That is an inherently platform-specific thing, and
is beyond your program's control, as far as I can tell.

On Mac OS X, args passed to exec() are always encoded as UTF-8. It is then
up to the executed program to know that the args are in UTF-8, and deal
with them accordingly.

If the LAME program is blindly treating its args as some other encoding,
then you need to change it so it uses UTF-8 (or a specified encoding), or
you need to get the information to LAME in a way it expects.

If LAME can read parameters from a file or a piped input stream, then you
can precisely control the encoding of those bytes, and you can then produce
whatever it is that LAME expects.

If LAME can't do such a thing, and it can't be changed to decode args as
UTF-8, then you'll have to write a C program that does the translation and
then calls the C function execve() with the converted args. You would then
exec() that "adapter" program from Java. Clearly, you can't write such a
program in Java, because you wouldn't be able to exec() another program
with anything but UTF-8 args being passed.

I notice that the specification for ID3v2.4.0 tags accepts UTF-8 as a
possible encoding, while ID3v2.3 does not.
<http://www.id3.org/develop.html>


On a side note, you should know that your program as given can deadlock if
LAME produces more than a certain amount of output on its stdout stream. I
don't know whether LAME can or will do this, but you should know about the
reason for the deadlock. Search the archives for the recent list messages
containing "system_profiler".

-- GG
_______________________________________________
java-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/java-dev
Do not post admin requests to the list. They will be ignored.



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.