I am using BitBucket Piplelines to run .NET SonarScaner. Data is sent to SonarCloud. The problem is that I get an error if the file name of the Git diff has Japanese characters in it. I have tried adjusting the locale, but it doesn’t help. Is there any way to fix this?
Hi @uda ,
Are you still experiencing this issue? I was wondering if you could give me some additional information. You have mentioned that the issue is being caused by the gitdiff containing japanese characters. Is this because the files have had Japanese characters added to the content and therefore this is being recorded in the diff? Or is it something to do with localization settings which are being used which is causing information to be added to the diff?
Would you be able to share some content from this file? You can also send me this privately if you prefer.
Thanks for the reply. This issue is ongoing.
We are unable to resolve this issue, so we are removing Japanese file names from the repository to address the issue. We are unable to respond.
SonarCloud is not available for the project.
The commit retrieved from BitBucket is as follows. It seems to be an error if the file name of the difference contains Japanese.
Omitted
diff --git “a/*/\342\227\207\345\231\250\345\205\267\351\253\230\343\201\225.txt" "b//\342\227\207\345\ 231\250\345\205\267\351\253\230\343\201\225.txt”.
index 6c6b4313f…2ef385f9a 100644
— “a/src/building/TestLibComputation/Data/Lighting/CompareExcel/\342\227\207\345\231\250\345\205\267\351\253\230\343\201\225.txt”
+++ “b/src/building/TestLibComputation/Data/Lighting/CompareExcel/342\227\207\345\231\250\345\231\345\205\267\351\253\230\343\201\225.txt”
@@ -1,5 +1,5 @@
v Omit (but unlike the file name, the contents are in English) **
\No newline at end of file Omitted
** No newline at end of file omitted**
2.41.0
I can send you the file unabbreviated.
I would appreciate it if you would allow me to send it to you personally.
I have been trying to recreate the failure you are describing locally and within bitbucket however, I haven’t experienced the issue you are seeing. I have tried creating files with Japanese filenames and Japanese content however all seem to be passing analysis on our side. I can see from the analysis that you sent me that there are both Japanese filenames and Japanese string content so I have tried a combination of both however it has currently not been failing.
I have sent you a message to discuss further investigation.
We have prepared a repository to reproduce this issue, and we hope you will check it.
You can see the error on the pipeline screen after adding a file with a Japanese name.
This is great, I will take a look in our logs today and see if we can do something about this for you. Either way i’ll come back and let you know my findings.
An update for you, I was able to recreate the issue you are experiencing, I am currently investigating to see what is possible here. I’ll try and update again for you soon.
I have been taking a further look into this issue with a colleague, we have tried many combinations using different character sets to try and find a working setup for you. We should be able to specify the working characterset for the sonarcloud analysis by setting /d:sonar.sourceEncoding=UTF-8 in the parameters and also potentially by setting the java params - export JAVA_TOOL_OPTIONS="-Dfile.encoding=UTF8 -Dsun.jnu.encoding=UTF8" . I do now see the file now being processed, however as you can see this is still throwing an error in the process
Unfortunately, as these failures are still occurring you will need to continue to change the files for now. I believe that there is some issue lower down in the code that is potentially not not handling these other character sets, this will however require some deeper investigation.
Please allow me to share the results of our additional internal investigation.
.NET 6.0 container image does not include Japanese language. We also found that the method of specifying the source code encoding to SonarScanner for .NET was incorrect. After correcting these issues, the error has been resolved. Specifically, we made the following changes
I am very glad to hear that you managed to find the source of the issue and thank you very much for sharing your findings with us. I will arrange for this information to be added to our troubleshooting documentation as I can imagine that other users could easily experience a similar situation.