With NetBeans 15 I can write characters like 'à' and 'è' in the editor but if I try to print them in the console they are not displayed and this also happens if I enter the ASCII code of the characters. If I compile and run the program manually everything is fine.
Resolved:
the problem rises on one of the changes implemented in Java 18 that is JEP 400: UTF-8 by Default. In it is stated: "Standardize on UTF-8 throughout the standard Java APIs, except for console I/O".
I have resolved adding (only for JDK 18)
if(!"UTF-8".equals(System.out.charset().displayName())){ System.setOut(new PrintStream( new FileOutputStream(FileDescriptor.out), true, StandardCharsets.UTF_8)); }
Related
I have a problem with encoding characters when I'm trying to run test. I'm using Symfony 4 framework with package symfony/phpunit-bridge.
I'm running test by command like below:
php bin/phpunit tests/WhovianTest.php
The results looks like below:
As we can see there is a problem with encoding in test's results. I'm using windows 10 operating system and PHPStorm IDE.
How could I solve this problem?
I would be grateful for help.
A standard Windows 10 shell has some issues with the ANSI control characters that are used to display colors (they are quite recognisable with the ?[31; characters being displayed). There are some packages to add them, or you can just turn them off.
The phpunit docs suggest:
On Windows, use ANSICON or ConEmu
Alternatively, you can set colors="false" in the opening tag of your phpunit.xml, or as a command line parameter: --colors=never (try auto as well).
I am writing an Eclipse Plugin. All my source files are encoded as UTF8 (Alt+Enter shows "Text file encoding: UTF8").
When I run my plugin using "right click -> Run as eclipse application" everything works fine.
However, when I install my plugin using an update site in another (but identical, i.e., copied) Eclipse application, German Umlauts (Ä Ö Ü...) get messed up in all SWT-controls, but not in String constants.
Example:
public class MyWizard extends Wizard{
public NewEntityWizard() {
super();
setWindowTitle("This will NOT work: Ä");
}
public void foo() {
String contents = "This WILL work: Ä";
ByteArrayInputStream stream = new ByteArrayInputStream(contents.getBytes());
// write stream to file test.txt
}
The window title will show up as: "This will NOT work: ä"
When opening the file test.txt in Eclipse, with UTF8 encoding, it will contain the correct test: "This WILL work: Ä"
Both will work when run by using Run as, i.e., when not installing the plugin.
How do I resolve this?
I figure, the compiled plugin / bin files might (correctly) be encoded in UTF8, but read in a different encoding by the second Eclipse installation. If so: How do I tell the JVM / Eclipse to read the Plugin's bin files in UTF8?
Any help is appreciated.
Solved the problem myself. The issue was a Bug in Eclipse (I am running Oxygen, not sure if the problem exists in other versions).
The bug was, that the PDE Builder, which builds the product, does not respect the encoding settings configured in Eclipse. It uses the default encoding of the plattform, which is not UTF8. This seems to be a Windows only problem. The java builder does not suffer from this bug, that's why the problem did not occur during testing.
Bug Description:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=516656
Solution:
As workaround I added the following line to the eclipse.ini of the building Eclipse installation, build the product again and installed it again. The setting makes UTF-8 the default encoding for the whole VM.:
-Dfile.encoding=UTF-8
This solved the issue.
platform：opensuse leap 42.2 KDE
Eclipse：Version: Oxygen Release (4.7.0) UTF-8
xxx#linux-bq5s:~> java -showversion
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
I use Java write a simple code, the code is fine since I can run it in a special way (shows in the image), so don't focus too much on the code.
I put in the word "高数" ，but as you can see, it returned something else, but it's not done yet, look at the second picture.
I copied the word "高数" in input filed at somewhere else that I typed in, and I paste in the Eclipse input filed and enter, it returned correct.
I have changed another Input Method, but nothing changed.
I run the code in terminal, and input normally, and it seems alright, so I think the problem is in the Eclipse
xzyx#linux-bq5s:~/桌面> java User
请输入指令：1-按书名选择；2-按序号选择
1
请输入书名
高数
您已选择：高数
xzyx#linux-bq5s:~/桌面> java User
请输入指令：1-按书名选择；2-按序号选择
1
请输入书名
电子
您已选择：电子
In Eclipse, when I add a table before input the charater "高数", the code could work correct, I think there is something wrong with Eclipse's input field.
I am trying to get a colored output in my Netbeans output window.
Ansi-Output in Linux and Windows console works perfectly fine. However not in the IDE.
Is there a way to make this work in Netbeans' output window?
According to this
https://netbeans.org/bugzilla/show_bug.cgi?id=214546
it should work, but it doesn't in my current Netbeans 8.0.1 installation (neither Linux nor Windows).
Any hints on how to do that?
I am using Netbeans 8.0.1 myself, on Windows 7. I just tried ANSI escape code, and it works. Example:
String greenBold = "\033[32;1m";
String reset = "\033[0m";
System.out.println("before" + greenBold + " green " + reset + "after");
There seems to be a problem when using Maven 3.5.x.
See:
https://netbeans.org/bugzilla/show_bug.cgi?id=270593
https://github.com/fusesource/jansi/issues/87
I tried NB 8.2 with the old Maven 3.3.9 first and it worked fine out of the box. The whole output remained as it had been but my application's own logs were colored as expected.
With Maven 3.5.2 and 3.5.4 the colors didn't work at all. So I had to set MAVEN_OPTS environment variable to "-Djansi.passthrough=true" (as suggested in the first link) and restart NetBeans. The problem is that now the whole output is colored differently and error stack traces don't contain links to code any more. So I'm switching back.
BTW. When using log4j2's %highlight{}, I also had to set disableAnsi="false" to get the desired effect:
<Console name="Console" target="SYSTEM_OUT">
<PatternLayout pattern="%d{HH:mm:ss.SSS} %highlight{%-5level} [%t] %location --- %msg%n%throwable" disableAnsi="false" />
</Console>
I'm using NetBeans 12.3 and I had same problem. Problem is with bundled Maven (version 3.6.3).
When I changed to Maven which I installed on my system it works. Note that version of Maven installed on my system is the same as the bundled one - 3.6.3.
I have changed location of Maven in settings:
#YoungFrog solution was the best for me.
I spent all day to get NetBeans 14 working with hyperlinks and ANSI colors simultaneosly.
chmod -r /path/to/netbeans-14/netbeans/java/maven/lib/jansi*
did the job.
Actually, for me it was bad to change the default maven installation folder. In order to have all the output correctly working (hyperlinks in stack trace, ANSI colors in output, no NETBEANS-EXEC lines) I suggest you to use the one bundled with the specific NetBeans version you have installed.
I am writing some node command line utilities. They all start with the line:
#!/usr/bin/env node
With Eclipse Juno and the Nodeclipse Node.js plugin, this line of code produces an error as shown:
OK, so # is not a valid comment character in javascript, but it is a valid character in Linux/UNIX as the shebang of the first line in a file. But how can I set up Eclipse to ignore this error? This is a problem for me because code formatting does not work if you have errors. I have to delete the line. Hit CTRL-SHIFT-F and add the line back.
I have tried a lot of things and researched, but I can't find an answer.
There is a duplicate question out there, eclipse javascript syntax error on hashbang line, but my question has more info.
EDIT:
Looks like there was something added to jshint to allow shebangs in the first line. Maybe I need to update my node-eclipse, or maybe the node-eclipse project needs to update jshint?
My jshint eclipse integration is version 0.9.6.
My nodeclipse is 0.4.0.20130519...
I upgraded to
jshint eclipse integration 0.9.9.20131029
nodeclipse 0.7.0.20131101
That did not help.
Here is my JSHint version in eclipse:
EDIT 2:
Thanks for the answer VonC. But I think this shows that I do not have a BOM in the file. Any other ideas?
$ od -N 20 -t x1 hello.js
0000000 23 21 2f 75 73 72 2f 62 69 6e 2f 65 6e 76 20 6e
0000020 6f 64 65 0a
0000024
EDIT 3:
With regard to Paul Verest's answer below, I tried to turn off JSDT validation, but I can't seem to do it. I unchecked "Enable JavaScript semantic validation" (In Eclipse, see Window > Preferences > JavaScript > Validator > Errors/Warnings), but the issue remains.
I am now uninstalling Eclipse Web Developer Tools 3.4.2. That did not seem to help and now my CSS and HTML editors are gone. Now I have tried to disable JSDT validation by following some of the ideas in this SO question, How do I remove javascript validation from my eclipse project?.
So I went into my project properties and went to JavaScript > Validation. I have set everything to "Enabled project specific settings" and unchecked "Errors/Warnings", "JSDOC", etc. Even so, I think validation is still running since the problem persists! My "Builders" Properties only lists the "JSHint Problem Checker" which is enabled. (I am doing all this on a new test project with a hello.js).
EDIT 4, THE ANSWER
It was not easy, but I ended up hacking the .project file in Eclipse. I had this:
<natures>
<nature>org.nodeclipse.ui.NodeNature</nature>
<nature>org.eclipse.wst.jsdt.core.jsNature</nature>
</natures>
I removed the jsdt nature and now the error on the shebang line is GONE! I did this in my test project and my real project. It worked! This is actually pretty helpful since I can format the file and I'm actually running jshint now.
There are 2 option for JavaScript validation in Eclipse:
JSDT
JSHint (default since Nodeclipse 0.7)
As configration is stored per project, copy .* settings files from project created with 0.7 or re-configure it manually (just compare .* files with newly created project).
Then put .jshintrc file like
https://github.com/Nodeclipse/nodeclipse-1/blob/master/org.nodeclipse.ui/templates/.jshintrc
Try to check JSHint options, if it is possible.
Note that with JSHint usage, ~~this question becomes general JSHint question (not Eclipse or Nodeclipse related).~~
UPDATE:
.project content since 0.7 :
<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
<name>ProjectName</name>
<comment></comment>
<projects>
</projects>
<buildSpec>
<buildCommand>
<name>com.eclipsesource.jshint.ui.builder</name>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>org.nodeclipse.ui.NodeNature</nature>
<nature>org.eclipse.wst.jsdt.core.jsNature</nature>
</natures>
</projectDescription>
As #Jess discovered this was error shown by JSDT, not JSHInt,
so removing <nature>org.eclipse.wst.jsdt.core.jsNature</nature> will stop JSDT from displaying it (even with JavaScript semantic validation already turned off since 0.7)
UPDATE 3:
Drawback of <nature>org.eclipse.wst.jsdt.core.jsNature</nature> removed will be that code assist and click-though to definition will not work (It actually works in rare cases when JSDocs are defined e.g. http://www.nodeclipse.org/nodejs/javascript/sources/books/2013/10/22/JSDT-require-JSDoc.html or within 1 .js file)
Even click-through to definition
Update:
The issue entered in nodeclipse points out to JSHint issue 66.
As Paul Verest remarks in his answer (upvoted), this could be as simple as making sure JSHint check the code.
Since commit 63da9, JSHint knows how to ignore that shebang directive.
// If the first line is a shebang (#!), remove it and move on.
// Shebangs are used by Node scripts.
if (lines[0] && lines[0].substr(0, 2) == '#!')
lines.shift();
Original answer
Are you sure '#' is not a valid character (yet used in this question)?
Double-check the encoding of your node.js file, because if it is UTF-8 with BOM, then the javascript couldn't be launched properly.
See "What's different between utf-8 and utf-8 without BOM?", and the wikipedia article on shebang (section "Magic number")
The shebang characters are represented by the same two bytes in extended ASCII encodings, including UTF-8, which is commonly used for scripts and other text files on current Unix-like systems.
However, UTF-8 files may begin with the optional byte order mark (BOM); if the "exec" function specifically detects the bytes 0x23 0x21, then the presence of the BOM (0xEF 0xBB 0xBF) before the shebang will prevent the script interpreter from being executed.
Some authorities recommend against using the byte order mark in POSIX (Unix-like) scripts, for this reason and for wider interoperability and philosophical concerns.