What steps will reproduce the problem?
1. Adding specialchars (á,é,í,ñ,etc) to the README.md
2. Adding a simple string like original_config.php to the README
3. Showing the README on Gitblit
What is the expected output? What do you see instead?
The latin or special chars readable and the string "original_config.php" not formated.
Instead a utf8 error code like a�o is showed on the specialchars and in the case of
the original_config.php It's formated in someting like original<em>config<em>.php
What version of the product are you using? On what operating system?
v.0.8.2 on CentOS
Reported by doropeza on 2012-03-16 15:58:20
The text was updated successfully, but these errors were encountered:
I will look into the encoding issue.
The underscore problem needs to be reported upstream @ MarkdownPapers. I'll write
a unit test for that and submit it - not sure if it will be fixed in time for the next
Hmmmm. I've copied, pasted, and committed your 3 steps into a readme file.
When I test this on Debian both v0.8.2 and v0.9.0-SNAPSHOT properly interpret the accented
characters as UTF-8 and properly interpret the single underscore. I expected this
to work because I knew the file was UTF-8 encoded and Gitblit expects all repository
content to also be UTF-8 encoded.
When I do this on Windows both v0.8.2 and v0.9.0-SNAPSHOT will fail if the file is
not UTF-8 encoded. On my Windows box the files are CP1252-encoded unless I manually
override that. If I leave them as CP1252 then Gitblit displays garbage characters.
If the file is UTF-8 encoded Gitblit behaves properly.
I hate to say Works For Me so can you create and attach a small test repository that
behaves improperly on your CentOS box?
Hi, Well in fact the development is made on windows workstations, the gitblit and repository
server are on a CentOS box. You probably found the problem with that test and obviously
almost every developer team is careless about how is encoded the markdown file :S