[
https://issues.apache.org/jira/browse/NIFI-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16161903#comment-16161903
]
ASF GitHub Bot commented on NIFI-4242:
--------------------------------------
Github user markap14 commented on a diff in the pull request:
https://github.com/apache/nifi/pull/2088#discussion_r138178130
--- Diff:
nifi-nar-bundles/nifi-standard-services/nifi-record-serialization-services-bundle/nifi-record-serialization-services/src/main/java/org/apache/nifi/csv/SingleCharacterValidator.java
---
@@ -31,10 +31,23 @@
illegalChars.add("\n");
}
+ boolean allowEmpty = false;
+
+ public SingleCharacterValidator(boolean allowEmpty) {
+ this.allowEmpty = allowEmpty;
+ }
+
@Override
public ValidationResult validate(final String subject, final String
input, final ValidationContext context) {
final String unescaped = CSVUtils.unescape(input);
- if (unescaped.length() != 1) {
+ if (allowEmpty && unescaped.length() > 1) {
--- End diff --
This logic doesn't seem to be exactly right. If allowEmpty == true and
unescaped.length() is 0, then this 'if clause' evaluates to false. So we will
go to the next line, and unescaped.length() == 0 so it's invalid. As a result,
when I tried to set Quote Character to empty string, the processor is invalid.
> CSVReader shouldn't require that an escape character be defined
> ---------------------------------------------------------------
>
> Key: NIFI-4242
> URL: https://issues.apache.org/jira/browse/NIFI-4242
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 1.3.0
> Reporter: Wesley L Lawrence
> Priority: Minor
> Attachments: NIFI-4242.patch, NIFI-4242.patch
>
>
> There are situations where, when parsing a CSV file, one doesn't want to
> define an escape character. For example, when using quote character ", the
> following is valid CSV;
> {code}
> a,"""b",c
> {code}
> The second column should be interpreted as "b. But when Apache Commons CSV is
> told that there's an escape character, the above row is invalid
> (interestingly, if it was """b""", it would be valid as "b").
> There are known formats that Apache Commons CSV provides, that doesn't define
> escape characters either.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
