how to load a properties file with non-ascii in ant - ant

Suppose I have a properties file test.properties, which saved using utf-8
testOne=测试
I am using the following ant script to load it and echo it to another file:
<loadproperties srcFile="test.properties" encoding="utf-8"/>
<echo encoding="utf-8" file="text.txt">${testOne}</echo>
When I open the generated text.txt file using "utf-8" encoding I see:
??
What's wrong with my script?

Use "encoding" and "escapeunicode" together. It's work fine.
<loadproperties srcfile="${your.properties.file}" encoding="UTF-8">
<filterchain>
<escapeunicode />
</filterchain>
</loadproperties>

I found a work around, but I still doesn't understand why the org one doesn't work:
<native2ascii src="." dest=".">
<mapper type="glob" from="test.properties" to="testASCII.properties"/>
</native2ascii>
<loadproperties srcFile="testASCII.properties"/>
Then the echo works as expected.
I don't know why the encoding in loadproperties doesn't work.
Can anyone explain?

Try it this way:
<loadproperties srcfile="non_ascii_property.properties">
<filterchain>
<escapeunicode/>
</filterchain>
</loadproperties>
Apparently, InputStreamReader that uses the ISO Latin-1 charset, which kills your non-ascii characters. I ran into the same issue w/Arabic.

What editor were you using and what platform are you on?
Your generated property file might actually be good, but the editor you're using to examine it may be incapable of viewing it. For example, on my Mac, the VIM command line editor can view it (which surprises me), but in Eclipse, it looks like this:
testOne=������
If you're on Unix/Linux/Mac, try using od to dump your generated file, and examine the actual hex code to see what it should be.
For example, I copied your property file, and ran od on a Mac:
$ od -t x1 -t c test.property
0000000 74 65 73 74 4f 6e 65 3d e6 b5 8b e8 af 95 0a
t e s t O n e = 测 ** ** 试 ** ** \n
Here I can see that the code for 测 is 36 b5 8b and 试 is e8 af 95 which is the correct UTF-8 representation for these two characters. (Or, I at least think so. It shows up correctly in the Character Viewer Mac OS X panel).

The right answer is pointed to in this comment by David W.:
how to load a properties file with non-ascii in ant
Java Property Files must be encoded in ISO-8859-1:
http://docs.oracle.com/javase/7/docs/api/java/util/Properties.html
But Unicode escape sequences like \u6d4b can/must be used to encode unicode characters therein.
Tools/ANT-Targets like <native2ascii>, generating ascii-encoded files from natively maintained ones, can help here.

You can write your own task that reads properties from your default java character encoding for your OS (mine is utf-8), instead of converting your property files to unreadable unicode-escaped ASCII files (designed by people who read and write only English). Here's how to do it by copying and modifying Property.java from Ant's source code to your own package (e.g. org.my.ant). I used Ant 1.10.1.
Download Ant's source code in your format of choice from here:
http://ant.apache.org/srcdownload.cgi
Copy src/main/org/apache/tools/ant/taskdefs/Property.java to your own project (such as a new Java project), in org/my/ant/Property.java)
replace:
package org.apache.tools.ant.taskdefs;
with:
package org.my.ant;
Fix any imports needed by the package change. I just needed to add:
import org.apache.tools.ant.taskdefs.Execute;
In the method:
loadProperties(Properties props, InputStream is, boolean isXml)
replace:
props.load(is);
with:
props.load(new InputStreamReader(is));
In your project's resources folder (could be the same as your source folder), add the file org/my/ant/antlib.xml, with the content:
<?xml version="1.0" encoding="UTF-8"?>
<antlib>
<taskdef name="property" classname="org.my.ant.Property"/>
</antlib>
Compile this project (Property.java + antlib.xml).
Put the resulting jar in Ant's classpath, as explained here:
http://ant.apache.org/manual/using.html#external-tasks
Then use it in a build.xml file as follows:
<?xml version="1.0" encoding="UTF-8"?>
<project name="example"
xmlns:my="antlib:org.my.ant"
default="print"
>
<my:property file="greek.properties" prefix="example" />
<target name="print">
<echo message="${example.a}"/>
</target>
</project>
The file greek.properties contains:
a: ΑΒΓ

Related

Replacing value in an XML file using Ant

I'm trying to automize my android build process. For that, I want to change the app name in an XML file. the code is something like this
<resources>
<string name="app_name">Realta Connections</string>
</resources>
Now I want to replace the name 'Realta Connections' by something else at build time, a name which I would give at build time. The name can be 'Realta Connections' or anything else, so I need to detect the name="app_name" and replace the content inside it. I tried looking for how to do it but couldn't find the precise way. How can I do that? Please help.
It is probaly easiest to have a fixed value, which will be replaced. This will allow the use of the replace task:
You need replacetoken/replacevalue and the Strings inside ![CDATA[]] because of the xml characters.
<replace casesensitive="false"
file="../KS.build/ivy.properties">
<replacetoken><![CDATA[<string name="app_name">Realta Connections</string>]]></replacetoken>
<replacevalue><![CDATA[<string name="app_name">Something else</string>]]></replacevalue>
</replace>
Otherwise there is no normal ant solution (repleaceregex doesn't allow nested CDATA replacements).
Links:
Ant replace task
I know this question is quite old, but here is an idea. This seems like it's not really a purely ant solution, but you can embed a script in ant using the <scriptdef> tag.
Here is a function you can use to search for something in an XML file and store the result in a property:
<scriptdef name="xpath-query" language="javascript">
<attribute name="query"/>
<attribute name="xmlfile"/>
<attribute name="property"/>
<![CDATA[
importClass(java.io.FileInputStream);
importClass(javax.xml.xpath.XPath);
importClass(javax.xml.xpath.XPathConstants);
importClass(javax.xml.xpath.XPathFactory);
importClass(org.xml.sax.InputSource);
importClass(java.lang.System);
var exp = attributes.get("query");
var filename = attributes.get("xmlfile");
var xpath = XPathFactory.newInstance().newXPath();
var input = new InputSource(new FileInputStream(filename));
var value = xpath.evaluate(exp, input, XPathConstants.STRING);
self.project.setProperty( attributes.get("property"), value );
System.out.println("Copied this value:" + value + " to this property:" + attributes.get("property"));
]]>
</scriptdef>
Then you could get the current name of the app by using the xpath-query task you just defined:
<xpath-query query='pathToResources\resources\string[#name="app_name"]' xmlFile="app.xml" property="appName" />
Then the app name will be stored in the property appName.
From there you could do regex replace on the xml file using the app name.
<replaceregexp file="app.xml" match="${appName}" replace="${newAppName}" />
The potential down-side of this particular approach is that if you have the same app name string somewhere else in the XML file the regex replace may replace something you didn't intend.
You could probably define the <scriptdef> to do the replacement rather than just storing what was found in a property, but I had this portion of code handy already.
When dealing with XML in ANT I always recommend the xmltask. For your requirement see xml task manual replace
A little Xpath knowledge won't hurt, see:
http://zvon.org/xxl/XPathTutorial/
http://www.w3schools.com/xpath/
try this code, it works for me
<target name="change-app-name">
<replaceregexp file="res/values/strings.xml" match='name="app_name"(.*)'
replace='name="app_name">Something Else<\/string>'/>
</target>

Native2Ascii task not working

I'm trying to use the native2ascii ant task but it seems that is not doing anything. Here's my ant task:
<target name="-pre-init">
<native2ascii src="src/com/bluecubs/xinco/messages" dest="src/com/bluecubs/xinco/messages/test"
includes="**/_*.properties"/>
<copy todir="src/com/bluecubs/xinco/messages">
<fileset dir="src/com/bluecubs/xinco/messages/test"/>
</copy>
<delete dir="src/com/bluecubs/xinco/messages/test" />
</target>
I did the copy part to see if it was an overwriting issue but the files come out exactly the same.
This is the output I get when running the task:
Converting 12 files from Z:\Netbeans\Xinco\2.01.xx\Xinco\src\com\bluecubs\xinco\messages to Z:\Netbeans\Xinco\2.01.xx\Xinco\src\com\bluecubs\xinco\messages\test
Copying 12 files to Z:\Netbeans\Xinco\2.01.xx\Xinco\src\com\bluecubs\xinco\messages
Deleting directory Z:\Netbeans\Xinco\2.01.xx\Xinco\src\com\bluecubs\xinco\messages\test
Edit:
Additional information:
OS: Windows 7 (but answer should work on any OD)
File encoding: Western (ISO-8859-1) obtained with this article.
Files location
Any idea?
native2ascii converts native characters like áéí to escaped unicode sequences. It means that á will be \u00e1, é -> \u00e9 and í -> \u00ed. After running native2ascii your files will be standard ASCII files which are more portable.
native2ascii does not touch the characters which are already in the escaped unicode form. Your properties files are already in escaped unicode form so it does not change anything. For example _XincoMessages_cz.properties contains this line:
general.accessrights=opr\u00E1vnen\u00ED k pr\u00EDstupu
It's escaped unicode. The nonescaped unicode form is this:
general.accessrights=oprávnení k prístupu
Wordpad vs. Netbans: When you open the properties files with Wordpad it opens it as a simple text file and shows \u00e1 as \u00e1. It does not convert it back to á. Netbeans does this conversion and you see the 'á' character. Furthermore, it writes it back to the disk as \u00e1 (!) when you save the file. To see the raw files use for example a Total or Double Commander which doesn't do any converting. (Note that Netbeans does this conversion just for properties files.)
If you put for example an á character to your _XincoMessages_cz.properties file it will be changed to \u00e1 if your run your ant task. Of course now don't use Netbeans for the editing, a simple notepad will do.
Loading properties files in java converts the escaped unicode characters to real unicode characters. An example:
final Reader inStream = new FileReader("..../_XincoMessages_cz.properties");
final Properties properties = new Properties();
properties.load(inStream);
System.out.println(properties.getProperty("general.accessrights"));
It prints:
oprávnení k prístupu
The ASCII/escaped unicode form in properites files is usually handled well by java applications. Finally, I think your properties files are good in their current format.
It ended being a view issue. Looking the files in a raw editor (i.e. Wordpad) showed that the files were already converted by the task. Viewing them from NetBeans shows them the same.

Writing a path to a property file using ant

I am writing a file path to a property file using ant property file task,below is my code snippet of ant
<propertyfile file="WeblogicDomain.properties" comment="Weblogic Properties Below">
<entry key="path" value="C:/bea"/>
</propertyfile>
In the output properties i.e.., WeblogicDomain.properties file the path varies as shown below
path=C\:/bea
i was puzzled with this, is there a solution to resolve this & place the exact path as mentioned in source code
My ant version : 1.6.5
This is how java.util.Properties works. The colon : and equals = characters are used as name value delimiters so colons are escaped when part of the key or value and not the delimiter.
See java.util.Properties.load(Reader) for more.

Ant Fileset Expansion doesn't work

I get a very confusing reaction from my ant build-file and I'm wondering whether I'm just not clever enough or this might actually be a bug.
I've got the following property set globally in my project:
<property name="lib.dir" location="lib"/>
Then I'll try to add some files out of this directory into a jar file via fileset (more than one resource):
<fileset dir="${basedir}" includes="lib/*filename*"/>
There should be (and exist) 3 different libraries, which are matched that way. However, if I try to use the following, it doesn't work and no files are included:
<fileset dir="${basedir}" includes="${lib.dir}/*filename*"/>
Note that the only differences lies in the usage of the global property. Now the simple question: why does the first version work as advertised, but the second doesn't?
Please check the actual value of "lib.dir" just before and maybe after the task that uses the "fileset" expression. Just to make sure, that it hasn't been changed accidently after you've set it globally. The <echo/> task can help.
Maybe I got the solution. The description of the locationattribute is:
Sets the property to the absolute filename of the given file. If the value of this attribute is an absolute path, it is left unchanged (with / and \ characters converted to the current platforms conventions). Otherwise it is taken as a path relative to the project's basedir and expanded.
Simply use the value attribute instead of location. Here's a test script to show the difference:
<project name="test">
<property name="test1" location="lib"></property>
<property name="test2" value="lib"></property>
<target name="target" description="description">
<echo>${test1}</echo>
<echo>${test2}</echo>
</target>
</project>
The output on my system is as follows:
Buildfile: D:\Develop\workspace-jabber\scrapbook\build.xml
target:
[echo] D:\Develop\workspace-jabber\scrapbook\lib
[echo] lib
BUILD SUCCESSFUL
Total time: 307 milliseconds
I have found a clue to the answer, but not the whole thing yet.
I runned both versions of the fileset with ant -debug and here is what happens.
In the working, not-using-property version, I get the following output:
fileset: Setup scanner in dir [pathToDir] with patternSet{ includes: [lib/*filename*] excludes: [] }
whereas in the should-be-working-but-doesn't version I get:
fileset: Setup scanner in dir [pathToDir] with patternSet{ includes: [ [pathToDir]/lib/*filename*] excludes: [] }
As you can see, ant add's the [pathToDir] in the regexp, thus searching for
[pathToDir]/[pathToDir]/lib/*filename*
which obviously doesn't exist. Problem now: how do I have to modify my version to have it working properly?
When creating the property (is it done global or in a target?), does the directory lib exist? If not, the location attribute does not work - use a value attribute instead or better define the property after creating the directory.
As indicated above, the problem was that ${lib.dir} too contained the whole path, thus searching for [pathToDir]/[pathToDir]/lib/filename.
To clip away the unwanted [pathToDir] in the ${lib.dir} property, I now used the task. I got now the following, but imho not so nice looking solution:
<basename property="lib.dir.rel" file="${lib.dir}"/>
<fileset dir="${basedir}" includes="${lib.dir.rel}/*filename*"/>
P.S.: On a second look, I found that Andreas_D also found the right reason and a good suggestion yesterday, which I must have overlooked :-/

ant javac problem

compiling with javac ant task giving me errors that doesn't exists..
[javac] D:\mySrc\xx.java:1: illegal character: \65279
[javac] package com.x.y;
and there is no problem with the class xx.java
here is my compile target:
<javac srcdir="${src}/src" destdir="${bin}" encoding = "utf-8" classpathref="classpath" debug="true" debuglevel="lines,vars,source" deprecation="off" />
<copy todir="${bin}" overwrite="no">
<fileset dir="${src}/src" excludes="**/*.java"/>
</copy>
The issue is probably with the Byte Order Mark (the thing that looks like: ""). These three special characters at the beginning of the file indicate that the file is in UTF-8 encoding. I've seen a few cases where the Java tools don't deal with this very well. See if you can delete this from your file, or setup your editor to not insert this BOM in the file.
Here's a good thread on this topic:
http://groups.google.com/group/comp.lang.java.programmer/browse_frm/thread/adb0500c61451317?pli=1
Try searching google for "javac illegal character \65279". This should give you some additional resources.
check carefully your file, probably there is an extra character
I had to recreate the class and copy the code line by line ...
this is really a problem ...

Resources