We have developed a hybrid app using worklight 6.1. We have set up our environment in eclipse juno.
While verifying the app using windows app cert kit, we are getting following error -
The UTF-8 file encoding test detected the following errors:
...\www\default\worklight\worklight.css is not properly UTF-8 encoded. Re-save the file as UTF-8 (including Byte Order Mark).
and many more such errors for dojo files as well.
Is there any settings, that we can do in eclipse, that will make all the files in app to use UTF-8 encoding.
I tried Window -> Preferences -> General -> Workspace : Text file encoding and set it to use "UTF-8". But this didn't helped.
Update:
It appears that for a Windows 8 store application, HTML/CSS/JS files must be encoded in UTF-8 with BOM marker, however Worklight Studio does not generate these files with the BOM marker.
To have this fixed, you'll need to create a PMR so that the development team could investigate & provide a fix.
In the meanwhile you can follow Microsoft's suggestion:
Corrective Action
Open the affected file and select Save As from the
File menu in Visual Studio. Select the drop-down control next to the
Save button and select Save with Encoding. From the Advanced save
options dialog, choose the Unicode (UTF-8 with signature) option and
click OK.
Previously:
If you have already created your Worklight project and then changed the encoding to UTF-8, this will not help this pre-existing project.
Delete the native windows8\native folder and re-build the project in Eclipse. This will then re-generate the native folder with the mentioned CSS file, in UTF-8 encoding.
I've tested this, and the file was created as mentioned, encoded in UTF-8.
Related
I know there are plenty of questions about this problem, but no one of the solved it for me! I'm using the Community Edition of IntelliJ and I tried to run JavaDoc through the IDE. Everytime and it doesn't matter fo which file, I run JavaDoc I got the following output:
javadoc: error - cannot read Input length = 1
I already figured out, that it might be an encoding problem... I'm working on a Windows 10 maschine. I already tried the following:
JavaDoc argfile encoding error
Start the terminal from IntelliJ with cmd.exe /K chcp 65001 instead of the default one cmd.exe to set the charset to UTF-8
I also set the project's default charset through the IntelliJ settings to UTF-8 (See: This Guide)
The problem seems to be the javadoc_args file respectively the path to that file... The path is C:\Users\Somebody Müller\AppData\Local\Temp\javadoc_args. Also if I view the file from IntelliJ, all ü characters are replaced by an unknown symbol.
I know that I could generate the documentation through a maven plugin, but I would prefer to do it via the IntelliJ IDE...
Could somebody identify the problem in detail and/or provide a solution or maybe parts of it?
EDIT
skomisa described the situation/behaviour in easy words:
For me the javadoc_args file does not exist! I see it is named in the Javadoc window as an argument to javadoc.exe, and if I click the link its content is shown in a pop up window within Intellij IDEA, but if I check in File Explorer there is no such file. Is this the case for you as well? I have no idea how it gets generated. Also, I created a project in a folder named Müller and the ü was rendered as � within the popup window that showed the content of javadoc_args.
UPDATE 04/12/2018
As skomisa already commented, JetBrains plans to fix this bug in a future version, likely in version 2019.1 (Build 191.2458).
UPDATE 22/02/2019
I know this question is quite old but it seems to be still relevant. I didn't check up to now if JetBrains fixed the bug but a similar one occurred for me when I try to open an JavaFX fxml externally inside of the SceneBuilder. In another post about renaming a Windows 10 user directory I found a possible workaround at least for Windows users! Just create an additional user directory without ü in the path and link to the existing one:
C:
CD\Users
MKLINK /J Müller Mueller
If you now uses the link as directory for project paths it should work fine.
I am unable to generate the Javadoc for a project in Intellij IDEA if the name of the path contains the character ü (u with umlaut). The workaround is to rename the project so that the project directory file path does not contain an umlaut.
To reproduce:
Use the project wizard to create a trivial Java Hello World project where the root directory name contains ü. I used Müller for testing purposes.
Ensure that the class for main() contains valid Javadoc documentation.
Build and run the project to verify that there are no unexpected issues.
Select Tools > Generate Javadoc, specify an empty Output Directory and click OK.
Javadoc creation fails with the error - cannot read Input length = 1 (shown below), and clicking the link to C:\Users\johndoe\AppData\Local\Temp\javadoc_args shows that the ü in the file path is (mis)represented as �, which presumably is the cause of the Javadoc error.
However, once the root directory is renamed from Müller to Muller (to remove the umlaut) the Javadoc creation works:
As a sanity check, rename the project from Muller back to Müller to reintroduce the error:
Notes:
As noted in the comments, the javadoc_args file does not exist, and I see no way to prevent its use during the Javadoc creation process.
Having the project name as Müller is not an issue; it's having ü within the project's file path that causes the problem.
Environment: Windows 10 + Intellij IDEA 2018 3.1 EAP (Ultimate Edition) + Open JDK 10.
I raised a bug report with JetBrains for this: https://youtrack.jetbrains.com/issue/IDEA-202849
Update 11/25/18
There is a workaround for this issue without needing to rename the project's path:
Run Generate Javadoc and let it fail.
Click the link to the file .../javadoc_args shown in the Javadoc window.
Copy and paste the content of the file javadoc_args into a text editor.
Correct any characters that are misrepresented (e.g. change M�ller to Müller).
Save the file using UTF-8 encoding, and the same absolute filename.
Open a Command Prompt window.
Copy the entire javadoc.exe command from the Javadoc window in Intellij IDEA and paste it to the Command Prompt window.
Submit the line that was pasted. It will now work because the project's path is correctly specified in the file javadoc_args.
Today (21-aug-2021) I tried to generate a javadoc but it failed. The error message was:
javadoc: error - cannot read Input length = 1
In my case it referred to the length of the path to the file, which is shown below.
D:\Tecnologia(ytrabajo)ysistemas26sep2020\misiontic2022\U El Bosque\UEB académico\Ciclo 2\Programación Básica\NetBProjects\R5DTO_DAOMVC_GUI
So I shortened the path to the following:
D:\Tecnologia(ytrabajo)ysistemas26sep2020\misiontic2022\NBProjects(m)\R5DTO_DAOMVC_GUI
As one can see, this route is shorter than the first so NetBeans could access it and generate the javadoc.
Note: It is not possible that NetBeans could not read the location because of the following characters: é and á in the words académico and Básica that I used in the first file location. Because, in that location, I tried to generate a JavaDoc in another project located there and NetBeans generated the Doc. So the error is more about the length of the path and the names of the files in the project.
I am having trouble viewing pdf file (.pdf) in IntelliJ IDEA (ULTIMATE 2019.3) from a markdown file (.md) having ![alt text] clause in it, even after PDFViewer (26th Feb 2013) plugin installed. png is working in there.
viewing pdf by selecting it from Finder on macOS Mojave is always fine but fine from IDEA only if the plugin is disabled.
It seems that the plugin takes extension of '.png' as a default, as viewing png in IDEA is always fine regardless of having '.png' as an extension in the md ![alt text] clause.
any help would be appreciated. Art
If you want to open .pdf files from the external application and not by IDE, check that you have *.pdf extension pattern added for Settings (Preferences on macOS) | Editor | File Types -> Files Opened In Associated Applications:
I have created a small application that selects the files and renames spaces into underscores and few other symbols. It works fine when I tried with the files on my desktop but it fails to execute when i try with files on my remote server. The problem is it doesn't show any signs of error. In my application, once the files are renamed, I will get a notification on my app stating the number of files renamed. It does show that the file is renamed but I couldn't find the renamed files. Any suggestion as to why it happens or any fixes for this please.
I have created the application and exported as a Mac Executable Application.
Solved: NSFileManager recognises file paths in different formats so we need to change according to the default path format with which Mac recognises and update files. I changed accordingly and it works. Thanks for you help.
I'm trying to create a Worklight project in Worklight Studio 6.1 from a template. It's a straight forward process as described here: http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/index.jsp?topic=%2Fcom.ibm.worklight.dev.doc%2Fstudio_ext_assets%2Fc_wl_project_templates.html
However I'm getting "invalid byte 2 of 2-byte UTF-8 sequence" exceptions on some of the settings.xml files inside the android environment's native resources when trying to compile newly created project.
The files are in utf-8 inside the template and I have utf-8 set up for my workspace file encoding ( Preferences->General->Workspace ).
But after extracting stuff from the template ( which is really a zip bundle ) looks like it changes encoding somehow.
Problem goes away when you try to re-save .xml file (for example - open it, add a char somewhere, delete it and save). But this is not an option since we are going to deliver the template to a customer and this will affect the 'user experience'.
Also, the same exact template works fine on linux platform. I saw this issue on windows.
Has anybody experienced this before and could share any info on how to fix it?
Thank you.
Make sure that under Preferences->General->Workspace in Eclipse, the default text file encoding is set to UTF-8 and not US-ASCII (usually by default it is set to ASCII). This should take care of the encoding problems.
I am uploading my first Opera Extension. It is very simple. It is a toolbar button that launches a popup window. It works perfectly fine in Opera developer mode. Opera is not letting me upload it successfully. It keeps saying the persona.ini file is missing. Meanwhile I downloaded quite a few extensions already live in the Opera Extensions Directory to see their persona.ini files and none of them even have a persona.ini file. I can only find one example of a persona.ini file online and it must not be correct because it doesn't allow the upload either.
Has anyone experienced this? Why is this happening?
You're probably uploading the extension in .zip format, which is not supported — only .crx and .nex are supported. .zip is only used for Opera themes (hence the reference to persona.ini).
So, to fix this, you can do the following: when in developer mode, use the "Pack extension" button to pack and sign your extension. Then try uploading it again — everything should work fine.
I successfully uploaded zip package in Opera store.
I faced with same issue ("persona.ini is missed") when tried to upload zip package with root folder - I mean zip content: "Sources/content (like manifest.json).
Chrome store accepted this package but for Opera you could try to create zip package with all content without parent folder (Sources folder in my case).
Opera doesn't support till now the .zip file you need to upload either .nex or .crx file.
To create a .nex file..
In your opera URL,just type opera://extensions
Click on Pack Extensions.
Browse to the root directory of your extension and click on okay.
The file will also create an .pem file along with .nex file. Keep your pem file safe and with you for uploading/upgrading your extension.