]
Geoffrey De Smet updated JBRULES-2853:
--------------------------------------
Fix Version/s: 5.3.0.Beta1
(was: 5.2.0.Final)
ResourceFactory.newClassPathResource(drlPath) behaves differently on
different platforms (linux, windows): it parses the file with different encodings
------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-2853
URL:
https://issues.jboss.org/browse/JBRULES-2853
Project: Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Reporter: Geoffrey De Smet
Assignee: Edson Tirelli
Priority: Critical
Fix For: 5.3.0.Beta1
This really sucks for non English people :) English people write in pure ASCII, so they
don't suffer from this problem.
French, Dutch etc mix in Latin-1 chars. Russian, Chinese use something else.
The root problem: There are 2 ways to create an InputStream:
- with encoding = GOOD, use encoding "UTF-8" and there are no problems.
- without encoding: use the default platform encoding = BAD
-- Linux: UTF-8, Windows in Belgium: Latin-1, Windows in China: Chinese-1, Windows in
Sweden: Latin-2, ...
-- Java's InputStream should have just defaulted it on UTF-8
Proposition 1: Overloaded method which has an extra String encoding:
- ResourceFactory.newClassPathResource(drlPath, encoding)
- similar tactic as InputStream
Proposition 2: Keep it simple. We decide what a DRL file is.
Just like an XML file says to hell with the specified encoding, so can we.
Note: All XML files default to UTF-8 encoding, and you can overwrite it in a header in
the XML file itself (= self-describing): no need to mess around in the java code.
Same principle: All DRL files are default UTF-8 encoding. Optionally we can define an
encoding header later.
I strongly prefer proposition 2. The world has got enough encoding problems.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: