invalid byte 2 of 2-byte UTF-8 sequence in resource files after importing the worklight template - ibm-mobilefirst

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.

Related

javadoc: error cannot read Input length = 1 (IntelliJ - no maven) [duplicate]

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.

React-Native: How to open locally bundled binary file

I'm writing a react-native app, and I want it to deploy with a zip file that contains a device firmware update.
Before letting the user send the update, I need my code to open the zip and do some validation of its contents.
I've found lots of zip-handling NPM packages, so all I need to do is load the file contents so I can feed it to one of these.
require('./firmware/fw.zip'); <-- packager doesn't include .zip by default
require('./firmware/fw.pdf'); <-- [gross hack] packager includes pdfs, but the actual result of the require() call is a number: 5. I don't know what I can do with this number to get file contents, but I'm pretty sure this require() system is designed for loading images, not binary data.
ReactNativeFs.openFile('./firmware/fw.zip'); <-- fails with ENOENT
ReactNativeFs.openFile(${ReactNativeFs.MainBundlePath}/firmware/fw.zip); <-- MainBundlePath is undefined on android.
This seems like a really basic question, so I'm sure I've missed a piece of documentation somewhere, but I'm heading into my third hour trying to load the contents of this file with no luck.
I'm pretty sure I could manually put the zip file into the appropriate android and ios resource directories, but that seems like a step down a hard-to-maintain road.
I encountered this problem again a couple months later (I'm apparently the only guy that needs to package .zips in react-native), and the above answer didn't work out for iOS. So I encoded the .zips as base64, put them in .js files, then used import to get the data from those .js files. This actually seems like a somewhat hacky but also flexible long-term solution, without having to mess around with platform-dependent file locations.
See whole answer at my new question: React-native packager configuration - How to include .zip file in bundle?
Partial solution:
Modify android/app/build.gradle, and add
task copyData(type: Copy) {
from '../../firmware/fw.zip'
into 'src/main/assets/raw/firmware'
}
preBuild.dependsOn copyData
This will at least ensure that the file gets copied each time you build, and is then available with ReactNativeFs.readFileAssets('raw/firmware/fw.zip', 'base64'). I'm not entirely thrilled because I still have to have iOS/android dependent code when loading the file, but at least it's loading now.
Tip: watch out for your syntax in gradle. into src/main/assets/myFirmware.zip will create a DIRECTORY called myFirmware.zip, and put your zip file underneath it. Then readFileAssets will still fail because it's finding a directory at your path, not a file.

Cocoa Application on remote files?

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.

Worklight: Windows 8 store certification issues for UTF-8 file encoding

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.

Build and Debug application outside the default package

If I try to build an application with the application class outside the default package, so the application file path is /app/AppClass.mxml instead of /AppClass.mxml (as would normally be the case), Flash builder cannot launch the application for debugging because it is looking for the SWF in debug/app/AppClass.swf and the SWF is being output to debug/AppClass.swf instead. Changing the output folder to debug/app makes it put the swf in debug/app, but then it puts the application configuration file "AppClass-app.xml" in /debug/app/app and then that can't be found.
Is there a way to change only the SWF output folder, or the location of the xml configuration file in the run-configuration?
You may use symbolic link to created swf file - http://en.wikipedia.org/wiki/Symbolic_link
for example for Windows :
cd project/path/bin-debug/package/path/
MKLINK ClassName.swf project/path/bin-debug/ClassName.swf
and it's work
or you can use symbolic link for folder:
cd project/path/bin-debug/package/
MKLINK path project/path/bin-debug/ /D
I think I remember this worked for me. But it was long time ago. And, yes, it is a known problem, I also recall Adobe people mentioning it as a limitation of FB.
In my Ant script, you'll need to do the adjustments to reflect your actual file names and directory structure. Also note that it will make it more cumbersome to debug it from FB. You'll need to use the debugging target in Ant, and then connect the debugger to the running application (so that some info, especially on the startup) will be lost. The only way you would be able to debug it, though I've never tried it, is with the commandline tools (I'm not sure of adl syntax for breakpoints / printing / stack frames, so idk how to do it.
Also, for the released application you will probably want to change the signing mechanism.