[Mono-bugs] [Bug 75252][Nor] Changed - ASP.NET failing to compile code with identifiers containing non-English characters in UTF-8

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by gonzalo at ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=75252

--- shadow/75252	2005-06-13 15:00:51.000000000 -0400
+++ shadow/75252.tmp.27670	2005-06-13 21:25:02.000000000 -0400
@@ -1,13 +1,13 @@
 Bug#: 75252
 Product: Mono: Compilers
 Version: 1.1
 OS: unknown
 OS Details: 
-Status: REOPENED   
-Resolution: 
+Status: RESOLVED   
+Resolution: FIXED
 Severity: Unknown
 Priority: Normal
 Component: C#
 AssignedTo: mono-bugs at ximian.com                            
 ReportedBy: informatique.internet at fiducial.fr               
 QAContact: mono-bugs at ximian.com
@@ -216,6 +216,27 @@
 fileEncoding is specified it should provide consistent behavour 
 regardless of requestEncoding and responseEncoding.
 
 
 ------- Additional Comments From kornelpal at hotmail.com  2005-06-13 15:00 -------
 *** Bug 75253 has been marked as a duplicate of this bug. ***
+
+------- Additional Comments From gonzalo at ximian.com  2005-06-13 21:25 -------
+1. My system has a Encoding.Default set to UTF-8
+
+2. This does not fail for me with the configuration provided. But the
+identifiers created for that control are missing the é (Dbut instead
+of Début), which is what you get with MS if you explicitly set the
+fileEncoding to utf-8.
+
+3. If I set the encoding to latin1 under MS, they just ignore that
+control (they don't even create a protected variable for it). I'd
+rather throw an exception.
+
+4. Removing "<globalization 
+requestEncoding="utf-8" responseEncoding="utf-8" />" should have no
+effect on the outcome, but as you experienced, it did. What happened
+in this case is that it used the defaults in machine.config, that set
+request/response/file encodings to utf-8. I just fixed this problem in
+ svn head r45928. I think this will fix the original problem in the
+reporter's configuration, as the default fileEncoding="utf-8" wasn't
+being honored, but replaced with Encoding.Default.