tracker issue : CF-4118565

select a category, or use search below
(searches all categories and all time range)
Title:

CLI does not seem to support UTF-8-encoded code properly

| View in Tracker

Status/Resolution/Reason: To Fix//

Reporter/Name(from Bugbase): Adam Cameron / Adam Cameron (Adam Cameron)

Created: 02/17/2016

Components: CLI

Versions: 2016

Failure Type:

Found In Build/Fixed In Build: CF2016_Final /

Priority/Frequency: Normal / Few users will encounter

Locale/System: English / Platforms All

Vote Count: 2

Problem Description:
See http://blog.adamcameron.me/2016/02/coldfusion-2016-trying-to-write-about.html

Basically the CLi does not seem to handle UTF-8 encoded files properly

Steps to Reproduce:
CLI.writeln("kuputuhi tauira ki p??hua nako");

Actual Result:
kuputuhi tauira ki p???hua nako

Expected Result:
kuputuhi tauira ki p??hua nako

Any Workarounds:
Nope

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	4118565

Reason:	BugVerified

External Customer Info:
External Company:  
External Customer Name: Adam Cameron
External Customer Email:  
External Test Config: My Hardware and Environment details:

Attachments:

Comments:

I tried it on Japanese Windows on which the default code page is 932. Below is the code and it is saved as UTF8 with BOM. <cfset cli.writeln("??????aaaa????")=""> The output is; ??????aaaa???? So, it handles properly Japanese characters on Japanese Windows. It seems to me that CFCLI cannot handle the characters not included in the default code page of the OS. Furthermore, chcp 65001 corrupts Japanese characters. The output is "‚¶‚á‚Ï‚Éx81;[‚¸x81;`‡Šaaaa????". IMHO, CFCLI converts the output to the default codepage of the OS. It would explain the behavior on Japanese Windows. So the desired behavior is to detect the actual code page of cmd and convert the output to it.
Comment by External U.
4747 | February 17, 2016 08:21:56 PM GMT
Oops, the code is <cfset cli.writeln("??????aaaa????")>
Comment by External U.
4748 | February 17, 2016 08:47:32 PM GMT