The java classes contining non-safe URI characters in names are incorrectly encoded

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a simple class with an accented character, ej Académico
2. Dump an object of this class using new Yaml().dump(obj)

What is the expected output? What do you see instead?

The expected output is !!Acad%c3%a9mico
The actual ouput is !!Académico

This throws an exception when traying to load the class back.

What version of the product are you using? On what operating system?

1.6

Original issue reported on code.google.com by manuel.s...@gmail.com on 12 May 2010 at 3:30

[GoogleCodeExporter]

Original comment by aso...@gmail.com on 12 May 2010 at 3:58

• Changed state: Accepted

[GoogleCodeExporter]

The patch from
http://groups.google.com/group/snakeyaml-core/browse_thread/thread/326d92c16987f
5ab
is taken.

To avoid encoding problems with the file name on different operating systems 
the test
is using static inner class.
(http://code.google.com/p/snakeyaml/source/browse/src/test/java/org/yaml/snakeya
ml/issues/issue67/NonAsciiCharsInClassNameTest.java)

The fix will be delivered in version 1.7

Original comment by aso...@gmail.com on 14 May 2010 at 6:14

• Changed title: The java classes contining non-safe URI characters in names are incorrectly encoded
• Changed state: Fixed

[GoogleCodeExporter]

http://code.google.com/p/snakeyaml/source/detail?r=90131e8e002a9f168cb8368c5885d
1938f1a1440

fixes Windows and OSX builds failed because of this patch ;)

Original comment by alexande...@gmail.com on 16 May 2010 at 8:59

[GoogleCodeExporter]

Still incomplete.
According to http://yaml.org/spec/1.1/#escaping%20in%20URI/ '[' and ']' should 
be
added to escaper.
Tests shall be added.
Exceptions must be tested (invalid escape etc)
Error messages must be tested (line number etc)
A tag with a non-ASCII character shall fail while dumping.

Original comment by aso...@gmail.com on 18 May 2010 at 12:46

• Changed state: Started

[GoogleCodeExporter]

Unfortunately it is not possible to escape characters when a Tag instance is 
created.
The reason is that it is not clear when to escape. For instance '/' may or may 
not be
escaped depending on the context.

Original comment by aso...@gmail.com on 27 May 2010 at 10:04

[GoogleCodeExporter]

I think that escaping is a better behaviour, providing another constructor that 
takes 
an URI object for precise URI specification, that way each constructor does the 
correct thing, the former creates a proper Tag no matter which String (notice 
String 
not URI) the client passes, as its signature suggests. If escaping is not an 
option 
for whatever reason then, IMHO, throwing an exception at construction time 
rather than 
in an unrelated place would make the code better and easier to debug.

Attached is the patch to avoid the escape of [].

Original comment by manuel.s...@gmail.com on 27 May 2010 at 11:25

Attachments:

• 01.patch

[GoogleCodeExporter]

The patch is taken.
I am afraid I did not quite catch your proposal. Can you may be contribute a 
patch
with the API change and the corresponding tests? The tests do not have to 
succeed, I
just wish to see the expectation.
If you do not want to change anything now may I close the issue ?

Original comment by aso...@gmail.com on 28 May 2010 at 9:36

[GoogleCodeExporter]

Never mind, both paths seems to broke some many things that indeed will create 
a 
backwards compatibility headache. I'm not sure is worth the hassle. Please, 
close the 
issue.

Just for the record attached is the patch that will use two constructors for 
Tag, one 
using an String that is escaped and other that takes a URI.

Original comment by manuel.s...@gmail.com on 28 May 2010 at 3:45

Attachments:

• 01.patch

[GoogleCodeExporter]

the last patch is taken.
I must say I do not have a clear vision on how to escape characters in a Tag. 
If no one 
objects the change it will go to release 1.7
Once we have more usecases from the community we can see how we can manage 
non-trivial 
tags.

Original comment by py4fun@gmail.com on 31 May 2010 at 9:37

• Changed state: Fixed