Introduction
The JS7 Controller, Agents and JOC Cockpit make use of Unicode. When files are created or used then UTF-8 encoding applies.
- Unicode support works across any supported JS7 - Platforms.
- Limitations have to be considered in mixed environments that include the Windows OS without Unicode support.
JOC Cockpit
When designing workflows with the Configuration -> Inventory view users can make use of any Unicode characters within the scope of JS7 - Object Naming Rules.
- Download (upload .json) workflow for Unix:
- Download (upload .json) workflow for Windows:
Configuration View
The Configuration -> Inventory view allows to specify object names and job scripts using Unicode characters:
- JOC Cockpit requires the JS7 - Database to support UTF-8 encoding in order to store objects that hold such characters.
- The same applies to the JDBC Driver in use. All vendors of supported DBMS offer Unicode support.
Workflows View
The Workflows view displays workflows using Unicode characters accordingly:
- The below example makes use of Japanese object names.
- In addition the JOC Cockpit interface language is switched to Japanese by use of JS7 - Profiles - Preferences.
Log View
The Log view window displays output of jobs and instructions.
- Partly output is created from JOC Cockpit and is qualified with markers such as [MAIN], [SUCCESS], [DETAIL].
- Partly output is created from job scripts executed with an OS shell. Such output is marked as [STDOUT] and [STDERR].
Explanation:
- Output from Unix Operating Systems
- Unix Operating Systems ship with built-in support for Unicode and UTF-8 encoding.
- Output from Windows Operating Systems
- Windows does not offer Unicode. Instead the OS ships with different codepages preinstalled depending on the location in which the OS is used.
- Some experimental support is available starting from Windows 10, however, as most Windows programs are not aware of Unicode there can be side-effects.
- Therefore the encoding of output created by jobs depends on the codepage in use for the respective Windows OS for which an Agent is operated.
Controller
The Controller does not read or files related to workflow execution. The Controller reads configuration files and writes log files only.
- Configuration files use UTF-8 encoding.
- Log files are created with UTF-8 encoding.
Agent
Agents use an OS shell to execute jobs scripts. Agents collect output of jobs that is available from the stdout and stderr channels.
- For Unix environments the OS creates output in UTF-8 encoding.
- For Windows environments the OS does not support Unicode but makes use of codepages.
Use with Windows Codepages
The Agent makes use of the codepage that is active for the computer the Agent is operated for.
- In Asia frequently code page 65001 is or specific codepages such as 932 for Japan are used.
- In Western Europe frequently codepage 850 is used.
FEATURE AVAILABILITY STARTING FROM RELEASE 2.3.0
Supported Codepages
Agents support use of the following code pages:
Specifying the Codepage
The Agent applies the codepage used by the Windows OS if available from the above list of codepages.
Users can force use of a supported codepage by adding a setting to the Agent's JS7_AGENT_CONFIG_DIR/agent.conf
configuration file such as:
js7.job.execution.encoding = "UTF-8"
Explanation:
- Users should be aware that modifying the Agent's codepage will not modify the codepage of the underlying OS shell.
- OS commands will continue to encode output with the OS codepage.
Limits of Windows Codepages
The following examples explain a few limits of codepages.
Download (upload .json): pdLanguageSupportSwitchCodePage.workflow.json
Workflow Jobs: ハローワールドジョブ
@echo off echo running job: %JOB_NAME% echo 日本語 echo var1=日本語 >> %JS7_RETURN_VALUES% echo last_job_name=%JOB_NAME% >> %JS7_RETURN_VALUES% chcp
Explanation:
- The first job is assigned an environment variable
JOB_NAME
from a built-in global variable like this: - Line 3: The output of the
JOB_NAME
environment variable can be scrambled if the server does not use a compatible codepage, see chapter Log View. - Line 4: The job displays Unicode characters that have been directly added to the job script.
- Line 6, 7: The job creates two variables for use with later jobs:
var1
: the variable directly holds Unicode characters.last_job_name
: the variable holds the name of the current job.
- Line 9: The job displays the current codepage.
@cmd.exe /K chcp 65001 <nul set /p "echo=running job %JOB_NAME%" <nul set /p "echo=last job name: %LAST_JOB_NAME%" <nul set /p "echo=value of variable var1: %VAR1%" <nul set /p "echo=日本語" chcp
Explanation:
- Line 1: The job script creates a new shell and switches to a Unicode codepage.
- Line 3: The output created for the current job name is readable from the log view as the codepage now includes Unicode support.
- Line 4: The output of the
last_job_name
variable will be scrambled if the predecessor job created this variable from a non-matching codepage. - Line 5, 6:: The output is readable in the log.