I've looking through How to escape the equals sign in properties files but didn't find my answer.
I have a Java Properties File that includes sets such as:
SOME_KEY = SOME_VALUE
This is normal. However, some of the values actually contain escape/control characters, such as URL's. This properties file is to be hand edited by a user on a rare occasion. I want the user to be able to simply paste in a URL and not worry about special rules, etc.
So I have this showing in my file now:
SOME_KEY = http://www.example.com/something.asp?some=
where some= is the base of dynamic URL where something after the = will cause the URL to respond differently.
From reading http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html it doesn't seem to make mention of needing to escape any escape/control characters after the first unescaped = or : is encountered, but I need/want to make sure.
I know that if my KEY had one of those characters present, then it would have to be escaped otherwise it'd be misread... such as:
SOME\=KEY = SOME_VALUE
Would make for a literal SOME=KEY as the key value.
In this above situation, excluding the obvious escaping of the KEY, is it necessary to hand-escape the values?
After the first = without escape, no.
If you use eclipse, you might want install the JBoss Tools Properties Editor. You not need to worry about escaping values manually as you mention SOME=KEY or Unicode. However, the pluging escapes the characters to avoid reading and coding problems.
http://www.jboss.org/tools
Related
I have a properties file, and I need to use the / forward slash in some of my keys.
e.g.
app.module/hdr.key1=value 1
app.module/hdr.key2=value 2
I just have no choice but need to do it that way. Please advise is this achievable and how to do this?
Thanks.
The use of forward slashes will not cause a problem. To understand why, I suggest you read a critique of the syntax used in Java properties that I wrote. In essence, what you need to know is the following:
Leaving aside edge cases (comment lines, blank lines and escape sequences), the syntax of a name=value pair permits almost any character (including forward-slashes) in the name.
The = can actually be any of the following: (1) = (optionally preceded and/or followed by whitespace); (2) : (optionally preceded and/or followed by whitespace); or (3) just whitespace. So, yes name=value is equivalent to name:value and also to name value.
All escape sequences begin with the backslash character. For details of the escape sequences, I suggest you do a Google search for java.util.Properties to find online documentation for that class, and look at the long description of the load(InputStream) method.
Using Jooq generator, by Gradle plugin, I am getting now with POJOs and tables not only classes with normal names, bu also heaps of files whose names start by bin$.
They are not necessary, for only yesterday the generator did not make these files. And everything works OK with or without them. But I don't want the project to be littered with tens of excessive files.
Since 10'th version, Oracle puts the dropped tables to the recycle bin. They have names starting by Bin$. So, JooQ simply makes classes for dropped tables. That could be blocked in two ways: To stop use recycling bean in Oracle or to filter the tables for which the Jooq generator makes classes.
ALTER SYSTEM SET RECYCLEBIN = OFF DEFERRED;
purge dba_recyclebin;
or to change the generator setting (the example is for Gradle)
generator{
...
database {
...
excludes = '(?i:BIN\\$.*)'
Edit: Finally after several attempts (by Lukas) and checks (by me) Lukas had found the correct meaning for excludes. Its form, IMHO, has the only explanation - JOOQ doesn't work with regex'es correctly, for Groovy does not parse the strings in single quotes.
jOOQ's <excludes/> setting is a Java regular expression. You have to properly form it like this:
excludes = '(?i:BIN\\$.*)'
Explanation:
Use (?i:...) for case-insensitivity. Just in case. Pun intended.
Use \\ before the $ sign because the $ means "end of line" in regular expressions. You want to escape that. And because Groovy/Gradle parses (as in "look for escape sequences") your string, you need to escape the backslash too, for it to reach the Java Pattern.compile() call
Use .* to indicate that after the $, you want to match any number of characters. . = any character and * = any number of repetitions
I have a property file which may/ may not contain unicode escaped characters in the values of its keys. Please see the sample below. My job is to ensure that if a value in the property file contains a non-ascii character, then it should be unicode escaped. So, in the sample below, first entry is OK, all entries like the second entry should be removed and converted to like the first entry.
##sample.properties
escaped=cari\u00F1o
nonescaped=cariño
normal=darling
Essentially my question is how can I differentiate in Java between cari\u00F1o and cariño since as far as Java is concerned it treats them as identical.
Properties files in Java must be saved in the ISO-8859-1 character set for Java to read them properly. That means that it is possible to use special characters from Western European languages without escaping them. It is not possible to use characters from other languages such as those from Easter Europe, Russia, or China without escaping them.
As such there are only a few non-ascii characters that can appear in a properties file without being escaped.
To detect whether characters have been escaped or not, you will need to open the properties file directly, rather than through the Properties class. The Properties class does all the unescaping for you when you load a file through it. You should open them using the File class or though System.getResourceAsStream as an InputStream. Once you do so you can scan through the input stream one byte at a time and ensure that all bytes are in the 0x20-0x7E range plus new lines \r and \n which is the ASCII range of characters you would expect in a properties file.
I would suggest that your translators don't try to write properties files directly. They should provide you with documents like spreadsheets that you convert into properties file. Or they could use a translation editor such as Attesoro (which I wrote) to let them save the properties files properly escaped.
You could simply use the native2ascii tool, which performs exactly this conversion (it will convert all non-ASCII characters to escapes but leave existing escapes intact).
Your problem is that the Java Properties class decodes the properties files, assuming ISO-8859-1 encoding, and parsing escaped unicode characters.
So from a Properties point of view, these two strings are indeed the same.
I believe if you need to differentiate these two, you will need to write your own parser.
It's actually a feauture that you do not need to care by default. The one thing that strikes me as the most odd is that the (only) encoding is ISO-8859-1, probably for historical reasons.
The library ICU4J seems to be what you're looking for. See the Normalization page.
I am getting file path in eclipse plugin using org.eclipse.swt.widgets.FileDialog and saving the path in XML files.
In web.xml , path is stored as below (I can't change backsladh to forwardslash or escape backslash since the value is coming from SWT FileDialog)
<init-param>
<param-name>filePath</param-name>
<param-value>c:\new\demo\next\version.txt</param-value>
</init-param>
In my filter , i have below code in init() method but am not able to get File reference due to special characters
String filePath = filterConfig.getInitParameter("filePath");
// Tried filePath.replace('\\','/') --> Didnot work since \n is a single character
File f = new File(path)
i could not get the actual path since \n is considered as new line.
That suggests that whatever's reading the file is assuming escaping which simply isn't the case.
Unfortunately, you haven't told us what code is used to write the data or the code used to read the data. Is it under your control in either path?
Basically you need to be escaping in the same way as you unescape - so either you can escape c:\new\demo\next\version.txt to c:\\new\\demo\\next\\version.txt when you're writing the data, or you can remove the code which tries to unescape when you're reading the data.
Note that if you literally tried:
string.replace('\\', '/');
then that certainly won't help at all - as you're ignoring the return value. If you tried
string = string.replace('\\', '/');
then that should have performed the relevant replacements, but you didn't say where you were trying to do that, or in what way it didn't work.
I would actually treat the forward vs back-slashes as a red herring here: fundamentally you need to escape in the same way as you unescape. Replacing backslashes with forward slashes may help for filenames, but you'll just get problems elsewhere in cases where you can't just perform that replacement.
I am getting file path in eclipse plugin using
org.eclipse.swt.widgets.FileDialog and saving the path in XML files.
In web.xml , path is stored as below (I can't change backsladh to
forwardslash or escape backslash since the value is coming from SWT
FileDialog)
The SWT File Dialog does not write web.xml files. You are doing that, so you can fix the backslashes. Change them to forward slashes.
I have below code in init() method but am not able to get File
reference due to special characters
that did not work because \n is considered a single character [from one of your comments]
That implies that the data is wrong in the web.xml file. Nothing you can do in code can fix that. This is not a coding question. You don't need to process backslashes in Java. The compiler already does that, and so in this case did the XML parser in the web-app container. You need to get the file format correct up front.
Is there any real way to represent a URL (which more than likely will also have a query string) as a filename in Java without obscuring the original URL completely?
My first approach was to simply escape invalid characters with arbitrary replacements (for example, replacing "/" with "_", etc).
The problem is, as in the example of replacing with underscores is that a URL such as "app/my_app" would become "app_my_app" thus obscuring the original URL completely.
I have also attempted to encode all the special characters, however again, seeing crazy %3e %20 etc is really not clear.
Thank you for any suggestions.
Well, you should know what you want here, exactly. Keep in mind that the restrictions on file names vary between systems. On a Unix system you probably only need to escape the virgule somehow, whereas on Windows you need to take care of the colon and the question mark as well.
I guess, the safest thing would be to encode anything that could potentially clash (everything non-alphanumeric would be a good candidate, although you migth adapt this to the platform) with percent-encoding. It's still somewhat readable and you're guaranteed to get the original URL back.
Why? URL-encoding is already defined in an RFC: there's not much point in reinventing it. Basically you must have an escape character such as %, otherwise you can't tell whether a character represents itself or an escape. E.g. in your example app_my_app could represent app/my/app. You therefore also need a double-escape convention so you can represent the escape character itself. It is not simple.