Try adding a logAttribute processor after your encoding test to see what
values are actually getting assigned to the encoding attribute. Attribute
are always stores as strings, so I don't think you need to use the literal
function. I would suggest trying ${encoding: matches
('utf-8|utf-16|utf-16be|utf-16le|us-ascii|iso-8859-1')}Matches is an exact match and values are case sensitive. If you set the bulletin level on the logAttribute processor to 'info', all the attribute key/value pairs will be displayed on the processor by hovering over the bulletin (yellow post-it). They will also e dumped to the app log. On Nov 12, 2015 6:40 PM, "Charlie Frasure" <[email protected]> wrote: > I am attempting to convert many files with various encoding to a common > character set. I have an attribute called 'encoding' that stores the > result of an encoding test. When passing that value as the source to the > ConvertCharacterSet processor, it didn't match the processor's expected > values. I added an UpdateAttribute processor that is attempting to compare > 'encoding' to known valid Java character sets. That comparison is where I > am having trouble. In SQL it would be "where encoding in ('utf-8', 'utf-16', > 'utf-16be', 'utf-16le', 'us-ascii', 'iso-8859-1')." > > Based on this document, I thought that 'literal' would be a good function > combined with 'contains'. > https://nifi.apache.org/docs/nifi > -docs/html/expression-language-guide.html#literal > > Once the comparison is working, I will send the matching files to the > ConvertCharacterSet processor. > > On Thu, Nov 12, 2015 at 6:24 PM, Matthew Clarke <[email protected] > > wrote: > >> Charlie, >> I am not sure what your use case is here. 'Literal' is not a NiFI >> expression language function. If you can give me some detail on what you >> are trying to do, I can help you with the NiFi expression language strategy >> to accomplish it. Did you create a FlowFile attribute named 'encoding'? >> >> Matt >> On Nov 12, 2015 6:15 PM, "Charlie Frasure" <[email protected]> >> wrote: >> >>> Typos on my regex were just in the email, not the processor. It should >>> have read ${encoding:match... >>> >>> On Thu, Nov 12, 2015 at 6:03 PM, Charlie Frasure < >>> [email protected]> wrote: >>> >>>> This expression does not parse without error: >>>> ${literal('utf-8 utf-16 utf-16be utf-16le us-ascii >>>> iso-8859-1'):contains(encoding)} >>>> >>>> Is it not possible to use an attribute in a comparison function? >>>> Unexpected token 'encoding' at line 1, column 73. Query: >>>> ${literal(utf-8 utf-16 utf-16be utf-16le us-ascii >>>> iso-8859-1):contains(encoding)} >>>> >>>> Alternatively, I think a regex should work, but didn't immediately get >>>> a match using: >>>> ${enconding.match('utf-8|utf-16|utf-16be|utf-16le|us-ascii|iso-8859-1')} >>>> >>>> Charlie >>>> >>>> >>> >>> >
